every founder has a number they check obsessively and a number they avoid. the one they check is the bank balance. the one they avoid is the burn multiple. the avoided one is the honest one.
bank balance only tells you what already happened. burn multiple tells you whether the company is going to be okay. that's why founders look at the first one before they brush their teeth and pretend the second one is "more of a quarterly metric."
what burn multiple actually is
burn multiple = net cash burn ÷ net new arr added in the same period.
if you burned $300k this quarter and added $100k in net new arr, that's a burn multiple of 3.0. you spent three dollars of cash to add one dollar of recurring revenue. it tells you, in one number, how efficiently growth is converting into a business.
the standard reading, popularized by david sacks and now the gold standard in venture math:
- under 1x: amazing. you're either pre-product-market-fit and lucky, or post-pmf and dangerous to competitors.
- 1x – 1.5x: great.
- 1.5x – 2x: good.
- 2x – 3x: suspect. fix it before it becomes a problem.
- over 3x: bad. growth that isn't paying back. you're funding a vanity number with cash.
why founders avoid it
three reasons.
one: it includes the boring expenses. payroll, aws, salesforce, the linkedin campaign that didn't work, the contractor invoice nobody remembers approving. the bank balance lets you tell a story. burn multiple just counts the dollars.
two: it punishes growth that came from one-time stuff. closed a big enterprise deal with a $200k annual contract paid upfront? that's a beautiful month for cash, but only the recurring component gets counted in net new arr. burn multiple sees through the lump.
three: it's calculable to the dollar. there is no "well, it depends." most founders pause and estimate when you ask their cash position. nobody pauses and estimates their burn multiple, because most people aren't measuring it at all.
the version most people get wrong
a lot of founders compute it by taking gross burn, all expenses ignoring revenue, divided by arr added. wrong. that overcounts burn dramatically, because revenue is already offsetting it.
the correct calculation:
net burn = gross expenses − revenue collected (cash basis)
net new arr = (this period's mrr × 12) − (last period's mrr × 12)
burn multiple = net burn ÷ net new arr
if you can't pull this from your books in under five minutes, you don't have a burn multiple problem. you have a books problem, and the burn multiple is hiding behind it.
the right cadence
monthly. quarterly is too lagged. the founders who don't run out of money on accident look at this on the first of every month and ask: why did it move?
a healthy company sees fluctuation between 1.0x and 2.0x quarter to quarter. that's normal. one heavy hire, one slow month, you're at 2.5x for a quarter — fine. three quarters in a row at 2.5x+ is the entire conversation. that's the moment to either cut, or accept that growth has stalled and act on it.
the monthly cadence matters because most of the bad ones are slow drifts, not cliffs. burn climbs $20k a month from a hire here, a tool there. arr stays flat. by quarter end the multiple has crept from 1.8x to 2.6x and nobody noticed, because nobody was looking at it weekly. the number is only useful at the cadence where you'd still have time to react to it.
what you do with the number
three honest reactions.
- under 1.5x: ship more. spend more. you're underspending on growth and the math says so.
- 1.5x – 2.5x: keep moving. but pick one expense line and ask whether you'd add it again from scratch. there is always one.
- over 2.5x for two quarters: cut. not maybe-cut, not next-quarter-cut. now. salaries are 70-80% of most startup burn, so this is hard. doing it at month 4 looks like leadership. doing it at month 12 looks like a fire drill.
revenue can be a story; cash burned per dollar of new arr can't.
how zift handles this
zift computes burn multiple, mrr, runway, and net burn from your stripe + bank + payroll data, every fifteen minutes. on the first of the month you get the number, the delta from last month, and the line item that moved it. no spreadsheet. no manual reconciliation.
if you're a finance lead at a series a team and you need this for multiple entities or currencies, zift handles that too.
the founders who don't run out of money on accident aren't smarter. they just look at the number that doesn't lie, on a schedule.
