WalkthroughBy Khaled Hawari

Normalising the Base Year Before You Budget From It

A budget built on last year's reported numbers inherits every one off event inside them, and by March nobody remembers which ones.

A budget built directly on last year’s reported numbers inherits everything that happened to last year. The legal fight, the systems migration, the customer who left in the tenth month, the two people who started in the eighth. All of it goes in, invisibly, because the reported figures are the only figures anyone has. By the third month of the new year somebody is explaining a variance and nobody in the room can remember which parts of the base were ordinary and which were not.

The fix is one exercise, done once, before a single budget line is written: take the reported result and turn it into a run rate, recording every adjustment and its reason on one page. That page is the bridge. It is the first tab of the budget model and it stays there all year, because every variance conversation eventually becomes a question about the base. It also earns a permanent line in the monthly reporting pack for the first year of a new plan, since a variance against a normalised base is unreadable by anyone who has not seen the adjustments.

This piece is the inside of a single row on the budget and reforecast calendar, the one where the baseline gets extracted. The build sequence, who is asked for what and when the plan locks, is set out there and is not repeated here.

The case, and the figures in it

What follows walks one company through the bridge end to end. It is a services company of about fifty people with a December year end, running a real budget for the first time, which is the situation this exercise is almost always for.

Every figure below is invented and round. They exist so the arithmetic of a bridge is legible and for no other reason. Nothing here is a past engagement and nothing here should be read as typical of anything.

Step one: decide which version of last year you are starting from

There are usually three versions of the prior year sitting in a company at this point, and they disagree.

The management accounts, as reported month by month during the year. The year end file after the external accountant’s adjusting entries. And the figures underlying the corporate return, which have their own adjustments for their own reasons.

Start from the year end file. It is the version that has been through an outside pair of eyes, it is the version a lender or a buyer will be handed, and it is the only one of the three that will not move again. Starting from the management accounts is the common choice because they are the ones everybody has been reading, and it means the base moves the moment the external file arrives, which is usually in the middle of the budget build.

All of that assumes the twelve months underneath the file were closed and locked as they went. Where they were not, this exercise is premature, and the honest answer is to fix the close and budget next year rather than normalise a set of numbers that is still moving.

For this company the year end file shows a reported operating result of 900,000 for the trailing twelve months. That is the top of the bridge and it does not get touched again.

Step two: remove the one off items

A one off is an item that would not appear in an ordinary year for this business. Two tests, and an item has to pass both.

Would it recur if next year were an ordinary year? If the answer is yes at any frequency, even every third year, it is not a one off. It is a lumpy recurring cost, and the right treatment is to average it across the cycle rather than remove it.

Can you point at the entries? A one off you cannot trace to specific journal entries or specific invoices is a recollection. It does not go in the bridge.

Here is what came out for this company.

Item Amount Direction Reason and evidence
Systems migration project 140,000 Add back Implementation and data migration costs for the ledger cutover, all invoiced by two named suppliers between the third and sixth months. The project is finished. Ongoing licence cost stays in the base
Legal and professional on a single dispute 60,000 Add back Traced to one matter, invoiced separately. Settled and closed before year end
Recruiting fees on the two senior hires 45,000 Add back Contingency fees on two specific placements. The salaries stay in the base and are dealt with in step three
Gain on disposal of vehicles 30,000 Deduct Sale of three vehicles at the fleet change. Income with no operating capacity behind it
Bad debt write-off, one customer 55,000 Add back A single insolvency, provided and written off in the same year. The general provision movement stays in the base
Government assistance received 80,000 Deduct A programme that has ended. The costs it subsidised are still in the base and still recurring, which is the whole reason this one has to come out

Net effect of the six: 190,000 added back. The bridge reads 900,000 plus 190,000, so 1,090,000.

Look at the fourth and sixth rows. Two of six adjustments make the base year look worse, and that ratio is the thing to check before anything else. If every adjustment on your bridge improves the run rate, you are not normalising. You are building a case, and somebody outside the company will eventually notice that the exercise only ever pointed one way.

The government assistance row is the one that gets argued. The instinct is to leave it in because the cash was real. The cash was real and the programme has ended, so the base year contains a year of subsidised costs presented at their subsidised level, and budgeting from it means budgeting a cost base the company will not have.

Step three: annualise the part year effects

This is the step that gets skipped, and it is usually larger than the one offs.

The one offs are things that happened and will not happen again. Part year effects are things that happened part way through and will now be there for the whole of next year. Both directions again, and the second direction is easy to forget because it feels like good news.

The rule: annualise to the exit rate, not to the average. What the business was running at as it left the year is the thing that carries forward. An average across twelve months is a description of a year that is over.

Effect Started or ended Annualised amount Direction
Two senior hires, started in the eighth month Started 120,000 additional cost for the four months they were not employed Deduct
Premises rent increase on renewal, seventh month Started 36,000 for the six months at the old rate Deduct
Customer lost in the tenth month Ended 200,000 of revenue that was in the base for ten months and will be in next year for none Deduct
Price change applied in the fourth month Started 90,000 for the three months billed at the old rate Add
Contract won in the sixth month, full year now running Started 150,000 for the six months before it began Add
Role vacant from the ninth month, not being replaced Ended 40,000 of salary that was in the base for eight months Add

Net effect: 76,000 deducted. The bridge reads 1,090,000 less 76,000, so 1,014,000.

The third row is the one that causes a fight, and it is worth being blunt about it. A customer lost in the tenth month is not a one off event to be added back. It is the new size of the business. Losing them was an event; not having them is the base. Companies argue for adding the lost revenue back on the reasoning that they will replace it, and replacing it is a plan, which belongs in the budget as new business with an owner and a date against it, not in the base year as if it had never gone.

Step four: apply the reclassifications

Now restate what is left onto the structure the ledger will report in next year. This step changes no totals at the operating result line and it changes almost every line above it, which is exactly why it has to be done before the budget rather than discovered during the first variance report.

Four kinds turn up:

Chart of accounts changes. If the account structure is being rebuilt, the base year moves onto the new structure with the same mapping table the rebuild uses. One mapping, used by both, or the budget and the comparatives will disagree.

Department and cost centre moves. A team that has moved from operations into delivery takes its costs with it, historically. Otherwise every departmental variance next year has a structural component nobody can explain.

Reclassification between cost lines. Costs that sat in direct delivery and belong in overhead, or the reverse. This one moves margin without moving the operating result, and it is the reason a company can budget a gross margin that looks like a change in the business when nothing has changed except where a cost is filed.

A policy change taking effect. A change in what gets capitalised rather than expensed, or a change in how a cost is allocated. The base year is restated as though the new policy had applied throughout, because the alternative is a first year of variances driven by an accounting decision.

For this company, the reclassifications moved cost between lines and left the operating result at 1,014,000. That is not a rounding convenience, it is what a reclassification is. Any reclassification that changes your bottom line is not a reclassification and belongs in step two with a reason attached.

The bridge, on one page

Line Amount
Reported operating result, year end file 900,000
One off items removed, net 190,000
Part year effects annualised, net (76,000)
Reclassifications applied Nil effect on the result
Normalised run rate, base year 1,014,000

Five lines, each backed by the detail above, each line item carrying its own reason and its own evidence. The budget starts from the bottom row, and it starts from there in the same account structure the reclassifications produced.

The rules that keep this honest

The bridge is published beside the reported figure, always. Not instead of it. The normalised run rate is a working number for planning, the reported result is the company’s actual reported result, and any document that shows one without the other is doing something other than planning. This single rule is what stops normalisation being an exercise in making a year look better, and it is not optional.

Every line has an owner who agreed it. The finance function prepares the bridge. The owner agrees each line, individually, before the budget build starts. A bridge nobody signed is a set of assumptions that will be relitigated in the second quarter, item by item, by whoever is unhappy with a variance.

Nothing goes in that you would not defend to a lender. The bridge does not stay inside the company. It shows up in a financing conversation, in a diligence request, in a conversation with the external accountant about why the plan does not look like the statements. Write it as though it will be read by someone who is looking for the weak line, because at some point it will be.

Keep the workings. Each adjustment references the entries, invoices or contracts behind it. A year later the number is remembered and the reason is not, and an adjustment with no supporting reference is indistinguishable from a plug.

What does not get normalised

Four things that people try to put in the bridge and should not.

A bad year caused by a decision that has not been reversed. If the pricing was wrong and the pricing has not changed, that is the base.

Anything justified by intention. “We will not spend that much on subcontractors next year” is a budget decision, and it belongs in the budget, where it will have an owner and be scored. In the bridge it is an adjustment with no event behind it.

Seasonality. The base year is twelve months, so it already contains one of everything. Normalising for a slow quarter is normalising away the business.

Owner compensation, unless the change is real and documented. Restating owner pay to a market rate is a legitimate exercise for a specific purpose, usually a transaction or a lender’s covenant definition, and it should be done there, once, with the reason stated. Doing it quietly in a budget base year produces a run rate the company will never actually achieve and a plan whose payroll line does not match its own payroll.

What we do not do

We do not normalise a base year off management accounts that have not been through the year end file, because the base will move under the budget while it is being built.

We do not accept a one off adjustment without the entries behind it, including the ones we are told are obvious.

We do not build a bridge that only moves in one direction. If a first pass produces nothing but add-backs, the pass is not finished, and the missing items are usually the favourable part year effects.

And we do not publish a normalised run rate on its own. It travels with the reported result and with the bridge between them, in the same document, every time it is shown to anyone.

MoreOther working documents

If this keeps failing in the same place.

A document that has to be re-explained every period is a process problem rather than a documentation problem. That is the point at which handing the function over is cheaper than fixing it again.