The Report That Changes When You Run It Again
Two people run the same report a week apart and get two different figures. Neither of them made a mistake, and the difference is not a bug — but a report that cannot be reproduced cannot be defended, and most of them cannot be reproduced.
Somebody brings last month's figures to a meeting. Somebody else brings the same report, run four days later, and the revenue line is different. The next twenty minutes are spent working out who is wrong, and the answer is nobody. The month did not change. The record of the month changed, because that is what records do — and if the report does not say which version of the month it was looking at, there is no way to tell a legitimate movement from an error.
This is the most common reporting failure in an operational system and it is almost never described as a failure. It gets described as "the numbers moved", as though the numbers were weather. They are not. There are exactly four mechanisms, all of them ordinary, all of them things you want your system to allow — and once you can name them, the report can be made reproducible without freezing anything.
Four ways last month keeps moving after last month ended
| Mechanism | What happens | Typical lag | Do you want to prevent it? |
|---|---|---|---|
| Backdated entry | A document is created now and dated into a period that has already been reported. | Days to weeks. | No. A supplier invoice that arrives late genuinely belongs to the month of the delivery. |
| Late arrival | The document existed but had not reached the system — sitting in an approval queue, a mailbox, or a field worker's bag. | Days to a month. | No, but you can measure the lag and shorten it. |
| Correction | An amount, a date or an account on an existing document is amended. | Any time. | Not entirely. You want errors fixed. You want to know one was fixed. |
| Reclassification | Nothing about the money changes; which bucket it is counted in does. A cost moves department, a customer moves segment, a project moves phase. | Months, sometimes years. | No — this is normal maintenance, and it is the one nobody thinks of. |
Notice that the honest answer in the last column is "no" four times. The instinct to stop the numbers moving is the wrong instinct, because every one of these mechanisms exists to make the record more accurate, not less. A system that forbade all four would give you perfectly stable reports about a month that never happened.
"As at" and "as of" are two different questions
Almost every reporting dispute is a collision between two questions that sound identical in English.
- What was true in July? — the transaction view. Everything dated in July, whenever it was entered. This answers "how did July go", and the answer keeps improving for weeks after July ends.
- What did we know about July on 1 August? — the entry view. Everything dated in July that had reached the system by the reporting moment. This answers "was the report we published defensible", and the answer never changes.
Both are correct. They are used by different people for different purposes: the first by anyone managing the business, the second by anyone defending a published figure. The failure is not choosing one — it is having a report that silently answers the first while its reader assumes the second, or a system that only supports one of them.
A report answers "what was true in July". Its reader usually assumes it answers "what did we say about July". Both are legitimate questions; only one of them is stable.
The practical test for whether your system supports both: pick a closed month and ask it for the figure as the figure stood on the day you published it. If the only available answer is "here it is as of right now", you have one view, not two, and every published figure you have ever issued is unreproducible.
Three stamps that make a report defensible
None of these requires freezing data, and all three are cheap. They are properties of the report output, not of the database.
-
The cutoff rule, written on the report
Not just the period — the rule. "Documents dated 1–31 July" and "documents dated 1–31 July and entered by 5 August" are different reports with the same title, and the title is what people quote. Put the rule in the header, not in somebody's memory of how the report was set up.
-
The run timestamp, to the minute
A date alone is not enough when a month-end close is happening, because the figure can move several times in one day. This is the single cheapest thing on the list and the most commonly missing: a report printed with no run time cannot be placed in sequence against any other copy of itself.
-
A statement of what moved since last time
The stamp that almost nobody implements and the one that ends the arguments. When a period has already been reported once, the second run should be able to say what changed and why — three backdated invoices, one correction, one department reclassification. Without it, every re-run is a fresh negotiation about whose printout is right.
The third stamp is the one to insist on
A cutoff rule and a timestamp let two people work out that their copies differ. Only a movement statement tells them why, and "why" is the entire content of the meeting they are about to have. It is also the honest test of whether a reporting layer is built on an audit trail or merely on a query: a system that cannot reconstruct a past state cannot produce this, and no amount of dashboard polish substitutes for it.
Period locks: blunt, unpopular, and the thing that works
The standard remedy is to lock a period once it has been reported, so nothing dated inside it can be created or amended. It is effective and it is genuinely disliked, because the first thing that happens after a lock is a legitimate document that has nowhere to go.
The resolution is not to skip the lock and it is not to unlock on request. It is to decide, in advance and in writing, what happens to a late document: it is dated into the open period with a reference to the period it economically belongs to. That decision is a policy question, not a software question, and a system's job is to make the resulting trail visible rather than to make the choice for you.
Two things make a lock survivable. A lock with an exception process that is logged is workable; a lock that can be lifted quietly is worse than no lock, because it produces the appearance of stability without the fact of it. And a lock at the reporting boundary rather than the accounting boundary — locking a month only once its figures have actually been published to somebody — avoids freezing periods nobody has yet relied on.
Three questions for whoever supplies your reporting
Separating a reporting layer from a query screen
Can I run this report as it stood on a date in the past?
What you are listening for
Either a demonstration, or a clear no.
How to read the answer
A clear no is a usable answer — you then know every published figure is a point-in-time artefact you must archive yourself. "The data is always current" is not an answer to this question; it is a restatement of the problem.
If I run last month twice, what tells me what changed in between?
What you are listening for
A named mechanism — a movement report, a change log, a version.
How to read the answer
A pause here means the answer is nothing, and that reproducing an old figure will be a manual reconstruction each time. Most systems pause.
What happens to an invoice dated into a locked period?
What you are listening for
A described route, including where the audit trail records it.
How to read the answer
"It cannot be entered" is incomplete — the document still exists in the real world. Ask where it goes, not whether it is blocked.
A routine that costs almost nothing
Applied once per reporting cycle
- Every report that leaves the building carries its cutoff rule and its run timestamp in the output itself — not in the email it was attached to.
- One figure per cycle is deliberately re-run a month later and the movement is examined. You are not looking for a small number; you are looking for a number you can explain.
- The lag between document date and entry date is measured, not assumed. It is the single best predictor of how much a published figure will move, and it is usually worse than the team believes.
- Reclassifications are recorded as events with a date, so a breakdown that changed can be explained without reconstructing anybody's reasoning from memory.
- Any lift of a period lock is logged with a reason, and the log is read by somebody who did not request the lift.
The short version
Reports move because records improve, and that is a feature. The defect is not the movement — it is publishing a figure with no record of the question it answered or the moment it answered it. Put the cutoff rule and the run time on the face of the report, and get a way to say what changed between two runs of the same period. Those three things convert an argument about whose printout is correct into a two-minute reconciliation, and they cost far less than the period lock most teams reach for first.
