Last month's revenue number changed after we closed the month. Is the report broken?
Probably not. Operational data keeps moving: jobs get invoiced late, work gets adjusted after a callback, refunds post, and ad platforms restate conversions for weeks. A report built on live data will restate. The fix is not freezing the pipeline, it is deciding policy — publish a snapshot at close for accountability, keep a live view for operations, and stamp every report with the moment it was computed.
What actually arrives late
- Invoices. Work completed on the 30th can be invoiced on the 4th, and whether it belongs to the old month depends on whether you report on completion or on invoice date.
- Adjustments. Callbacks, warranty rework and price corrections change the value of jobs that already closed.
- Ad platform restatement. Conversion data continues to fill in for days or weeks as delayed and modeled conversions are attributed back to the original click date.
- Manual corrections. Someone in the office fixes a miscoded job type in the second week of the following month.
Restatement is correctness and it reads as untrustworthiness
A pipeline that never restates is not more accurate; it is just frozen at a moment when the data was incomplete. But an executive who sees a number change is not thinking about pipeline design. They are thinking the reporting cannot be trusted, and once that happens the report stops being used.
The way out is to make movement expected instead of surprising. Show the as-of timestamp on every view. When a number restates, show both values and the reason. Movement you predicted is credible; movement you did not is not.
Snapshot and live view, side by side
Run both. The snapshot is taken at a fixed close date, stored immutably, and used for accountability, comparisons and anything tied to compensation. The live view is recomputed continuously and used to run the business today.
They will disagree, and that is fine as long as each is labeled. What is not fine is one number that quietly rewrites itself and is used for both purposes.
Measure your own settling curve
Every business has a period after which the numbers stop moving materially, and you can measure it rather than guess. Snapshot a month's total every day for sixty days and plot how much it changes. The curve flattens at some point, and that point is where your close date belongs.
In practice, a company that invoices quickly settles far sooner than one that batches billing weekly. Setting close before your curve flattens guarantees you will restate; setting it after means the number you publish is the number that stands. This is one of the first things we calibrate when building revenue reporting, and it is what keeps automated briefs from reporting a decline that is only a billing lag.
Topics: late-arriving data · reporting · restatement · data governance
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.