Building the 2027 Budget: A Driver-Based Framework

Why Start in Late Summer

The budget calendar for a December year-end runs backwards from board approval. If the board approves the 2027 budget in late November or December, the build needs to start in late summer to allow for the functional inputs, the iterations, and the review cycle. Starting in October compresses the build into the busiest part of the finance calendar and produces a rushed plan; starting in late August allows it to be built properly.

Late August is also when the H1 actuals and the mid-year reforecast are settled, so the build starts from a clean, current base rather than a stale one. The budget is an extrapolation from a known position — and the known position is only clean once the mid-year work is done.

Drivers, Not Last-Year-Plus

The fundamental choice is between two methodologies. Last-year-plus takes the prior-year actuals and applies a growth percentage — revenue up fifteen per cent, costs up ten per cent — line by line. It is fast and it is defensible-sounding, and it is almost always wrong, because it assumes the shape of the business does not change and it gives the board nothing to engage with.

Driver-based budgeting builds the plan from the underlying drivers: the revenue is MRR compounded at a net growth rate plus other revenue; the cost is fixed opex plus variable opex plus headcount-driven payroll. The budget becomes a model with inputs the board can interrogate — "what if growth is two points lower", "what if we delay the Q2 hires" — rather than a static set of numbers.

The Revenue Build

The revenue build starts from the current MRR baseline and compounds it forward at a net growth rate — gross new MRR growth less churn. Add other, non-recurring revenue as a separate line. The output is a monthly revenue projection that reflects the actual dynamics of the business rather than an annual growth assumption spread evenly.

The discipline is to ground the growth and churn assumptions in the actual recent trajectory, not in ambition. A budget that assumes a step-change in growth without a specific reason for it is a wish, not a plan. Where a step-change is genuinely expected — a new product, a new channel — model it explicitly as a driver change from a specific month, so the board sees the assumption and can test it.

The Cost Build

The cost build has three components. Fixed opex — rent, software, the costs that do not scale with revenue or headcount in the short term. Variable opex — the costs that scale with revenue, expressed as a percentage. And headcount-driven payroll — the largest line for most growth-stage companies, built from the headcount plan with fully-loaded costs and calendar-aware start dates.

The headcount plan is where the budget becomes a decision tool. Each planned hire is a line with a start date, a salary, and on-costs; the payroll cost flows from the plan. The board can then engage with the actual decisions — "delay these two Q2 hires and the runway extends by this much" — rather than debating an abstract cost-growth percentage. This is the driver-based forecast approach applied to the annual plan.

The Scenario Structure

A driver-based budget naturally supports scenarios, because the drivers can be flexed. Build three: a base case on the current trajectory, a downside where growth softens and churn rises, and an investment case where additional spend drives additional growth. The three scenarios give the board a range rather than a false-precision single number, and they make the fundraise-trigger conversation concrete — at what point in the downside does the runway require a raise.

The scenarios should differ in their driver inputs, not just their outputs. A downside that halves the growth rate and adds a churn point is interrogable; a downside that just multiplies the base case by 0.8 is not. The value is in the board being able to see and test the assumptions behind each scenario.

The Build Process

A workable build process from late August to board approval:

1. Late August: Confirm the current base from settled H1 actuals; agree the driver framework and the scenario structure.
2. September: Build the revenue and cost drivers; gather functional inputs (the headcount plan from each function, the opex plans).
3. Early October: Assemble the base-case budget; build the downside and investment scenarios.
4. Late October: ExCo review and iteration; refine the assumptions.
5. November: Board pre-read and discussion; final adjustments.
6. Late November / December: Board approval of the 2027 budget.

Key Takeaways

• Budget-build season starts in late summer for December year-ends, so a board-approved 2027 plan is ready by November or December. Starting in October produces a rushed plan.
• Start from a clean base — the H1 actuals and mid-year reforecast, settled by late August.
• Build on drivers, not last-year-plus-a-percent. A driver-based budget is a model the board can interrogate; a last-year-plus budget is a static document that is wrong on day one.
• Revenue is MRR compounded at net growth (growth less churn) plus other revenue; ground the assumptions in the actual trajectory, not ambition.
• Cost is fixed opex plus variable percentage plus headcount-driven payroll built from a dated hiring plan — which is where the board engages with real decisions.
• Build three scenarios that differ in their driver inputs, so the board can test assumptions and the fundraise-trigger conversation is concrete.
• A driver-based budget reforecasts in an afternoon all year, because the same model produces the budget and every subsequent reforecast.