Two teams bring different completed-order totals to a meeting. One groups orders by creation date, the other by completion date. Both reports may implement their rules correctly while answering different questions. This illustrative case shows why reconciliation begins with the metric definition, rather than the formula on the screen.
Describe the question without naming the report
“How many orders did the team complete this month?” and “What happened to orders accepted this month?” require different datasets. Agree which decision depends on the answer: workload assessment, unfinished-work control or planning the next period.
Record the event, counting unit, period and status. For each definition, provide an included and an excluded record. The disagreement about a chart becomes a check of explicit conditions.
Align granularity before comparing totals
A row may represent an order, a line item or a status change. Joining status history can repeat the same order. Applying DISTINCT without a reason may hide the symptom without identifying the required record.
Microsoft’s star-schema guidance distinguishes facts from dimensions and emphasizes consistent fact granularity. For this check, first establish what a row represents, then choose the counting method. This is a modelling principle, not a requirement to use a particular BI product.
Reduce the difference to specific records
Use the same source snapshot and record the extraction time. Compare identifiers: which appear only in the first set, only in the second and in both? Check event date, status and exclusion rules for each group.
In this example, an order was created at the end of one month and completed at the start of the next. It belongs to different periods in the two reports. Once the question is agreed, the difference becomes explained rather than an error to conceal.
| Check | Question | Evidence |
|---|---|---|
| Period | Which event determines the date? | A record crossing a month boundary |
| Granularity | What does one row represent? | Identifier and repeats after the join |
| Freshness | Which sources have arrived? | Time and scope of the latest load |
Acceptance needs reproducible evidence
Keep the definition, sample, expected outcome and metric owner’s approval. Decide separately whether to recalculate history after a rule change. Do not silently mix a new definition with old values.
E-Data Consulting starts an analytics pilot with this acceptance record. Sources may reside in A5.ERP or other systems; available fields, extraction methods and frequency are checked for the actual configuration. The next step is to select one discrepancy and trace it to the source record.
Questions and answers
Should only one report remain?
No. Different decisions may need different views. Clear names and definitions prevent unlike metrics from being compared as equivalent.
Can a new dashboard resolve the difference?
Only if the rule, source or transformation is corrected. A visual redesign alone does not change the meaning of the data.
Source and method
Microsoft Learn: Star schema. The worked example and acceptance procedure above are original editorial guidance, not a quoted standard or a real client case.