Why three systems give three answers to the same question

Ask three enterprise systems how many records were processed last quarter and you will frequently get three different numbers. The instinctive diagnosis is "data quality" — something must be corrupted, duplicated, or lost in transit. In our experience that diagnosis is almost always wrong, and it sends teams down an expensive path of re-validating pipelines that were working correctly all along.

The real cause, in most engagements we have seen, is that the three systems are answering three subtly different questions.

Where the divergence actually comes from

Consider a record that a user created, saved as a draft, and never submitted. The source system counts it — it exists in the table. The operational report excludes it — it was never "real" work. The data warehouse counts it on Mondays and excludes it on Fridays, because the draft flag arrives on a different sync schedule than the record itself.

None of these systems is broken. Each is internally consistent. But nobody ever wrote down which of the three behaviors is the definition of a processed record, so each layer embedded its own assumption — usually years apart, by different teams, each making a locally reasonable choice.

Field constraints produce the same effect. A source system that truncates a category field to fifty characters will silently split one category into two when a rename pushes a value over the limit. Reporting that groups on that field now shows a total nobody recognizes, and the discrepancy hunt begins in exactly the wrong place: the numbers, rather than the field.

Tracing beats averaging

When totals conflict, there is a strong organizational temptation to negotiate: pick the most defensible-looking number, or worse, present a range. Both moves defer the problem to the next briefing, where the same conflict resurfaces with higher stakes.

The alternative is slower but terminal: take one record population, follow it through each system, and identify the exact rule where the counts diverge. In practice the full list of divergence causes is short — draft and status handling, sync timing, field constraints, filter defaults, and timezone boundaries cover the large majority. Each cause, once found, is a sentence in a definitions document rather than a mystery.

The deliverable that matters is not the reconciled number. It is the canonical measure definition — a written statement of what counts, what does not, and which system is authoritative for each component. With that in place, disagreements about the number become disagreements about the definition, and definitions can be settled in a meeting rather than re-litigated in every briefing.

What this looks like as infrastructure

Documentation decays unless something enforces it. The durable version of this work is a reconciliation layer that recomputes the canonical measures from each source on every refresh and surfaces divergence as data — a small table of "system, measure, delta, known cause" that leadership never sees because someone fixes the cause while the delta is still small.

That layer is not sophisticated. It is a handful of queries and a habit. But it converts the reconciliation from a one-time heroic effort into a property of the reporting system — which is the only form in which it survives staff turnover.

If your dashboards currently disagree with your source systems, the fastest path out is rarely a data quality initiative. It is one person, one record population, and the patience to follow it all the way down.