Restatements: when history changes
Data that has been published can change. A store's late file arrives, an error is corrected, a hierarchy is remapped, a weighting scheme is refreshed. Each of those legitimately alters figures that somebody has already used.
Restatement is normal in any serious data operation. What matters is whether it is disclosed and bounded.
Why does history move?
Four common reasons. Late-arriving data from stores that reported after the cut. Corrections to errors found later. Reclassification, where an item or store is remapped. And methodology changes, where the way figures are computed is revised and applied retrospectively.
They are not equivalent. The first two make history more accurate; the last two make it different.
What should a restatement policy say?
How far back history can change, under what circumstances, how changes are communicated, and whether a prior version remains available. Those four make a dataset usable for anything that has to be reproduced.
The last one is the most valuable and the least common. An archived version of what was published on a date is what allows an old analysis to be checked.
Why does this matter commercially?
Because decisions get made on figures. A trade term agreed against a number that later changes, or a bonus calculated on a series that was restated, produces a dispute with no clean resolution.
The defence is to record which version was used, with its extraction date, alongside any decision that depends on it.
What is the difference between a revision and a methodology change?
A revision corrects the estimate of the same quantity. A methodology change redefines the quantity. The first is an improvement; the second breaks comparability with everything computed under the old method.
Providers should announce methodology changes explicitly and, ideally, publish a period of overlap on both bases. Without overlap, a step change appears in every series and looks like a market event.
How should an analyst work with this?
Stamp everything. Every extract carries a date and a version, every saved result records which extract it came from, and anything that will be revisited is stored rather than regenerated.
That discipline costs very little and it is what makes an analysis defensible six months later, when the underlying data no longer produces the same numbers.
Does this affect published external series too?
Yes — national statistical series are revised on published schedules and the most recent points are the most likely to move. The Census Bureau's retail series documents its revision practice, which is a good model for what a commercial provider should be able to state.
What should a buyer ask?
Whether history changes, how far back, how often, how it is notified, and whether prior versions are retained. Five questions, and a provider who has answers has thought about being relied upon.
Frequently asked questions
How far back should history be allowed to change?
That is a policy choice rather than a fact, and what matters is that the boundary exists and is stated. Unbounded revision makes reproducibility impossible.
Should I always use the latest version?
For current analysis, yes. For reproducing a prior decision, no — use the version that decision was made on, which is why archiving matters.
What if a restatement changes a conclusion?
Then the conclusion was marginal, and that is worth knowing. Re-run and report both, rather than quietly adopting the new answer.
Does restatement indicate poor data quality?
Not by itself. Transparent restatement indicates a process that finds and fixes errors. Silent restatement is the concerning version.
How do I detect an undisclosed restatement?
By storing extracts and comparing. If history moves and nothing was announced, that is a question for the provider.
Do reclassifications affect long series?
Substantially, because a remapped item changes the composition of every period. Ask whether reclassifications are applied retrospectively or only forward.
What about my own internal restatements?
The same rules apply. Internal hierarchies change and internal history moves, and the discipline of stamping versions is just as necessary inside a business.
What is the minimum good practice?
Extract-date stamping on every saved result. It is one field and it makes the difference between an analysis that can be checked and one that cannot.
### What should happen when a restatement is announced?
Check whether any live commitment depends on the affected periods, then decide whether to re-run or to note the change. Both are reasonable; doing neither is not.
Keep a short register of decisions that are bound to specific figures — trade terms, incentive calculations, published claims. When history moves, that register tells you in minutes whether it matters.
### What should a provider publish about revisions?
A schedule, a magnitude history, and a notification route. A buyer who knows that revisions are typically small and arrive on a known cadence can plan around them; one who discovers a restatement by accident cannot.
Magnitude history is the element most often missing and the most useful, because it converts an abstract risk into a quantity.
### Why does this matter more as analysis is automated?
Because automated pipelines re-run against current data by default, so a dashboard silently updates history and nobody sees the change. The manual equivalent at least had somebody looking at the numbers.
The defence is to snapshot anything that will be referred to again, and to make the snapshot date visible on the output rather than buried in a log.
Working with retail data? See NRS Insights data solutions or contact NRS Insights.