In a recurring report, the data is never quite still. Issues are corrected, restatements arrive, and systems refresh at different times. Without a discipline for how data is refreshed and versioned, a report becomes ambiguous: which snapshot was it built on, and does the number I am reading match the one that was sent?
This guide covers how to refresh and version report data so every cycle is unambiguous and reconstructable. It is the companion to Data Quality for Reporting.
A recurring report is only as reliable as the snapshot it was built on. Freeze it, version it, and be able to reproduce it.
Why refresh and versioning matter
Two questions decide whether a report is trustworthy after the fact.
- Which data did it use? If the source changed after the report was built, the figure may no longer match.
- Which version was sent? If a corrected version circulates alongside the original, no one knows which is authoritative.
Refresh discipline answers the first; versioning answers the second. Together they make the report reproducible, which is the foundation of trust in a recurring cycle.
Freeze before you report
The single most important practice is the data freeze: fixing the snapshot the report will use.
- Set a freeze point in the reporting calendar, ahead of drafting.
- Export the snapshot, so the report draws from a fixed set rather than a live system.
- Record the as-of date, so the period is unambiguous.
- Require a decision before the freeze is reopened – changes after it are exceptions, not defaults.
A report built on a live system that keeps changing is a report no one can reproduce. The freeze is what makes the number stable.
Versioning the report
Versioning is the discipline that keeps the issued report unambiguous.
- Version every draft, so the approved one is identifiable.
- Record the approval, with who, when and which version.
- Issue only the approved version, through a controlled distribution list.
- Archive the issued version with its snapshot, so it can be reproduced later.
The most common failure is a “final” file superseded by an emailed edit. Versioning prevents it. See Report Approval & Sign-off.
Refreshing after a correction
Sometimes the data changes after issue – a restatement, a late input, a correction. The response should be controlled, not ad hoc.
- Assess materiality – does the change affect a decision or a published figure?
- Decide whether to reissue or note the correction in the next cycle.
- Version the reissue, and mark the superseded version clearly.
- Record the change, and feed the cause to the post-cycle review.
An uncontrolled reissue is how two “final” versions end up in circulation.
Reproducing a past report
The test of a refresh and versioning discipline is whether a past report can be reproduced.
- The snapshot must be retained for as long as the report may be questioned.
- The definitions must be versioned, so a metric means what it meant at the time.
- The reconciliation must be recorded, so the figures can be checked later.
If a report from six months ago cannot be reproduced, the discipline has a gap, and the gap is usually the snapshot or the version record.
Version naming and archive
A simple version scheme removes ambiguity.
- Name drafts sequentially – v0.1, v0.2 – and the issued version clearly, such as v1.0 final.
- Record the approval against the issued version number.
- Mark a superseded version as superseded, and keep it rather than deleting it.
- Archive the issued version with its snapshot, so it can be reproduced.
The naming is not bureaucracy; it is what lets a reader know whether they hold the current, authoritative version.
A worked refresh decision
Take a case where a figure is restated after the report is issued.
- The change: operating costs revised down by 2% after a late invoice.
- Materiality: it changes the reported margin by less than a point.
- Decision: note the restatement in the next cycle rather than reissuing, because it does not affect a decision.
- Record: log the restatement and the reasoning, so the basis is clear.
A material change would trigger a reissue; an immaterial one is noted. The decision is documented, not improvised.
Versioning the inputs, not just the report
The report version is only half the discipline. The inputs need versions too.
- Version the metric definitions with effective dates.
- Version the mapping or allocation logic where figures are derived.
- Version the source extract where the report depends on it.
- Record which versions applied to the issued report.
A report version tied to unversioned inputs cannot be reproduced, because the inputs may have changed underneath it.
Common mistakes
- No data freeze. The report is built on a moving target.
- No versioning. A corrected version circulates alongside the original.
- Live-system reporting. The figure changes after the report is issued.
- Uncontrolled reissues. Two “final” versions in circulation.
- No snapshot retained. Past reports cannot be reproduced.
Frequently asked questions
What is a data freeze in reporting?
A point in the reporting cycle at which the data snapshot is fixed, ahead of drafting, so the report draws from a stable set rather than a live, changing system.
Why does a recurring report need versioning?
Because a corrected version can circulate alongside the original, leaving no one sure which is authoritative. Versioning makes the issued report unambiguous.
How do you handle a restatement after a report is issued?
Assess materiality, decide whether to reissue or note the correction next cycle, version the reissue, mark the superseded version, and record the change and its cause.
How long should data snapshots be retained?
For as long as the report may be questioned – typically the audit or retention period that applies to your reporting, and at least long enough to reconcile subsequent cycles.
How do you reproduce a report from six months ago?
From the retained snapshot, the versioned definitions, and the recorded reconciliation. If any of the three is missing, the report cannot be fully reproduced.
How should report versions be named?
Sequentially for drafts, with a clearly marked issued version, and superseded versions marked as such rather than deleted. The point is that the current, authoritative version is unambiguous.
When should a report be reissued?
When a change is material – it affects a decision or a published figure. Immaterial changes are noted in the next cycle instead.
What is retained with a report version?
The issued version, the data snapshot it was built on, the versioned definitions, and the recorded reconciliation – so the report can be reproduced later.
Do inputs need versioning too, or just the report?
Both. Version the metric definitions, the mapping or allocation logic, and the source extract, and record which versions applied to the issued report.
What happens if the snapshot is not retained?
The report cannot be reproduced later. Reproduction depends on the retained snapshot, the versioned definitions and the recorded reconciliation.
How long should snapshots be kept?
For as long as the report may be questioned – typically your audit or retention period, and at least long enough to reconcile the next few cycles.
What is a data freeze, in one line?
The point in the cycle at which the snapshot is fixed, so the report draws from a stable set rather than a live system. Everything after that is an exception to be managed.
Does versioning slow the cycle down?
No. Naming a version and recording an approval takes a moment; reconstructing which version was authoritative after the fact can take hours, or prove impossible.
Who authorises a reissue?
The report owner, following the same approval gate as the original issue, with the approval recorded against the new version number.
Can a report be reproduced from the system alone?
Rarely. The system shows current data, not the snapshot the report used. Reproduction depends on retaining the snapshot and the version record.
Next step
Freeze the data, version the report, retain the snapshot, and record reconciliations. See Report Approval & Sign-off for the versioning gate, and When Data Is Wrong for handling a correction after issue.
Sources
- Data-quality and reporting practice: data freezes, snapshot retention and version control as standard reporting controls.
- APMP, Body of Knowledge: version control, production management and document retention, applied to recurring reports.
Good-practice claims are cited from their sources; no statistic in this article is invented.