The one rule underneath all of it
Revenue is recognized when you deliver the service, not when the customer pays. Every complication in SaaS accounting is a variation on that sentence.
A customer paying $12,000 in January for a year of software has given you $12,000 in cash and $1,000 in January revenue. The other $11,000 is deferred revenue โ a liability, because you owe eleven more months of service.
Founders who track revenue on a cash basis systematically overstate good months and understate the rest. It also makes growth rates meaningless, because a single large annual prepayment looks like a step change rather than a timing event.
Why this matters before you raise
Deferred revenue is one of the first things diligence tests. A company reporting cash-basis revenue as ARR will have its numbers restated during the process โ usually downward, usually at the worst possible moment.
The five-step model, briefly
ASC 606 is the standard governing this. The formal version is long; the operational version is five questions.
- Identify the contract. What did both parties actually agree to, including auto-renewal terms?
- Identify performance obligations. What distinct things are you promising โ software access, implementation, support, training?
- Determine the transaction price. Total consideration, including variable amounts like usage overages.
- Allocate price to obligations. Split the total across each promise by standalone selling price.
- Recognize revenue as each obligation is satisfied. Over time for subscriptions, at a point in time for one-off deliverables.
The four cases that trip people up
Most SaaS businesses only need to get a handful of scenarios right.
- Annual prepay. Recognize ratably across the term. Cash in month one, revenue across twelve.
- Setup and implementation fees. Rarely a distinct obligation. If setup has no standalone value without the subscription, spread it over the expected customer life โ not the contract term, and not immediately.
- Usage overages. Variable consideration. Recognize in the period the usage occurs, and only to the extent a significant reversal is not probable.
- Multi-year contracts with escalators. Allocate total contract value across the full term rather than recognizing each year's invoice as billed. A 3-year deal at $100k/$110k/$120k recognizes at $110k a year, not as invoiced.
How this feeds your metrics
Recognition policy is upstream of nearly every SaaS metric investors ask about, which is why getting it right is a reporting decision rather than an accounting technicality.
- ARR should be built from recognized subscription revenue, not bookings or cash collected
- Gross margin needs hosting, support, and customer success in COGS โ not buried in operating expense
- Net revenue retention compares recognized revenue cohort over cohort, so a recognition change silently breaks the comparison
- Deferred revenue balance is itself a forward indicator โ a shrinking balance against flat bookings means contract terms are shortening
What to put in place now
You do not need audit-grade infrastructure at seed stage. You do need these four things, and they get materially harder to retrofit later.
- A written revenue recognition policy, even if it is one page
- A deferred revenue schedule reconciled monthly to the balance sheet
- Contract terms captured somewhere structured โ billing system or spreadsheet, not just PDFs
- A consistent ARR definition documented and used in every board deck without exception