Why do reports from different systems never agree?

Reports from different systems usually disagree for one of three reasons: they use different definitions, they were taken at different moments, or one of them is wrong. Definitions are the most common culprit in our experience. Timing is the one that is easiest to rule out, and it has a twist that the usual explanations miss. Figures for months that are supposedly over can keep moving. A report presented at month end and the same report run two weeks later describe two versions of that month. A re-run test separates timing from the other two causes in an afternoon.

What the usual answer says

The articles that rank for this question cover definitions and filters well. One consultancy puts it this way: "Two reports can appear similar while using slightly different rules underneath. Small logic differences often create large reporting discrepancies". A software vendor's explainer adds stored snapshots. When a derived number is saved and never recomputed, "Weeks later, a report reads the stale snapshot, another report recomputes the value live, and the two disagree by exactly the amount of history that accumulated in between".

What neither covers is the source data itself changing after a period has been reported, or how to tell that apart from a definitions problem.

When last month keeps changing

Most ERPs accrue for goods when they are received, so a late invoice does not move the whole cost of last month. What moves is what was not accrued, or not accrued correctly: price and quantity differences between receipt and invoice, items received without a record, and adjustments. Invoices take time to reach the ledger. Ardent Partners' 2025 accounts payable benchmark, sponsored by the e-invoicing company Pagero and based on 212 survey responses, found that "The average AP organization takes 9.2 days to process a single invoice". Where the difference between the accrual and the invoice is dated back to the month of receipt, that month's figure changes after it was presented.

In a timber business the question is which records carry the event date and which carry the entry date. A scale ticket carries the load date. A settlement, a rate correction or a deduction may carry either, depending on how it is entered. Any record entered later but dated to the load revises a figure that has already been reported.

When two systems see different moments

Systems also copy data on schedules. One ERP vendor's analytics add-on, for example, is documented to support "two data refreshes per day, at 12:00 AM and 12:00 PM (Coordinated Universal Time)". A report from that store at four in the afternoon shows the data as it stood at noon. A report from the ERP itself at the same hour shows it as it stands now. Neither is wrong, and a comparison between them can mislead unless both carry their as-of time.

The test

Take last month's main report as it was presented at month end. Run the same report today, on the same definitions. If the figures differ, list the transactions that changed and when they were entered. That list measures how much of the disagreement comes from timing. If the re-run matches the original and the departments still disagree, timing is ruled out, and the cause is definitions or an error. The same list shows which documents habitually arrive late, which may be the cheaper thing to fix.

What software changes

Most finance teams already book late items against the next period once a month is closed. What data tooling adds is the record of what moved. A report can carry the time its data was taken, and the version that was presented can be kept beside later re-runs. The transactions entered between two versions can then be listed automatically rather than hunted for.

When it doesn't apply

A business that locks each period at close and never reopens it has little moving past, and its disagreements will come from definitions and filters. Real-time operational counts, such as loads on the road right now, are meant to change by the minute and are not compared across periods. And where the headline disagreement is between tally and scale volume, or shipped and invoiced, it is a definitions problem that no as-of stamp will fix.

Quarri for finance and strategy teams is built for the people who close the month, explain the margin and answer the board.

Quarri is an AI-native data platform for the timber supply chain. It connects buying, production, sales and inventory for forest management, sawmill, wood products and pulp, paper and packaging operators.