Building an Annual Operating Plan From the Ledger Up

A plan exists to be compared with what actually happened, in the monthly pack, against a close that produced the actuals on a known date. That is the whole function. Everything else a planning exercise produces, the alignment, the conversations, the shared view of the year, is a by-product of a document that will later be held against reality line by line.

Which means the plan has to be built in the shape the ledger reports in, from the first cell. Not translated into that shape afterwards. Most operating plans at this size are built in the shape of the management team’s conversation, by initiative, by product, by growth area, by whatever the owner has been thinking about, and then mapped to account codes in the last week by one person under time pressure. That mapping is the single most fragile artefact in the whole exercise, it lives in one head or one hidden tab, and it stops being maintained the first time the plan is amended.

Build it the other way round. The model is account-level from the start, and the version for the conversation is generated from it. A view can always be produced from a plan that ties to the ledger. A plan that does not tie to the ledger cannot be made to tie later, at any price anyone is willing to pay.

The build itself is done by the finance lead rather than delegated to whoever has spreadsheet time, because most of the work is deciding what locks when and holding that line against people who would rather reopen an earlier stage.

Two things this piece does not cover. The timing of the build, who is asked for what and when the plan locks, is the budget and reforecast calendar. The clean-up of the prior year that this build starts from is normalising the base year. This is the structure in between.

The unit of the plan is an account, a department and a month

Every line in the model is a general ledger account code, a department or cost centre code, and a period. Not a category. Not a heading. Not “marketing”.

The test is mechanical and it takes five minutes. Export the plan’s line identifiers, export the ledger’s account list, and check that every plan line maps to exactly one account and that no account with activity is missing from the plan. If the ledger has three accounts where the plan has one line, a variance report on those accounts cannot be produced without a manual bridge, and a manual bridge is a thing one person maintains until they are busy.

Then the harder rule, which is about dimensions.

Do not plan on a dimension the ledger does not post. This is where more plans die than anywhere else. A company decides to plan by product line, or by site, or by customer segment, because that is how the business is actually run and it is a completely reasonable thing to want. The ledger does not tag transactions with any of those. So for the whole of the following year, every variance conversation about product line requires somebody to rebuild the actuals by hand from a report that does not exist.

There are only two honest responses. Either add the dimension to the ledger before the plan is built, tag it going forward, and accept that comparatives will not have it. Or plan on the dimensions the ledger has. What does not work is planning on a dimension nobody posts and assuming the reporting will be sorted out later.

The four layers, and the rule that one number is typed once

The model has four layers and they do not mix. This is unglamorous and it is the difference between a model that survives three revisions and one that becomes untrustworthy after the second.

Layer	What lives there	What must never be there
Assumptions	Every input a human decided: rates, volumes, headcount, start months, renewal assumptions, percentage uplifts. Each with a name against it and a one line note on where it came from	Anything calculated
Drivers	The mechanics that turn assumptions into account movements. Loaded cost formulas, a revenue build, a working capital conversion, an allocation basis	A hardcoded number
Account build	The account, department and month grid. Every cell is a formula reading the layers above	A typed figure. A typed figure in this layer is invisible and it will be wrong within two revisions
Output	The statements, the cash view, the departmental packs, the board view, anything anyone actually reads	Any calculation not already done below it

The rule that enforces all four: every number a person decided appears exactly once, on the assumptions layer, with their name beside it. When the owner changes the hiring plan in draft two, one cell changes. If a headcount number is typed into six places because six schedules needed it, the plan is no longer a model, it is a set of statements that agreed with each other on the day they were built.

Run one check before the plan locks. Search the account build layer for any cell containing a typed number rather than a reference. In a model built properly the count is nil. In most first models it is somewhere in the dozens, and each one is a place where the plan will quietly stop agreeing with itself.

The build order, and what locks at each stage

Sequence matters because each stage is built on the one before it, and reopening an earlier stage invalidates everything downstream. So each stage closes before the next opens, and closing means somebody agreed it.

Stage	What is built	What locks	What may still move	Who signs
1. Base year	The normalised run rate, on next year’s account structure, with the bridge attached	The starting point. Nothing after this stage may adjust the base	Nothing. If the base is wrong, the build stops and restarts here	Owner, line by line on the bridge
2. Structure	The account and department grid, the dimension decision, the mapping to the ledger	The shape. No new plan lines after this without a mapping decision	Individual amounts, all of them	Finance lead
3. Drivers	The mechanics: how revenue is built, how payroll is costed, how variable costs move, how working capital converts	The method. Arguments after this are about inputs, not about how the model works	Every assumption feeding the drivers	Owner agrees the revenue method, finance owns the rest
4. Committed costs	Leases, insurance, software, contracted services, debt service, anything with a signed document behind it	Nothing, these are facts. They are built rather than agreed	Only if a contract changes	Finance lead, from the contract register
5. Headcount	The dated hiring plan, by role, by month, at fully loaded cost	The plan, once the owner decides it	Start months, until the plan locks	Owner
6. Department input	Discretionary cost submissions, argued against the pre-filled baseline	Each department’s total, once returned and reviewed	Reallocation within a department	Budget holders, then finance
7. Consolidation	The full model: result, balance sheet, cash, capital, covenant projection	Nothing yet. This is the draft that shows the gap	Everything	Nobody yet
8. Decisions	The gap closed by decisions with names and dates against them	The decisions, in writing	Nothing after this	Owner
9. Load and prove	The plan in the ledger by account, department and month, then exported back and tied to the model	The plan for the year	Nothing. From here it is a reforecast	Owner signs, finance loads

Stage four is the one companies skip, and skipping it is why department submissions come back containing rent. Committed costs are facts sitting in signed documents, and asking a manager to estimate a number that exists on a lease is asking them to be wrong. Build them from the contract register, exclude them from the submission templates, and tell the budget holders they have been excluded so nobody assumes they were forgotten.

Stage five sits between the two for a reason. Headcount is the largest single decision in most plans at this size and it is neither a fact nor a discretionary submission. It is a decision the owner makes, once, in its own conversation, and everything downstream depends on the answer.

Building the cost side from documents rather than opinions

Three categories, and they are built differently. Treating them the same way is what produces a plan where the fixed costs are guesses and the discretionary costs are precise.

Contracted. Leases, insurance, software subscriptions, maintenance agreements, financing. Each one is read off its document, into the month it falls, with the renewal date noted. Where a contract renews mid-year and the new price is unknown, the assumption goes on the assumptions layer with a name against it, so that when the renewal comes in the plan can be scored against it.

Payroll. By person for existing staff and by role for planned hires, at fully loaded cost. The loading is a formula on the driver layer, not a percentage typed into the payroll schedule, because the components move independently and at different points in the year. Phase it on the actual pay calendar, including the months carrying an extra run, and include what the company actually pays on top of salary in your province rather than a rounded uplift borrowed from somewhere else.

Variable and discretionary. These are the only two that belong in a department submission. Variable costs move on a driver, so what the budget holder is really agreeing is the driver relationship, not the annual total. Discretionary costs are a decision about what the department will do, and the submission is where that decision gets stated.

Pre-fill the submission with the department’s own normalised baseline. A blank template comes back late, and it comes back as a wish list. A pre-filled one comes back as an argument with the baseline, and an argument with the baseline is exactly the conversation worth having.

The plan does not stop at the operating result

A plan that ends at the operating result is a profit and loss exercise wearing a bigger name, and it cannot answer the question the owner will actually ask in month five, which is about cash.

Four more pieces, each built from the model rather than beside it.

Working capital. Receivable and payable conversion on the same drivers as revenue and purchases, so that a change in the revenue assumption moves the cash line automatically. If working capital is a separate typed schedule, it will be right in the version that locked and wrong in every version after.

Capital. By month of commitment, with the cash effect in the month of payment, which is frequently a different month. Split funded from unfunded if you have a facility, because the covenant definitions will care about the split.

Debt service. From the amortisation schedules, principal and interest separately. Not from last year’s interest expense with a percentage applied.

Covenant projection. If there is a facility with tests in it, project each test to each test date inside the plan, using the agreement’s own definitions rather than the ratio’s ordinary meaning. A plan that passes on the operating result and fails a covenant in the third quarter is a plan that needs a decision now rather than a discovery later.

Loading it, and the proof nobody performs

The last stage is the one treated as administrative, and it is where a well-built plan gets damaged.

Load the plan into the ledger by account, by department, by month. Not as an annual figure divided by twelve. Then perform the proof: export the loaded budget back out of the accounting system, total it by account and by month, and tie it to the model.

That takes about twenty minutes and almost nobody does it. The failures it catches are ordinary and expensive. A department code that did not exist in the ledger, so its lines went to the default. A month that loaded to period thirteen. An account that was renamed after the mapping was built. A sign convention that flipped on the income accounts. Each of those produces a variance report in the first month of the year that looks like a business problem and is a load error, and the credibility cost of the first wrong variance report is much higher than the twenty minutes.

Versioning, so that next year’s build has something to learn from

Every version of the model is dated and kept. Not overwritten. When a version changes, one line records which assumption moved and who moved it.

This costs almost nothing during the build and it is the only thing that makes the post mortem possible. At the end of the year, the question worth answering is not whether the plan was right. It is which assumptions were wrong at the time they were written, which is a different and much smaller list, and you can only separate the two if you can see what was assumed and when.

What we do not do

We do not build a plan on a dimension the ledger does not post, and we say so at the point it is proposed rather than delivering a plan that cannot be reported against.

We do not name a planning product. At this size a properly built spreadsheet with four separated layers beats a planning tool implemented badly, and the tool decision is a real decision that should be made after a company has built its plan by hand at least once and knows what it actually needs. Choosing the tool first is choosing a structure before you know your own requirements.

We do not accept a department submission containing rent, insurance or debt service, because those are facts and a budget holder should not be asked to estimate them.

We do not load a plan into a ledger without exporting it back out and tying it.

And we do not carry a typed number in the calculation layer, including the ones somebody is confident about. Those are the cells that are still there, unchanged, in the version everyone is arguing about in the third quarter.