Deferred revenue in SaaS: how it works and where it breaks at scale.

Your MRR dashboard says growth is up. Your bank balance doesn't match it. Your auditor just asked why deferred revenue on the balance sheet doesn't reconcile with your active contract list, and nobody on the finance team can explain the gap without spending two days in a spreadsheet. This is the moment most subscription businesses first take deferred revenue seriously, usually right before a board meeting, a fundraise, or an audit, which is the worst possible time to be figuring it out for the first time.

Quick answer

Deferred revenue is a liability, not income. It's the cash a SaaS company has collected for a subscription it hasn't finished delivering yet. Under ASC 606, that cash gets recognized as revenue gradually, as the service is delivered, not all at once when the invoice is paid. For a company with simple monthly billing, this is a rounding error. For a company selling annual and multi-year contracts with upgrades, downgrades, and mid-term changes, it becomes one of the most error-prone line items on the balance sheet, and one of the first things investors and auditors check.

What deferred revenue actually is, and why it's a liability

When a customer pays $12,000 upfront for a 12-month subscription, the cash lands in the bank immediately. But the company hasn't earned that money yet: it still owes the customer eleven more months of service. Accounting standards treat that obligation as a liability called deferred revenue (sometimes "unearned revenue"), not as revenue, because if the company shut down the product tomorrow, it would owe most of that cash back.

Each month, as the service is delivered, a portion of the deferred revenue balance converts to recognized revenue on the income statement. By month 12, the liability is zero and the full $12,000 has been earned. This is the core mechanic behind ASC 606 (and its international equivalent, IFRS 15): revenue is recognized as performance obligations are satisfied, not when cash changes hands.

This is why a growing SaaS company's deferred revenue balance can climb even as the business is healthy. More prepaid annual contracts mean more unearned cash sitting on the balance sheet at any given moment, which is normal, and is in fact a sign of a business collecting cash ahead of delivery. The problem isn't that deferred revenue exists. The problem is when it stops reconciling to what customers actually have under contract.

How deferred revenue works under ASC 606

The basic monthly recognition mechanic

For a standard annual subscription paid upfront, the accounting is simple in principle: debit cash, credit deferred revenue on day one, then debit deferred revenue and credit revenue in equal monthly installments over the contract term. The complexity shows up in three places: multi-year contracts, contract modifications, and reconciliation at volume.

Multi-year contracts and the current/non-current split

A three-year contract billed upfront doesn't sit in a single deferred revenue account. Accounting standards require splitting the balance into current deferred revenue (the portion to be delivered in the next 12 months) and non-current deferred revenue (everything beyond that). As each year passes, a slice of the non-current balance rolls into current. Presenting the entire multi-year balance as current overstates near-term liquidity and understates the longer-term obligation, a mistake auditors flag quickly.

Contract modifications: the part that actually breaks

Annual subscriptions with no changes are the easy case. Real subscription businesses have upgrades, downgrades, seat changes, and mid-term plan switches happening constantly, and each one is a distinct accounting event. The first question is whether the change creates a new, separate performance obligation or modifies the existing one. Adding a new module at its standalone price is generally treated as a new contract layered on top of the old one, with its own recognition schedule. Changing the terms of the existing subscription (a tier change, a seat reduction, a mid-term price change) modifies the existing contract, which can require a catch-up adjustment to the deferred revenue balance and a revised schedule going forward.

At low volume, a finance team can track this by hand. At the volume most growth-stage SaaS companies actually process (hundreds of upgrades, downgrades, and plan switches a month once usage-based or tiered pricing is in play), manually updating a schedule for every modification is where deferred revenue accuracy usually falls apart.

Reconciliation: the period-end gut check

At every close, the deferred revenue balance on the books needs to tie back to the actual list of active contracts: every live subscription accounted for, every recognition schedule reflecting current contract terms, and every cancelled or churned contract cleared off the balance instead of left to linger. When a customer cancels mid-term, the remaining deferred revenue has to be resolved (either refunded or recognized, depending on what was actually delivered), not simply ignored. A reconciliation that doesn't tie out cleanly, or period-end adjustments that keep growing in size, is usually the first visible sign that the process is behind the business.

Where deferred revenue breaks in practice

The errors that show up in SaaS deferred revenue accounting fall into a small number of repeat categories, regardless of company size:

Recognizing revenue at billing instead of delivery. Common in companies that started on cash-basis bookkeeping and never fully rebuilt the process for accrual accounting. Revenue belongs to the period it's earned, not the period it's invoiced or collected.

Leaving deferred revenue on the books for churned customers. When a subscription cancels mid-term, the remaining balance has to be assessed and cleared, refunded if owed, recognized if the service was already delivered. Letting it sit overstates liabilities and is a common audit finding.

Not updating schedules for contract modifications. This is the single most common source of systematic drift. Every upgrade, downgrade, or plan switch is an accounting event; if it isn't processed, the deferred revenue balance quietly stops matching the underlying contracts.

Treating all deferred revenue as current. Multi-year prepaid deals need the current/non-current split. Skipping it misstates near-term liquidity on the balance sheet.

A billing system that isn't connected to the ledger. This is less a single error than the root cause behind most of the others. When contract data lives in a billing tool, a CRM, and a general ledger that don't talk to each other, every plan change has to be re-entered by hand somewhere. On a small customer base this is a manual-process annoyance. Past a few hundred active subscriptions with any mix of upgrades, downgrades, and usage-based components, it becomes a structural accuracy problem, not a workload problem.

A checklist for your own deferred revenue process

Before your next close, board update, or fundraising due diligence request, it's worth asking:

If more than one of these gets a shaky answer, the underlying issue usually isn't a training gap on the finance team. It's that billing events and revenue recognition live in different systems that were never wired together.

Why this keeps happening in a fragmented stack

Most early-stage SaaS companies start with Stripe (or a similar processor) for payments, a spreadsheet for revenue recognition, and a CRM for the customer relationship, three systems with no shared source of truth for what each active contract actually says. That works fine at 50 customers on simple monthly plans. It stops working once pricing gets more complex and volume grows, because every contract change becomes a manual translation exercise between systems, and translation is where errors get introduced. This is the same fragmented tool stack problem that shows up across billing operations generally, deferred revenue is just the line item where it becomes visible fastest, because auditors and investors look at it directly.

The fix isn't a better spreadsheet template. It's having subscription lifecycle events (a signup, an upgrade, a proration, a cancellation) generate their accounting entries automatically, in the same system that manages the contract, rather than requiring a second manual step. Revvly's proration handling for mid-cycle plan changes is built on this idea: a plan change is a single event that updates billing, usage, and the underlying revenue schedule together, instead of three separate updates that can drift out of sync. That doesn't replace a company's GL or accounting review, but it removes the most common failure point: schedules that don't get updated because the system doesn't know a contract changed. For a deeper look at how bookings, billings, and recognized revenue relate to each other as distinct numbers, see our breakdown of bookings versus billings versus revenue.

Frequently asked questions