Late records after a monthly report: preserve the confirmed version or recalculate?
Keep confirmed reports and newly recalculated values distinguishable. Late records can change a past period without silently rewriting the report used for an earlier decision.
On this page5 sections
A late record does not force a choice between never changing history and overwriting every old number. Preserve a confirmed report as evidence of the information used at the time, calculate an updated view, and decide whether to publish a formal revision after reviewing the differences. Readers should be able to identify the version they are viewing rather than encounter a monthly total that changes without explanation.
Identify which time makes the record late
A transaction can have an event date, a source confirmation date, a platform ingestion date and a report publication date. Suppose a September transaction reaches the platform on 3 October. It may belong to September's business period while remaining absent from the September report that was already confirmed. Changing its ingestion date does not resolve the distinction. The dashboard should not decide accounting or business-period policy on behalf of the responsible team.
Late does not necessarily mean incorrect. Delayed confirmation, interface backlogs, cancellation and reissue, and manual correction have different causes. Establish the source record identity and version first. Otherwise, a revised document may be counted as an additional transaction instead of replacing the relevant contribution under the agreed rule.
Give confirmed and recalculated views different purposes
| View | Question answered | Information retained |
|---|---|---|
| Confirmed report | What information supported the earlier decision? | Version, cutoff, approver and definition |
| Latest recalculation | What is the result using currently known records? | Calculation time, source batch and changed scope |
| Approved revision | Which replacement has been reviewed and authorized? | Reason, differences and approval record |
Coexisting versions do not require every screen to display several competing totals. The business can choose a default. However, the label, export and detail view must carry the same version. Returning from a recalculated detail view should not silently switch the user to a confirmed total with a different basis.
Make the revision explainable
A difference list should distinguish additions, deletions, corrections to amounts or states, and changes of organizational attribution. Retain the source identifier, old and new values, affected period and reason. A changed total should lead to those records. If the source supplies only an overwritten aggregate, the platform cannot invent row-level evidence; disclose the available level of traceability before promising a detailed reconciliation.
Whether a difference requires republication should depend on its decision impact and the organization's procedures. Do not bury an arbitrary percentage threshold in code. Small changes that do not trigger republication can still be recorded. Where a revision is published, retain the earlier confirmed version instead of erasing the evidence that it existed.
Database history is not report approval history
The SQL Server temporal-table documentation describes current and history tables that preserve row versions for point-in-time analysis. It applies to the listed products, including SQL Server 2016 and later. System versioning time does not automatically replace the business event date, metric-definition version or report approval state.
The implementation therefore still needs to retain report filters, calculation rules, source batches and confirmation actions. A final screenshot alone can be difficult to reproduce. Database history alone can also be insufficient when no one knows which calculation or organizational scope produced the meeting report. Treat those as separate records in the delivery requirements rather than assuming one backup will explain everything.
Rehearse one complete revision
Confirm a report using test data, then introduce a late transaction belonging to that month, a cancellation and a correction. Verify that the original remains unchanged, the recalculation is correct, and each difference is traceable. Approval should create an identifiable new version. Check that exports and details do not mix versions, and that an account without publication authority cannot release the revision.
Why Do Data Dashboard, ERP and Excel Figures Differ, and How Can You Find the Cause? helps investigate why figures changed. Historical Replay in a Digital Twin: What the Timeline Needs concerns reconstructing event state over time; neither replaces a monthly-report confirmation policy. For data visualization development services, specify who confirms and revises a report, how long versions remain available, and when users are notified of a replacement. Retain the test revision so that the same process can be checked after future maintenance changes.