How to calculate burn rate in SQL

What is burn rate and why it matters

In a venture-backed startup, burn rate is the single most important survival metric. It answers a question every CEO and board member asks within ten minutes of any check-in: how fast are we spending the bank account, and how long does the bank account last? Everything else — growth rate, retention, NPS — only matters if the company is still around to measure it. When a finance analyst joins a Stripe-stage company, Snowflake, or a pre-seed team out of Y Combinator, burn is the first dashboard they own.

Picture a concrete scenario. Friday afternoon, the CEO pings you on Slack: "Board call Monday. Need our trailing three-month net burn, runway at current pace, and what runway looks like if we slow hiring." Your only input is a transactions table from the corporate bank and a payroll export. By Sunday night you need a number the CFO can defend. A runway figure six months too generous and the company underestimates urgency; six months too conservative and leadership panics and cuts headcount that did not need to be cut. Burn is one of those metrics where the math is easy and the framing is hard.

Burn rate also sits at the boundary between accounting and analytics. Accountants think in accrual: revenue earned in a period, expenses matched to it. Operators want cash: dollars leaving the bank. For runway, cash always wins, because banks do not accept accruals as payment.

The SQL formula

The cleanest input is a monthly cash flow table with three columns: month, total expenses paid in that month, and total revenue collected in that month. If your finance team already maintains that table, the query is short.

SELECT
    month,
    expenses                       AS gross_burn,
    expenses - revenue             AS net_burn,
    revenue
FROM cash_flow
ORDER BY month;

Most teams do not have a clean cash flow table on day one. What they have is a transactions feed from the corporate bank, a payroll export from Gusto or Rippling, and credit card statements from Brex or Ramp. The first job of the burn analyst is to roll those up. Assuming a unified bank_transactions table where outflows are stored as negative amounts, the monthly aggregation looks like this.

SELECT
    DATE_TRUNC('month', txn_date)                                  AS month,
    SUM(CASE WHEN amount < 0 THEN -amount ELSE 0 END)              AS gross_burn,
    SUM(CASE WHEN amount > 0 THEN amount  ELSE 0 END)              AS inflow,
    SUM(CASE WHEN amount < 0 THEN -amount ELSE 0 END)
      - SUM(CASE WHEN amount > 0 THEN amount ELSE 0 END)           AS net_burn
FROM bank_transactions
GROUP BY 1
ORDER BY 1;

A few things to notice. We flip the sign on outflows so gross burn reads as a positive number — boards hate negative numbers that mean "good." We treat any positive amount as inflow, which conflates revenue with refunds and one-off events like fundraise wires; in production you almost always need a category column to split true revenue from financing inflows. And we use DATE_TRUNC so the bucket is calendar months, not rolling 30-day windows.

For a richer view, separate operating outflows from financing outflows. A wire to pay down a SaaS credit line is technically an outflow, but if you bucket it as burn the trend will look spiky and meaningless.

SELECT
    DATE_TRUNC('month', txn_date)                                  AS month,
    SUM(CASE WHEN category = 'operating' AND amount < 0
             THEN -amount ELSE 0 END)                              AS operating_burn,
    SUM(CASE WHEN category = 'financing' AND amount < 0
             THEN -amount ELSE 0 END)                              AS financing_outflow,
    SUM(CASE WHEN category = 'revenue'   AND amount > 0
             THEN amount  ELSE 0 END)                              AS revenue
FROM bank_transactions
GROUP BY 1
ORDER BY 1;

Once you have monthly burn, the rest of the analysis — runway, trailing average, scenario modeling — is just arithmetic on top of these numbers.

Gross vs net burn

Gross burn is the sum of every dollar that left the bank for operating purposes in a period. Payroll, rent, cloud bills on AWS or Vercel, contract recruiters, the SaaS stack — every operational outflow rolls up into gross burn. It is the right number for stress-testing what happens if revenue evaporates.

Net burn is gross burn minus the cash actually collected from customers in the same period. For a pre-revenue startup, net burn equals gross burn. For a Series B SaaS company doing two million dollars a month in collected ARR, net burn can be dramatically lower, sometimes close to zero. A company that collects more cash than it spends is "cash flow positive" — its net burn is negative. Board decks write this as "net burn: $(180k)" with parentheses, a hangover from accounting that confuses everyone the first time they see it.

Both numbers matter because they answer different questions. Gross burn answers "how much do we need if customers stop paying tomorrow?" Net burn answers "given current revenue, how fast is the bank shrinking?" Runway calculations use net burn; sensitivity analysis uses gross.

Runway

Runway is the number of months the company can keep operating at current net burn before cash hits zero. The math is brutally simple: cash balance divided by net burn. Where it gets interesting is which burn number you divide by. A single month of burn can be wildly unrepresentative — December always looks low because nobody hires over the holidays, March looks high if the annual offsite hit that month. A trailing three-month or six-month average smooths the noise.

WITH monthly AS (
    SELECT
        DATE_TRUNC('month', txn_date)                              AS month,
        SUM(CASE WHEN amount < 0 THEN -amount ELSE 0 END)
          - SUM(CASE WHEN amount > 0 THEN amount ELSE 0 END)       AS net_burn
    FROM bank_transactions
    GROUP BY 1
),
ranked AS (
    SELECT
        month,
        net_burn,
        AVG(net_burn) OVER (
            ORDER BY month
            ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
        )                                                          AS net_burn_3m,
        ROW_NUMBER() OVER (ORDER BY month DESC)                    AS rn
    FROM monthly
)
SELECT
    m.month,
    m.net_burn_3m,
    b.cash_balance,
    b.cash_balance::NUMERIC / NULLIF(m.net_burn_3m, 0)             AS runway_months
FROM ranked m
JOIN balance_snapshots b
  ON DATE_TRUNC('month', b.snapshot_date) = m.month
WHERE m.rn = 1;

The window function gives a trailing three-month average that updates each month. Joining to balance_snapshots gives the latest cash on hand. The NULLIF guard handles the rare case where net burn is zero — division by zero would otherwise blow up the query. For a company that just turned cash-flow positive, runway is mathematically infinite; report that as "cash-flow positive, not applicable" rather than as a number.

A more honest runway query carries forward a forecast. If next quarter has hiring plans baked into the headcount roadmap, project net burn upward and divide cash by the projected number instead of the trailing one. That version makes board decks; the trailing-average version is the weekly internal pulse.

Common pitfalls

The first trap is treating one-time expenses as recurring burn. A company that buys a year of office furniture in May will show a $40,000 spike in May's gross burn. Compute runway off that month and the answer is wrong in both directions: too pessimistic now, too optimistic later. The fix is to maintain an "adjusted burn" view that excludes non-recurring categories. Real finance teams keep a list of what counts as one-time — furniture, legal fees for a financing round, equipment purchases — and tag those transactions explicitly.

The second trap is mixing accrual and cash numbers in the same calculation. If your PnL says the company lost $100,000 in March but the bank dropped by $130,000, the gap is timing — prepaid rent, deferred revenue, expenses booked but not yet paid. Runway is a cash concept. Always use cash outflows, not PnL net loss. Confusing the two is the most common interview red flag for finance analyst roles.

The third trap is misreading the sign on net burn. Negative net burn means the company brought in more cash than it spent — a good thing. But "negative" sounds bad in plain English, and executives can interpret "burn is negative this month" as a warning rather than a celebration. Agree on terminology up front: some teams report "net cash generation" instead, others stick with parentheses notation. Pick one convention and use it everywhere.

The fourth trap is calendar-day differences. February has 28 days, July has 31. Raw monthly sums make February look artificially cheap and July artificially expensive even if per-day spending is identical. For comparative analytics, normalize to a per-day burn and multiply by 30. For runway this matters less, because the absolute number is what the cash actually does.

The fifth trap is computing runway off a single month. A seasonal spike, a one-time bonus, or a delayed customer payment can swing a month by 30 percent in either direction. Three-month or six-month trailing averages are the standard. Anything shorter is noise; anything longer fails to reflect recent reality, especially if the company has been growing or cutting aggressively.

Optimization tips

Burn rate queries run against transaction tables that grow indefinitely. Two patterns keep performance reasonable. The first is partitioning the transactions table by month. Snowflake, BigQuery, Databricks, and Redshift all support partition pruning on a date column. With monthly partitions, every burn query that filters by month range only scans the partitions it needs.

The second pattern is a materialized monthly rollup. The raw transactions table might have billions of rows after a few years. A monthly aggregation — one row per month per category — is a few hundred rows even after a decade. Refresh it nightly with an incremental job, and every dashboard query reads from the rollup in milliseconds.

For exploratory analysis where rules might change, keep the rollup but join back to the raw feed for the current and prior month only. Any change to category mapping should be retroactive — re-run the historical rollup or you end up with inconsistent burn numbers across periods, which is impossible to defend in a board meeting.

Finally, watch window functions over full history when you only need recent months. The ROWS BETWEEN 2 PRECEDING AND CURRENT ROW clause limits the frame, but the optimizer still has to sort the full set unless you push a date filter into a CTE first.

Related reading

• How to calculate ARR in SQL
• How to calculate ARR growth in SQL
• How to calculate blended CAC in SQL
• SQL window functions interview questions

If you want to drill SQL questions like burn rate, runway, and cohort revenue every day, NAILDD is launching with 500+ SQL problems built exactly around finance and product analytics interview patterns.

FAQ

What burn rate is considered healthy?

It depends on stage and funding. A pre-seed company with $1M raised should burn $20k-$50k per month — enough to keep founders alive and pay for cloud and tools. A Series A with $10M-$15M typically burns $200k-$500k per month while scaling the team. Series B and later, with $30M+ raised, often burns $500k-$2M per month as engineering and go-to-market expand. The number that matters more than absolute burn is the ratio of burn to remaining cash, which gives runway.

How much runway is enough?

The industry rule of thumb is 18 months as comfortable, 24 as plenty, and anything below 12 as the trigger to start a fundraise. Below six months you are in survival mode and every spending decision is a runway decision. Public market downturns push these higher because fundraises take longer. Always plan for a fundraise taking three to six months from first meeting to wire.

How do companies actually cut burn?

The first lever is headcount, because payroll is 60-70% of total burn in most tech companies. Layoffs are blunt; hiring freezes are gentler but slower. The second lever is marketing — paid acquisition can be cut overnight without breaking the product. The third is SaaS stack and office costs. The fourth is renegotiating debt or extending payable terms with suppliers. Almost no company cuts engineering tools or cloud aggressively because those have strong returns.

Is rising burn a bad sign?

Not necessarily. If revenue is growing faster than burn, unit economics are improving even as absolute spend rises. The metric that captures this is "burn multiple" — net burn divided by net new ARR. Below one means more new revenue than burn, which is excellent. Above three is a warning that growth is inefficient. Rising gross burn with flat revenue is unambiguously bad; rising burn with proportionally rising revenue is normal scaling.

How does bootstrapped burn differ from VC-backed?

Bootstrapped companies keep gross burn very low — often under $50k per month even at meaningful scale — and aim to be cash-flow positive within months of launch. VC-backed companies treat burn as an investment in growth, spending ahead of revenue to capture market share. Both work; the failure mode is mixing them, where a company raises VC money and then operates with bootstrap-level caution, wasting both the capital and the time it bought.