Manufacturing Dashboard Software: Why Output Totals Disagree

When a dashboard and a shift sheet disagree, compare the included transactions before choosing a total. Manufacturing dashboard software should let a reviewer trace a number to its source events, definition, time boundary, and data version. A visually polished chart does not establish which records belong in it.

This guide is for small manufacturing owners and production managers evaluating reporting software. It provides a hypothetical reconciliation and a supplier-demo checklist. It extends our daily manufacturing dashboard guide, which covers what to show and who should act on it.

First, define the same measure

Ask each report owner to complete one sentence: "This number counts these events, for this operation and location, in this unit, within this period, using this status rule." Words such as output, complete, accepted, and shipped are not interchangeable.

For the worked example, both reports are intended to show accepted finished pieces of one part from one final operation on line L-2. The reporting interval includes 06:00 and excludes 14:00 on one stated date. All example times use the same site clock at UTC-05:00, with no clock change during the interval. A real implementation should retain the actual site time zone and handle clock changes explicitly.

We are comparing a dashboard snapshot taken at 14:05 with a shift sheet finalized at 14:15. That difference in observation time is part of the investigation. No figure below represents a Ploqy customer result.

Reconcile 1,240 pieces to 1,180

The dashboard displays 1,240; the finalized shift sheet displays 1,180. Keep both original reports and export the rows contributing to each. In this fictional case, the review finds three separate differences.

1. Remove one duplicated 40-piece event

A completion event for 40 accepted pieces was retried after a connection interruption. The reporting import counted both deliveries of that same event. Its original event ID and source record show that the second delivery is not another batch.

Keep the legitimate 40-piece completion and exclude only its duplicate contribution. The dashboard comparison total moves from 1,240 to 1,200. Do not deduplicate merely because two rows share a quantity and timestamp; two genuine jobs can have matching values. Use a stable source identity and investigate ambiguous records.

2. Move 30 pieces to the next shift

A separate 30-piece event occurred exactly at 14:00. The agreed interval assigns that instant to the next shift, but the dashboard query included it in the earlier shift as well. Correcting the interval changes the comparison total from 1,200 to 1,170.

Do not delete that production event. Keep it in the next shift, and verify that the two adjacent shifts together count it once. A boundary rule that includes both ends of adjacent intervals can create a double count even when every individual source event is valid.

3. Include a late-arriving 10-piece event

Ten more pieces completed the defined acceptance event at 13:55. The record reached the reporting source at 14:10, after the dashboard snapshot. The finalized shift sheet already includes it. Under this example's occurrence-time rule, those pieces belong to the earlier shift.

After the validated late record is included and the dashboard data is refreshed, the reconciled total becomes 1,170 + 10 = 1,180. The complete bridge is 1,240 - 40 - 30 + 10 = 1,180.

The matching totals are a useful check, but not sufficient proof. Confirm that both reports now contain the same eligible event set. An omitted 20-piece event and an unrelated extra 20-piece event could cancel numerically while leaving the records wrong.

Keep occurrence time separate from entry time

The worked case uses the time the defined production event occurred, not the time somebody typed or synchronized it. Other reports may intentionally measure posting activity instead. Label the choice, preserve both timestamps, and avoid silently switching between them.

Define which event supplies the clock: machine completion, final inspection acceptance, finished-goods receipt, or shipment. If inspection happens later, it may legitimately create a different reporting period from machining. Link to the job-card record and inspection evidence rather than treating one department's timestamp as universally correct.

Late entries also need a closing rule. Decide whether an approved shift report is restated, shown with a later adjustment, or retained as an immutable snapshot alongside a current view. Record who reviewed the correction and why. Preserve enough history to reproduce what a manager actually saw at the earlier meeting.

Check the data pipeline, not just the refresh button

A current browser display can still show an older data copy. For example, Microsoft's Power BI documentation distinguishes refreshing report visuals from refreshing imported data: visuals based on imported tables can query the data from the last model refresh. That is a product-specific behavior to investigate, not a claim that every dashboard works the same way. Source: Microsoft Power BI data-refresh documentation.

For a software demonstration, ask for four timestamps: when the production event occurred, when it reached the source, when the reporting dataset successfully loaded it, and when the displayed result was calculated. A page-open time or attempted refresh time alone does not show that the source update was included.

Make failed or incomplete refreshes visible. An old total with a clear last-successful-update warning is more useful than an old total presented as live. Agree when a stale report should stop being used for a particular decision, especially dispatch readiness or urgent schedule changes.

Check units, quality status, and filters too

The example deliberately uses one part and pieces throughout. In real reports, a total of boxes is not comparable with a total of pieces until a valid conversion is applied. Keep the conversion and its effective version visible. Do not combine different products into a total that hides their units or operational meaning.

Compare accepted, rejected, held, and awaiting-inspection quantities separately. An operation-completion total may correctly exceed accepted finished output. For the physical balance behind those statuses, see the worked partial-job quantity guide. Today's reconciliation concerns which reporting rows qualify, not a second count of physical stock.

Check saved filters and access scope. One user may see only one line while another sees the whole plant. Report permissions should remain in force during investigation; use an authorized reviewer or a sanitized comparison export rather than widening access merely to make screens match.

Use these acceptance tests before rollout

1. Trace the total. Open the exact rows behind a headline value, with source IDs, unit, operation, status, and report scope.
2. Replay an event. Deliver the same 40-piece source event twice. Confirm one contribution and visible evidence of how the duplicate was handled.
3. Cross the boundary. Enter a record exactly at shift end. Confirm it belongs to one shift and remains present in the combined-day total.
4. Arrive late. Enter a prior-shift event after the first refresh. Check its period assignment, review status, and effect on the saved and current views.
5. Interrupt refresh. Stop the test data connection and inspect the displayed freshness warning and recovery result.
6. Change the context. Compare units, quality statuses, saved filters, and authorized user scopes without weakening permissions.
7. Export the bridge. Produce the starting total, each explained difference, final total, and event-level evidence. Mark unexplained differences as unresolved.

Write the expected outcome beside each test and distinguish standard functionality from configuration, proposed customization, and manual work. A demonstration should show the actual path from event to report, not only a corrected number.

Fix the first unexplained difference

Choose one line, one shift, and one disputed measure. Compare definitions first, then record sets, then refresh history. Correct the earliest supported mismatch and repeat the comparison. If evidence is missing, retain the discrepancy and assign an owner instead of inventing a balancing adjustment.

Once the reconciliation is reliable, connect it to the production metrics your team uses to act. The goal is not to force every report to display the same number; it is to make each number explainable within its documented purpose.