Explain why two correct reports can disagree

Two reports can disagree when they correctly answer different questions. Their populations, dates, status filters, units or source versions may differ. Establish those definitions before deciding whether one calculation is wrong.

The aim is not to excuse every mismatch. It is to distinguish a legitimate difference in meaning from a failure to implement an agreed metric.

Compare the contracts first

In the original retail BI fixture, all eight sales lines across seven orders total 77,500 paise. The paid subset contains seven lines across six orders and totals 69,500 paise. The difference is 8,000 paise from the non-paid portion.

An all-status report and a paid-only report can therefore both be correct under their stated rules. If both are labeled “paid sales,” however, the larger result does not match that contract.

The retail BI lab supplies the synthetic data and reference checks. These totals are teaching values, not actual commercial results.

Build a small reconciliation bridge

The bridge explains the difference using mutually exclusive parts of the same source. It does not require forcing both reports to display the same number.

Keep the entity count beside the amount when grain matters. Seven paid lines are not seven paid orders; the paid subset has six distinct orders. A report counting lines and another counting orders can disagree without either count being arithmetically wrong.

Inspect time and source versions

Two reports may use the same metric but different extraction times. A later extract can include a correction or late-arriving eligible record. Compare source manifests and refresh timestamps before assuming the query changed.

Occurrence time and receipt time also answer different questions. In the weekly reporting case, an event arriving after the period end is included because its occurrence time belongs to the week and the readiness contract permits it.

A receipt-time report may place that event in a later window. The difference is legitimate only if each report clearly states its time basis and serves the intended decision.

Check units and adjustment rules

An amount stored as 104,000 paise can be displayed as INR 1,040. Those values agree after conversion. If both are labeled rupees, one label or calculation is wrong.

Gross, discounted, refund-adjusted and collected amounts can also differ. Write the adjustment sequence and timing rule. Do not assume a refund ledger without dates can establish a period-specific cash-flow measure.

Rounding can produce small display differences, but investigate the unrounded values before using rounding as an explanation. A large missing category is not a formatting issue.

Identify when disagreement is a defect

If the population, grain, time, unit, source version and adjustment policy are all intended to match, a remaining discrepancy needs diagnosis. Common causes include join fan-out, dropped unmatched records, duplicate inputs and inconsistent null handling.

The conflicting-total interview exercise demonstrates those implementation errors. Its 171,000-paise fan-out total is not a valid alternative to the agreed 104,000-paise completed-order measure.

Explain the result to the users

State which report answers which question, show the bridge and recommend clearer labels or definitions. If one report is wrong, identify the defect and the validation that will prevent recurrence.

Avoid declaring a universal “single source of truth” without specifying the measure. A shared source can support several valid metrics, and a shared label can still conceal incompatible rules.

Exercise: write two report titles that distinguish the 77,500 and 69,500 totals clearly. Then list the metadata needed to explain a future difference caused by a late-arriving record.

NeuraPath's Data Analytics with Generative AI course connects reconciliation with metric communication. The useful outcome is agreement about meaning and evidence, not merely making every dashboard display the same number.

Continue learning

This article is part of the Metrics, visualization and decision communication sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Translate a vague request into an answerable analytical question.
• Continue with Build a chart annotation standard for recurring reports.