Loading…
Loading…
A balance moved and nobody knows why. The difference between a system that can answer that and one that cannot is whether movements are stored as events.
Deferred revenue closed at $1.1 million. Last month it was $900,000. Somebody asks why.
The good version of this conversation takes thirty seconds:
Opening balance $900,000
Billings $400,000
Recognised ($250,000)
Contract modification $50,000
---------
Closing balance $1,100,000
The bad version takes a day, produces the same closing balance, and does not actually explain anything. It just re-derives the number from source and confirms it is what it was.
The difference between those two is not effort or skill. It is whether the movements were recorded as they happened or reconstructed afterwards.
A schedule maintained in a workbook holds state, not history. It knows the current position of every contract. It does not know that contract 4471 was modified on the 12th and that this is why the balance moved.
So when somebody asks why, the only available method is to compare: take last month's file, take this month's file, diff them, and interpret the differences. That works, sort of, and it has three problems.
It is slow. Diffing two workbooks with a few thousand rows and interpreting the result is genuinely hours of work.
It is lossy. Two changes that offset each other disappear entirely. A contract that was modified twice shows one net movement. A correction that reversed an error looks like no change at all.
It depends on having last month's file. Which depends on somebody having saved a copy, unedited, which is a habit rather than a control.
The alternative is to store what happened rather than only what is true now.
Each change to a schedule is an event: a type, a date, an amount, an affected contract, and a cause. Billings are events. Recognition is an event. A modification is an event with a pointer to the amendment that caused it.
The balance is then derived by summing events, and the rollforward is not something you construct. It is a query. Opening balance is the sum of events before the period, movements are the events within it, closing balance is the sum through the end. It ties by construction because both ends came from the same data.
This is the same structure that makes a forfeiture recordable without restating equity expense, and the same one that makes a lease modification a new measurement rather than a rewrite. Three different problems, one underlying rule.
The $50,000 in that rollforward is the interesting one, because it is the only line that needs explaining beyond its own label.
Stored as an event, it carries its cause: contract 4471, amendment dated the 12th, reallocation across obligations, schedule revised for months 9 to 20. Answering "what was that $50,000" is following a pointer.
Stored as a delta between two files, it carries nothing. It is a number that appeared, and explaining it means finding the amendment yourself, which means knowing an amendment existed, which is the thing you were trying to find out.
The audit case is the obvious one, and it is not the main one.
Recorded movements mean anomalies are visible while they are still cheap. A balance that moved because of six modifications is a different situation from one that moved because of one large billing, and a rollforward shows that immediately. A closing balance does not.
They also mean the close can be reviewed rather than just completed. A reviewer looking at four labelled movements can form a view in a minute. A reviewer looking at a closing balance can only confirm it matches the schedule, which confirms the arithmetic and nothing else.
You do not need a system to start. Take your largest schedule outside the ERP and add a movements log next to it: date, type, amount, contract, cause. Fill it in as changes happen rather than at period end.
Within two months you will be able to answer the question in thirty seconds, and you will have found at least one movement nobody would have been able to explain otherwise.
Not sure where your process sits?
Every journal traces back to the document it came from, assembled on request.