Data practice · 28 Sep 2026

How do you keep reports trustworthy when the underlying data changes?

← Data practice

Say what each report knew and when, and mark which figures are settled and which are still provisional. Keep enough history to reproduce a past report as issued, and explain every difference since. The accounts have period close for this: once a month is closed, late items go into the current period. Management reports on operational data, such as the last few days' harvest, the current month's stumpage or accruals waiting for invoices, move legitimately as documents arrive. A report that silently shows a different figure for last month than it did last week loses trust, even when the new figure is right. A line such as as at 5 September; up since last issue, from late tickets and a rate correction keeps it.

What the usual answer says

The usual advice is to validate data quality, keep audit trails, give each metric an owner and a definition, and flag metrics that moved more than expected. One guide adds the right instinct: distinguish corrected numbers from figures that remain uncertain. All useful. It rarely says how to do that in a report people read every week.

Illustrative: one month's stumpage As first issued as at 5 September provisional Each change, dated and explained Late tickets loads ticketed after issue A rate correction the rate was wrong at issue A late settlement arrived after the issue As it stands today settled: every expected document in
Illustrative, with no figures. The report says what it knew and when, and each difference since the last issue is listed with its date and its cause, so a moved figure keeps the reader's trust. Diagram: Quarri.

Even audited numbers change

Ideagen Audit Analytics' May 2026 report found "Total restatements fell 18% in 2025, from 477 to 391", making 2025 "the second lowest annual count in our 20-year database". That is good news about the accounts, and it shows that even audited, controlled numbers are occasionally wrong after issue. Management reports are built on data that is still arriving, so their figures move for a different reason: they were provisional when issued, not wrong.

Keep history, and know how long

Not every source system keeps old values. The company behind dbt, which sells data transformation software, notes in its documentation on snapshots: "While some source data systems are built in a way that makes accessing historical data possible, this is not always the case." Its snapshots exist because "Analysts often need to 'look back in time' at previous data states in their mutable tables", and record each version of a row with the dates it was valid.

Open table formats go further. The Apache Iceberg documentation describes "time travel in SQL queries using TIMESTAMP AS OF or VERSION AS OF clauses". A report can then be rerun against the data as it stood when it was issued. That lasts only while the old snapshots are kept; they are commonly expired to save storage, so set the retention to match how long reports need to be reproducible.

Settled or provisional

Mark each figure in a report as settled or provisional, based on whether all its expected documents have arrived. Harvest volumes for the last few days, stumpage for the current month and costs still carried as accruals will usually be provisional; closed months should be settled. Readers then know which numbers to act on and which to watch, and whoever prepares the next issue knows where to look for changes.

The flag needs a rule for what counts as expected. For harvest, it can be a ticket for every load in the trip record. For stumpage, a settlement for every active contract in the month. For costs, an invoice for every accrual. When the last expected document arrives and matches, the figure turns settled. Documents that arrive after that are the ones worth a line in the difference section.

Then add a short section to each issue on what changed since the last one. Say which figures moved, by how much, and why: late tickets, a correction, a rate change or a reclassification.

Where AI helps

Given the report as issued, the report now and the data history, AI can list what moved and trace each change to the records behind it. That is the tedious part of writing the difference section. It works for changes that come from records. It can't explain a change that comes from a revised definition unless the definitions are versioned too.

When it doesn't apply

One-off analyses that no one will compare with a later version need less of this. Figures from closed and audited periods need only the cut-off. And a business whose management reports come only from the closed accounts can rely on period close. A locked PDF of each issue reproduces those reports well enough. It can't explain the differences.

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

Sources

  1. Ideagen Audit Analytics, "Financial restatements report", May 2026: ideagen.com
  2. dbt Labs, "Add snapshots to your DAG", dbt documentation: docs.getdbt.com
  3. Apache Iceberg, "Spark Queries: Time travel", documentation: iceberg.apache.org

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.

See it on your own data.

Live in two weeks, on the systems you already run.