SaaS · Saas

Burn Multiple for SaaS — A Field Guide

Burn Multiple for SaaS — A Field Guide is the work that turns a product into a business. The code is one thing; the business is the company that ships the code, sells it, supports.

John Kihiu12 min read

Burn multiple answers a question growth rate alone can't: how much cash did it cost to buy that growth? Two companies can post the same year-over-year ARR growth while one burns through cash twice as fast as the other to get there. Burn multiple exposes that difference in a single number, which is why investors lean on it heavily when a growth rate alone would flatter a capital-inefficient business.

The formula

Burn multiple is net burn divided by net new ARR over the same period: Burn Multiple = Net Burn / Net New ARR. Net burn is cash out minus cash in for the period (typically a quarter), and net new ARR is the increase in annual recurring revenue over that same period, including expansion and net of churn. A company that burns $2M in a quarter while adding $1M in net new ARR has a burn multiple of 2 — it costs two dollars of cash to buy one dollar of new annual recurring revenue.

SQL · QUARTERLY BURN MULTIPLE
WITH quarterly AS (
  SELECT
    quarter,
    cash_out - cash_in AS net_burn,
    ending_arr - LAG(ending_arr) OVER (ORDER BY quarter) AS net_new_arr
  FROM finance.quarterly_summary
)
SELECT
  quarter,
  net_burn,
  net_new_arr,
  ROUND(net_burn::numeric / NULLIF(net_new_arr, 0), 2) AS burn_multiple
FROM quarterly
ORDER BY quarter;

What the benchmark bands mean

David Sacks, who popularized the metric, proposed rough bands: under 1 is amazing (rare, usually a company approaching or past profitability while still growing fast), 1 to 1.5 is great, 1.5 to 2 is good, 2 to 3 is suspect, and above 3 is bad — cash is being converted into growth extremely inefficiently. These bands are a starting point, not a hard rule; an early-stage company investing heavily in product before go-to-market is expected to run a higher multiple than a company in its scaling phase, where efficient growth becomes the expectation.

Stage matters more than the raw number

A burn multiple of 2.5 at $500K ARR building out a first sales motion is a different story than the same 2.5 at $20M ARR with an established go-to-market engine. Compare the multiple against companies at a similar ARR stage, not against a single universal target.

Why it catches what growth rate hides

Growth rate alone rewards spending your way to a bigger top-line number regardless of cost. Burn multiple penalizes that directly, because it's a ratio, not a rate — a company that doubles its burn to grow 20% faster will see its burn multiple get worse even as its headline growth rate improves. This is exactly the scenario that made the metric popular after the 2021-2022 shift away from growth-at-all-costs: boards started asking not "how fast are we growing" but "how efficiently are we buying that growth."

Common miscalculations

The most frequent mistake is using gross new ARR instead of net new ARR in the denominator, which flatters the multiple by ignoring churn and contraction — a company adding $2M in new logos while losing $1M to churn has $1M net new ARR, not $2M. The second common mistake is using GAAP net income instead of actual net cash burn, which can differ substantially due to non-cash items like deferred revenue recognition or stock-based compensation. Use cash, not the income statement.

One quarter is noise; trend it

Burn multiple is volatile quarter to quarter — a single large enterprise deal closing in one quarter can swing net new ARR enough to make the multiple look great or terrible in isolation. Look at a trailing four-quarter or trailing-twelve-month view before drawing conclusions from any single period.

Wrapping up

Burn multiple is net burn over net new ARR — a capital-efficiency check that growth rate alone can't provide. Use net figures (post-churn ARR, actual cash burn), compare against companies at a similar stage rather than a fixed target, and trend it over several quarters rather than reacting to one.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.