Finance reports one revenue figure, the product dashboard shows another, and the warehouse produces a third. Each team trusts its own number. Before anyone examines a pipeline, establish whether the systems are even measuring the same thing - in most cases they are not, and the discrepancy is definitional rather than technical.
01Definitions diverge before data does
Revenue can mean bookings, recognised revenue, cash received or invoiced amounts, and each is legitimate for a different purpose. An active user might be someone who logged in, performed an action, or held a valid subscription. Two systems computing different definitions correctly will never agree, and no reconciliation of the pipeline will make them.
Write the definitions down explicitly before investigating anything else. This step alone resolves a large share of reported mismatches, because it usually reveals that both numbers are right for what they measure.
| Dimension | Variation |
|---|---|
| Time zone | UTC versus local versus reporting time zone |
| Period boundary | Calendar month versus billing cycle |
| Currency conversion | Rate at transaction versus at reporting |
| Refunds and credits | Netted, excluded, or in a separate period |
| Test and internal accounts | Included in one system, filtered in the other |
| Deleted records | Hard deleted versus soft deleted |
02Time zones account for a large share
A transactional system storing UTC and a reporting system aggregating by local day will disagree on every daily figure, with the difference concentrated at period boundaries. Month-end is where this becomes most visible and most consequential, because that is when numbers are formally reported.
Standardise on UTC for storage and convert only for display, with the reporting time zone stated explicitly on every report. Ambiguity here produces discrepancies that recur every period and get re-investigated repeatedly.
03Late-arriving data makes snapshots disagree
Events that arrive after an aggregation has run are absent from it. A dashboard computed at midnight and a warehouse job running at three in the morning will legitimately differ if events continued arriving in between, and both are correct as of their execution time.
Decide and document whether aggregates are recomputed when late data arrives. Either policy is defensible; leaving it implicit means nobody can tell whether a difference indicates a bug or expected behaviour.
| Step | Purpose |
|---|---|
| Agree the metric definition in writing | Removes definitional mismatch |
| Fix the time window and time zone | Removes boundary effects |
| Compare totals for one narrow period | Reduces the search space |
| Compare counts before comparing sums | Distinguishes missing rows from wrong values |
| Identify records present in one system only | Points at the pipeline stage |
| Trace a single differing record end to end | Confirms the mechanism |
04Compare counts before comparing values
If two systems disagree on a total, first check whether they hold the same number of records. Differing counts mean the pipeline is dropping or duplicating rows, which is a fundamentally different problem from equal counts with different values - the latter points at transformation logic, currency conversion or rounding.
Then take one record that differs and trace it through every stage. A single traced example usually reveals the mechanism faster than any amount of aggregate comparison, because it shows exactly where the value changes.
05Nominate one system as authoritative per metric
For each important metric, name the system of record and require that others reconcile to it rather than computing independently. Where three systems each calculate revenue from source data, they will drift apart continuously and every reconciliation becomes a negotiation.
Automate the comparison. A scheduled check that compares key metrics across systems and alerts on divergence beyond a threshold turns this from a quarterly argument into a monitored condition somebody addresses while the cause is still recent.
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer