Building Forward Burn From Your Headcount, Line by Line

A CFO at a Series B company divides $9M in the bank by last quarter's average monthly burn, gets fourteen months, and tells the board there's runway into next year. The number is wrong, and it's wrong in the direction that gets companies killed. The fix is building forward burn from your headcount — a bottoms-up construction of what the company will actually spend next month, not an average of what it spent while it was smaller.

Trailing burn is a rear-view mirror. It describes a company that no longer exists the moment you're hiring.

Why trailing burn lies while you grow

There are three ways to state a burn number, and they disagree by design.

Last month's burn is the most volatile. A single delayed Stripe payout or a quarterly SaaS renewal lands in one month and vanishes the next, and the figure swings 20% with no change in the underlying business.

Trailing three-month average smooths that noise. It's the default in most board decks, and it's the one that quietly lies. If you added four engineers over the quarter, the average includes two months where three of them weren't on payroll yet. You're dividing your cash by a burn rate the company has already outgrown.

Forward burn is the only one built for planning. It answers the question that actually matters — what will we spend next month, given who works here and what we've already committed to — rather than what we happened to spend across a window when the company was a different size.

The distinction is not academic. On a fast-hiring team, the gap between trailing-average runway and forward runway is routinely a full quarter. The board hears fourteen months; the honest number is eleven.

The bottoms-up build

Forward burn is not a formula you apply to a total. It's a stack you assemble line by line. Three layers.

Layer one: current headcount at full cost

Start with everyone on payroll today, at fully loaded cost — not base salary. Loaded means base plus payroll taxes (roughly 7.65% employer-side FICA up to the wage base), benefits, and the software and hardware that ride with a seat. The SHRM benchmark puts benefits load in the 25–40% range depending on plan generosity.

If your headcount model uses base salary and your P&L uses loaded cost, the two never reconcile, and every forecast inherits the gap. We've argued the case for making loaded comp match the books — it's the single reconciliation that keeps a headcount plan and a burn model speaking the same language.

Layer two: committed but not yet active

This is the layer trailing burn structurally cannot see. The engineer who signed an offer and starts in eight weeks is not in last month's actuals, is not in the three-month average, and is absolutely in next quarter's burn.

Every accepted offer with a start date belongs in the forward build from the date it lands, not the date the first paycheck clears. Same for the tooling contract you've signed but haven't been invoiced on, and the office expansion that closes next month. Committed spend is spend. The accrual view — the logic behind GAAP accrual accounting — exists precisely because cash timing misleads.

This is where headcount planning that protects runway does the heavy lifting: the plan isn't a record of hires already made, it's the forward layer of the burn model, and the two should never be maintained in separate spreadsheets.

Layer three: lumpy and non-monthly items

The items that don't recur monthly are the ones that blow up a naive forward model.

• Estimated quarterly tax payments. Federal estimated taxes hit four times a year, and a company that ignores them models four months too optimistically and eight months too pessimistically.
• Annual insurance and SaaS renewals that bill once and disproportionately.
• Delayed payment timing — payouts, collections, and vendor terms that shift cash across a month boundary without changing the economics.

Spread the annual items across the months they cover for burn purposes, but track the cash-out date separately so you don't get surprised on the day the actual payment clears.

Forward is correct, and fragile

Forward burn is analytically the right basis for planning. It is also the most fragile of the three methods, for the same reason it's the most accurate: it's built entirely from assumptions, and assumptions decay.

The trailing average has one virtue — it's made of facts. Nothing in it can be wrong tomorrow, because it already happened. The forward model has no such protection. Every line depends on a start date, a comp figure, a renewal date, a payment timing that was true when you built the model and may not be true now.

Consider what moves the zero-cash date. A single senior start date slips from March to May: two months of loaded comp fall out of the burn, and the zero-cash date moves out a couple of weeks. A payroll run adds a mid-cycle bonus you forgot to model: it moves the other way. Neither event shows up in a static spreadsheet until someone opens it and manually re-runs the numbers — and by then the board deck already went out with the old date.

This is the structural weakness of any burn model that lives in a static file. The moment reality diverges from the assumptions — and it diverges the day after you build it — the number decays silently. The fix isn't a better spreadsheet; it's a model wired to the systems where start dates, payroll runs, and payments actually change, so the forward burn re-derives itself when an input moves rather than waiting for a quarterly rebuild. Tools built on live source-system data rather than periodic exports close that gap; it's worth understanding what live financial data buys you before assuming a monthly refresh is good enough.

See how live headcount and burn stay in sync →

Once the build is solid, the next move is testing it against multiple hiring speeds — the discipline of modeling conservative, base, and aggressive cadences, where the same forward stack gets run three times and the runway spread tells you how much rope you actually have. And the whole exercise routes back through operations discipline: a forward burn model is only as good as the process that keeps its inputs current.