Net Burn Rate

Average monthly cash outflow before any inflows are netted off — essentially the company's monthly cost base in cash terms. Tracked alongside net burn because net burn alone can mask a structural problem when revenue is masking high cost. The board reads gross burn to understand the absolute cost commitment (mostly payroll, infra, COGS, sales spend) regardless of revenue mix. Common pitfall: founders often optimize the net burn narrative ("we cut burn 30%") via a one-time inflow without addressing the gross-burn cost base — the next quarter without that inflow re-exposes the underlying spend. Always present gross and net side-by-side.

Estimated number of months the company can operate at the current net burn before unrestricted cash reaches zero, holding everything else constant. The single most consequential survival input for venture-backed companies — it sets the urgency of every fundraising, hiring, and cost decision. Common pitfall: runway is often quoted off `finance.total_cash_in_bank` and a single-month spot-burn instead of operationally-available cash and a 3-month-trailing burn — the result is a runway that looks 2–4 months longer than it actually is when working capital tightens. Boards should ask which cash and which burn went into the calculation.

Sum of all bank account balances at the reporting cut-off, expressed in a single reporting currency after FX conversion. This is the gross top-of-house cash number — it does not net out restrictions, near-term liabilities, or commitments. The board reads this as the absolute denominator for runway and as a checksum against the cap table (capital raised − cumulative net burn ≈ cash). Common pitfall: founders sometimes report a USD figure that silently includes ILS/EUR accounts at stale FX rates — always reconcile against the bank-accounts list (per FX-aware MultiCurrencyAccountList) and tag the rate date.

The single past-period observed burn — gross and net — that anchors the forecast-scenario matrix. The "we just lived through this" baseline against which conservative / most-likely / best-case forecasts are projected. Differs from `finance.gross_burn_rate` and `finance.net_burn_rate` in being explicitly a point-in-time historical anchor with both components paired in one object, rather than the standalone monthly KPI values. Common pitfall: anchoring forecasts off a single month with a known one-off (large bill, prepayment received) bakes a distortion into all scenarios — pick a representative period or document the adjustment.

Forecast burn-rate matrix across three scenarios — conservative (defensive cost plan, slow revenue), mostLikely (current best-estimate), bestCase (aggressive investment with strong revenue) — with gross + net burn for each. Bound to the ScenarioBurnRateMatrix widget alongside the historical `finance.burn_rate_actual` anchor. The board reads this to understand what range of cash trajectories the company is planning for and which one management has chosen as the base case. Common pitfall: the three scenarios cluster tightly (all within ±10% of each other) — that's not three scenarios, it's one scenario with rounding error. Real scenarios should reflect meaningfully different operating decisions and produce visibly different runways.

Sum of cash actually received from operating activities for the period — customer collections (subscription, services, transactional revenue), refunds claimed back from vendors, and any operating tax credits. Excludes financing activities (debt draws, equity proceeds) and investing activities (asset sales, investment income). This is the numerator-side of the net-burn equation, and the cash-basis counterpart to recognized revenue on the P&L. Common pitfall: companies sometimes book annual SaaS prepayments here as a single-month inflow, masking the underlying monthly run-rate — split lumpy items out or smooth over a trailing 3 months.