The Assumption Register That Makes a Budget Auditable
Six months into the year nobody remembers why the plan said what it said, unless somebody wrote it down at the time.
The register is the part of the budget that survives the year. The model does not. By the middle of the second quarter the model has been superseded by a reforecast, the tab everyone was arguing about has been renamed, and the only person who could explain the revenue build has moved on to something else.
What survives is a variance report, month after month, with a column that says the plan expected one thing and the business did another. Without a register, that column is answered by memory, and memory produces a specific and recognisable kind of answer: “I think we assumed a bit more volume in the second half.” That is not analysis. It is somebody being agreeable in a meeting.
So treat the register as an instrument rather than as documentation. It is what makes variance analysis possible at all, and a company that builds a careful model and no register has spent six weeks producing something nobody can interrogate.
What counts as an assumption
Not everything in a budget is an assumption, and a register that tries to capture everything becomes a hundred rows nobody reads. Three tests, and a row goes in only if it passes all three.
It drives a line. You can point at the account it moves. A statement about the company’s ambitions that does not connect to a number is a strategy note and belongs somewhere else.
A reasonable person could have chosen differently. If there is only one defensible answer, it is a fact or an arithmetic step, not an assumption. Your pay calendar is a fact. The number of pay periods in the year is arithmetic. The decision to fill a role in April rather than July is an assumption.
An event could prove it wrong. You can describe, in advance, the thing that would happen and tell you the assumption has failed. If nothing observable would ever falsify it, it is an opinion, and putting it in the register gives it a credibility it has not earned.
That third test is the one that does the pruning. Applied honestly, a first budget for a company at this size produces somewhere between fifteen and thirty rows, which is a document a person will actually read at the quarter.
The register itself
One sheet, one row per assumption, and these columns. Nothing here needs software.
| Column | What goes in it | Why it earns its place |
|---|---|---|
| Reference | A short unique code, and it never gets reused | This is what the variance commentary cites. Everything else in the register is useless without a handle to grab it by. |
| Statement | The assumption in one sentence, in plain language, in the words of the person who made it | A statement written in finance’s words is finance’s assumption. See below. |
| Type | Decision, estimate, observation or constraint | Four types behave differently at revisit time |
| Lines it drives | The accounts or the model tab | So that a variance on a line can be traced back the other way |
| Owner | A person, not a department | The person who answers when this one moves |
| Source | Where the number came from: a contract, a quote, a prior period, a supplier’s notice, a decision taken in a specific meeting, or a judgement | The most valuable column at the six month mark and the one most often left blank |
| Revisit trigger | The observable event that would make you look at this again | Turns the register from a record into an instrument |
| Revisit date | The point in the cycle it gets looked at anyway, even if the trigger has not fired | Triggers do not always fire on time |
| Direction if wrong | Which way the line moves, and whether the effect is one month or the rest of the year | Not a sensitivity analysis. A single arrow and a duration. |
| Status | Holding, breached, superseded, or retired | Updated at each reforecast, and the history is kept |
Two columns are usually argued about, so here is the case for each.
Direction if wrong, without a number. The temptation is to build a sensitivity table with percentages in it. At this size that is theatre: nobody has the data to say what a ten percent movement in an assumption does across a model with circular dependencies in it, and the table gets built once and never updated. An arrow and a duration are enough to sort the register by consequence, which is the only thing you actually do with it.
Status, kept as history rather than overwritten. When an assumption breaches, do not correct the statement. Mark it breached, date it, and write the new one as a new row with a new reference. A register that has been quietly edited into agreement with reality is worth nothing at the post mortem, and the post mortem is where a register pays for itself the second time.
The rule about who writes the statement
The person who supplied the number writes the assumption, in their own words. Finance transcribes nothing.
This sounds like a small procedural preference and it is the difference between a register that works and one that does not. When the controller writes the statement, what gets recorded is the controller’s understanding of what the sales lead meant, which is a translation, and translations lose exactly the part that turns out to matter. Six months later the assumption reads as sensible and the sales lead says “that is not quite what I said”, and they are usually right.
It also changes what gets written. A person recording their own assumption in their own words tends to include the condition attached to it. “We can deliver that volume as long as the second technician starts before the summer” is a far more useful row than “delivery capacity sufficient for plan”, and no finance function would ever have written the first version, because they did not know about the technician.
Practically: at the point a submission comes back, ask for the assumptions with it, in the submitter’s writing, one sentence each. Chase the ones that come back as adjectives.
Wiring it to the variance report
This is the step that makes it more than a filing exercise, and it takes one column in the reporting pack.
Every variance requiring commentary cites an assumption reference, or explicitly says that no assumption covered it.
The second answer is the more useful one. A variance nothing in the register anticipated means the register has a hole, and holes are informative: the company plans in categories that do not match the way it actually gets surprised. Two or three of those in a quarter and you know what to add before the next cycle. That feedback loop is the whole point, and it disappears the moment the commentary is allowed to say “timing” instead.
The management reporting pack is where this lives, and it is one extra column on a page that already exists. The cost is trivial. The reason it usually is not done is that the register does not exist to cite.
Revisit, by trigger and by sweep
Two mechanisms, and you need both.
Triggers are event-based and they are the point of the register. A supplier gives notice, a contract renews, a hire is deferred, a customer signals a change in volume, a lease event arrives. The trigger fires, somebody looks at the row, the status changes. Write the trigger as something a person would notice, not as something requiring a report to detect.
Sweeps are calendar-based and catch what the triggers missed. At each reforecast, read the register from top to bottom and mark every row. Holding, breached, superseded, retired. Sorted by consequence, this takes half an hour and it is the highest-value half hour in the reforecast, because it converts a discussion about numbers into a discussion about which of last year’s decisions have stopped being true.
Do not sweep monthly. A register reviewed twelve times a year gets reviewed properly about twice, and the other ten reviews teach everyone that the review is a formality.
Building one from a budget you have already finished
Most readers are not at the start of a cycle. The register can be reverse-engineered, in an afternoon, and it is worth doing even in the second half of a year.
- Sort the budget by absolute value, largest lines first.
- Take the top fifteen lines. Stop there. The tail does not need a register and adding it is how the exercise gets abandoned.
- For each line, ask the person who owns it one question: what has to be true for this number to be right? Write down what they say, in their words.
- Apply the three tests. Delete what fails. Roughly a third will.
- Fill in the source column, and accept that for a budget already built, some sources will honestly read “nobody remembers”. Write that. A blank looks like an oversight; “nobody remembers” is a finding, and it is the argument for doing this properly next cycle.
- Set the revisit triggers, and set them only where a genuine observable event exists.
- Add the reference column to next month’s variance commentary and start citing.
Step 5 is the one people want to skip. Resist. The count of rows where nobody remembers the source is the single best measure of how defensible the budget currently is, and it is a number you can show the owner.
What does not go in it
The register records assumptions about your own business. It does not record forecasts about the economy, and this is a boundary rather than a stylistic preference.
I do not publish a view on where rates, wages, prices or any market are going, and neither should your register. A row that says something about general conditions has borrowed a guess from somewhere else and given it the authority of your own plan, which is a bad trade: when it turns out wrong, the variance is unexplainable, because nobody in your company ever had a reason for it. If an external condition genuinely drives one of your lines, record the mechanism rather than the prediction. “Our fuel cost tracks the posted rate and we have no hedge or fixed price arrangement” is a true, useful, testable row. A prediction of what that rate will do is not, and a company that budgeted on one has no better answer in month seven than the company that did not budget at all.
The same applies to anything you would need somebody else’s professional judgement for. If a line depends on an accounting treatment that is genuinely uncertain, the register row says who is being asked and when, not what the answer will be.
One more exclusion, and it is procedural rather than topical. When an assumption changes, the old row stays as it was, marked and dated, and the new one gets a new reference. A register that agrees with reality because it was edited into agreement has nothing to teach at the year end, which is the point at which it was going to be worth the most. The close can carry an explanation as far as the number. Only the register carries it back to the decision, and only if the decision is still legible.
Nor do I populate one. Every row belongs to somebody in the company, and a register filled in by the finance function is the exact failure this piece is written against.