a customer signs a $120k annual contract in january and wires the money. the founder sees the bank balance jump, posts the win on slack, and quietly upgrades the runway slide for the next board meeting. the actual revenue for january is $10k. the other $110k is a liability — money the company owes back if it can't deliver the service.
every saas founder has heard "deferred revenue" in an accountant's explanation that ended before they were sure what it meant. the distinction is not academic. it's the difference between thinking you have 12 months of runway and discovering, eight weeks before the round closes, that you have 7. the company that survives this confusion is the one that learned, before the audit, how to read both numbers — the cash balance the bank shows, and the runway shape the deferred-revenue waterfall actually implies.
the cash trap, in one company
a series a saas company has $3M in the bank, reported monthly net burn of $250k, and a runway slide that reads "12 months." the cfo presented it that way at the last board meeting. the founder repeats it on investor calls.
look at the balance sheet. $1.2M of that $3M is deferred revenue from annual contracts paid up front, sitting as a current liability because the service hasn't been delivered. the cash is in the account. the obligation is on the books. those two facts don't cancel — they coexist, and they break the runway number when read together.
the burn multiple looks fine — 2.5x against $100k of net new monthly arr. but it uses the reported net burn line, which already nets against revenue recognized this month from contracts paid up front in prior months. the cash that funded that recognized revenue arrived in january, not the month you're reading. on the cash-flow page, the company didn't collect it this month at all.
the corrected math reads: (cash − deferred revenue) ÷ net burn = ($3M − $1.2M) ÷ $250k = 7.2 months. five months of runway disappeared into a line item the cfo's presentation didn't include.
why the gap exists
deferred revenue is the cleanest example of an accounting truth that does not feel true. gaap recognizes revenue when you deliver service, not when the cash arrives. if you sell a 12-month contract for $120k in january, you recognize $10k/mo and the rest is a liability — because if the customer cancels in march, you owe back the unearned nine months. the cash is in the bank. the cash is also conditionally refundable.
founders read the cash balance and the income statement without reconciling them, because their tools don't make the reconciliation visible. stripe shows cash collected. the accounting platform shows revenue recognized. nothing on either screen shows the deferred-revenue bridge connecting the two. the gap is widest right after a strong annual-contract pull — the cfo opens the bank app, sees $3.4M instead of $2.9M, and pushes the runway slide out by two months. the diligence partner who pulls the balance sheet in october will undo that adjustment in thirty seconds.
the two failure modes
the math breaks in two places — once on the cash line, once on the burn line.
overstating cash is the boardroom version. "we have $3M, we burn $250k, that's 12 months." the math is correct against the wrong cash number. the right one is cash minus deferred revenue. if the company shut down tomorrow, those $1.2M of prepaid customers are first-in-line creditors, ahead of the founder's next paycheck.
understating cash burn is the subtler mistake, and the one that breaks fundraising. the reported net burn line nets expenses against revenue recognized — including revenue funded by cash collected in prior months. if you stop signing new annual contracts, the income statement still shows $100k/mo of recognized revenue for twelve months because the cash already came in. the actual cash burn over the next six months is materially higher than the p&l line says, because no new cash is offsetting it.
deferred revenue is the only line item on the balance sheet that looks like cash to founders and like a liability to investors — and the investors are right.
the corrected calculation, in plain math
true cash = bank balance − deferred revenue
true burn = operating expenses − new cash collected this month
true runway = true cash ÷ true burn
the first adjustment removes prepaid-but-undelivered cash from the runway base. the second strips out income-statement smoothing and asks the only question a cash-flow forecast cares about — how much came in this month, how much went out.
for our $3M / $1.2M / $250k example, true cash is $1.8M. if the company collected $200k of new cash this month and operating expenses were $350k, true burn is $150k, and true runway is $1.8M ÷ $150k = 12 months — same answer as the naive math, for the right reason.
now the bad month. if new cash collected drops to $50k for two quarters running — a sales-cycle wobble, a hiring slowdown at the buyer, anything — true burn climbs to $300k/mo and true runway becomes $1.8M ÷ $300k = 6 months. the runway number is far more sensitive to the new-cash line than to reported burn, and the founder watching only reported burn won't see the shift until quarter-end — twelve weeks too late.
what to report at the board meeting
a clean board pack shows cash on hand with deferred revenue called out as a memo line below — visible so nobody pretends it isn't there. the runway slide should carry two numbers: reported runway (the comforting one) and cash-adjusted runway (the honest one). investors should not need to ask which is which. the founder who shows both before the partner asks is the one who keeps the round's velocity.
how zift handles this
zift reads cash from your bank feed, deferred revenue from your stripe and accounting platform, and surfaces the cash-adjusted runway alongside the reported one — every fifteen minutes, with the deferred-revenue waterfall feeding into it. on monday morning the briefing names the contracts that earned out in the prior week, the new prepayments that came in, and the resulting shift in true cash runway.
if you're a finance lead at a series b team running multi-currency contracts or multi-entity revenue recognition, zift handles that too.
founders who read both numbers — the bank balance and the cash-adjusted runway — make decisions at the cadence of the truer one, which is the only cadence a series a balance sheet can actually afford.