Last month's report may change when a delayed record arrives or an earlier entry is corrected. That does not automatically mean the reporting system is broken. The important question is whether the report's rules explain what changed and which version a reader is seeing.
Related service: CRM, ERP and web application development- 01Identify when the event occurred.
- 02Record when the system learned about it.
- 03Apply the approved late-data rule.
- 04Recalculate or issue a revised view.
- 05Explain the changed records and totals.
SECTION 01
Choose the history the reader needs
A current operational view may incorporate every correction, while a published period snapshot may need to preserve what was available at a cutoff. Name those views clearly. Record the chosen timezone and the treatment of dates supplied without a time. Do not use whichever timestamp is easiest to query without checking the business meaning.
Apache Beam discusses late arrivals relative to event time and processing progress. PostgreSQL's transaction-isolation documentation describes consistent database snapshots during queries. These are different concepts: a consistent query does not establish that all real-world events have arrived. Completeness needs its own reporting rule.
SECTION 02
Illustrative example: a late service completion
Suppose a job completed on the final day of a month but its offline record reached the server two days later. A report based on completion date assigns it to the earlier month. A report based on receipt date assigns it to the later one. Both can be legitimate if their labels and purpose make the distinction explicit.
If the earlier period was already shared, the system might preserve the original snapshot and publish a revised operational total with a change note. The approved rule determines that choice. This example uses invented events and is not accounting advice; it demonstrates why late-arrival behavior belongs in a software reporting brief.
SECTION 03
Test revisions without erasing the explanation
Ask for samples covering a late new record, a corrected date, a cancellation and a duplicate resend. Verify that the same correction is not counted twice. Preserve sufficient source identity and version history to explain the change, with access and retention appropriate to the data.
Compare the dashboard, downloadable report and scheduled message for the same cutoff. A screen that updates silently while an exported file remains unchanged can confuse a review meeting. Start with a clearly documented correction window and exception path rather than promising immutable history and automatic restatement simultaneously. Handoff should show how an operator investigates a changed total and who approves a policy change.
SECTION 04
Frequently asked questions
Should historical totals never change?
That depends on the report. Distinguish a frozen published snapshot from a view that incorporates later corrections.
Does a database snapshot prove the data is complete?
No. It can provide a consistent read of stored data, but delayed source records may still be missing.
What should accompany a revised total?
A clear revision or cutoff label and a way for authorized users to trace the relevant changed records and rule.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Late data and event-time processingApache Beam
- Transaction isolation and snapshotsPostgreSQL
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy