Assign late records to the event period required by the metric, while retaining their arrival date. Publish revised versions with a bridge from the earlier total. Define provisional periods, revision deadlines and materiality rules before a delay creates an unexplained change in a report.
Distinguish late arrival from new activity
A record received today can describe an event from last week. Store the business event date, first received timestamp and any correction timestamp separately. Choose the reporting period using the metric definition rather than the import schedule. If the report measures invoices issued, a delayed invoice export belongs to its issue period; a report of records processed can legitimately use arrival time instead.
Preserve the prior published version. Without it, an analyst may be unable to explain why a screenshot, downloaded file and current dashboard disagree. A revision log should identify the affected period, prior value, revised value, reason and publication time. Avoid a vague updated label that leaves readers unable to tell whether yesterday's activity or a historical correction caused the movement.
Set a policy for provisional and stable periods
Define when an initial estimate appears, how long routine revisions are accepted and what happens after the normal window closes. Different sources can require different waiting periods. A rapid operational view may accept incomplete recent data, while a monthly management comparison may wait for reconciliation. Label those views so readers understand their intended use and do not treat them as competing unexplained answers.
Materiality should reflect decisions as well as absolute size. A small adjustment that changes a target status or regional ranking may deserve a prominent note. Record both the numerical threshold and qualitative triggers. Provide an exceptional-correction route for important errors discovered after a normal freeze; a freeze should create governance, not an instruction to preserve a known misleading figure forever. Assign authority to approve that exceptional release.
Explain revisions as a bridge
Break a changed total into late events, corrected values, removed duplicates and definition changes where those components exist. Keep the signs consistent so the bridge reconciles exactly. Do not count one newly arrived refund both as a late adjustment and a separate correction. If multiple publications are revised, identify the earliest affected period and preserve comparable definitions across the series.
Monitor arrival lag by source to see whether recent periods mature predictably. A rising delay may need operational attention instead of repeated footnotes. The linked framework offers timeliness and fitness background, not a mandatory revision calendar. The invented calculation below demonstrates one policy. It should not be read as evidence that any actual reporting process has a particular delay distribution or that a financial closing rule has been satisfied.
If readers download the data, include a version identifier in the export. That lets them relate a locally saved total to the corresponding revision note instead of comparing an old file with an unexplained new screen.
Fictional weekly invoices: Monday changes Friday’s view
A fictional scenario to explain the method, not a customer result or a market benchmark.
A fictional Friday review shows 40 invoices issued during the week, totalling 8,000 units. Its publication note says that the latest week is provisional until Tuesday noon. On Monday, three more invoices arrive centrally. Their source issue dates belong to the prior week and their values total 600 units.
Version two therefore reports 43 invoices and 8,600 units for the original week, with a bridge of 8,000 plus 600 late arrivals. The Monday event-period total does not receive an extra 600. A separate processing-workload report can count three records received on Monday because that report measures a different event.
The report retains version one's publication time and marks the revised week. One late invoice would have changed a target status even at a small value, so the owner also records that decision effect. These fictional values demonstrate a transparent revision rather than claiming that all delayed invoices are valid or automatically material.
TAKE THIS INTO YOUR NEXT CONVERSATION
A practical next-step checklist.
- Retain event, arrival and correction timestamps.
- Label provisional periods and revision windows.
- Store prior published versions.
- Reconcile every revision through signed components.
Common questions.
Should a frozen period never change?
A normal freeze can limit routine updates, but an explicit exceptional-correction route should handle consequential errors.
Is a changed total automatically evidence of an error?
No. Newly arrived valid records, corrected values and changed definitions have different causes and should be identified separately.
Further reading & source context.
These primary references provide background. They are not evidence for the fictional example above and do not endorse Accuralytix.
Found an error or a missing qualification? Send an editorial correction.
Check my data readiness.
Use a practical tool to turn this idea into a clearer starting point.
Check my data readiness