Key takeaways
- The number one cause of stalled SaaS diligence: revenue recognized when cash was received instead of when it was earned. In one Debit client intake, books showed $1.2M in revenue where correctly deferred contracts put it closer to $890K.
- A prepaid annual contract is a liability at the moment of receipt — deferred revenue — not revenue. It only becomes revenue ratably, as the service is delivered.
- ASC 606’s five-step model governs when revenue counts: identify the contract, identify performance obligations, determine the price, allocate the price, recognize as obligations are satisfied.
- Multi-element contracts (software + onboarding, for example) need separate recognition schedules per element — bundling them into one ratable number is one of the most common ASC 606 errors.
Step two in the diligence order — the revenue schedule — is where most SaaS diligence slows down or stops. The reason is almost always the same: the company recognized revenue when it received cash, not when it earned it.
Under GAAP, those are different things. And when an investor’s accounting team arrives with a different definition of “when does revenue count,” the gap between what the founder’s books show and what GAAP requires can be material enough to reprice a round, delay a close by weeks, or require a restatement of prior-period financials.
This isn’t obscure accounting. It’s the application of a standard — ASC 606 — that has been required for private companies since 2019. But a meaningful percentage of growth-stage startups haven’t applied it correctly. In a Debit client intake earlier this year, the books showed $1.2M in revenue for a period where correctly deferred contracts would have put it closer to $890K. The business was the same. The accounting just hadn’t caught up.
The core principle: revenue is earned, not received
The number that stalls most SaaS funding rounds isn’t a miss on ARR. It’s a misunderstanding of when ARR becomes revenue. And it’s almost always triggered by the same thing: annual contracts booked incorrectly.
Revenue recognition is the accounting principle that determines when a dollar of revenue counts. Under US GAAP — specifically ASC 606, the standard governing revenue from customer contracts — revenue is recognized when your performance obligations to the customer are satisfied. For a SaaS company, the performance obligation is software access. You satisfy that obligation over time, month by month, not the moment a customer signs or pays.
This creates a precise and important split: Cash received ≠ Revenue earned. ARR ≠ GAAP revenue recognized. Total contract value ≠ Revenue in this period.
Most founders understand this conceptually. The books often don’t reflect it.
What happens to the money that isn’t revenue yet
When a customer prepays for a period of service not yet delivered, that payment isn’t revenue. It’s a liability — specifically, deferred revenue: a balance on your balance sheet representing the obligation to deliver future service.
Until you deliver the service, the amount collected is an obligation to the customer and is recorded as deferred revenue on the balance sheet. The journal entry at the moment of cash receipt, for a $24,000 annual contract:
- Cash: +$24,000
- Deferred revenue (current liability): +$24,000
Then, each month over the 12-month contract:
- Deferred revenue: −$2,000
- Revenue: +$2,000
At the end of month 12, deferred revenue hits zero, and you’ve recognized $24,000 of revenue ratably — $2,000 per month, earned as you delivered the service.
What most startup books show instead: Cash +$24,000, Revenue +$24,000 on day one, no deferred revenue entry. That’s cash-basis revenue accounting applied to a prepaid subscription — and it will not survive a GAAP audit or investor quality-of-earnings review.
The five-step model in practice
ASC 606 structures revenue recognition through a five-step framework. For SaaS companies, most of these steps are straightforward — but each one has a version that breaks in practice.
Step 1: Identify the contract
You need a signed agreement (or an accepted order) with commercial substance. Verbal renewals, handshake extensions, and “they always pay” assumptions don’t count.
Step 2: Identify performance obligations
A performance obligation is a contractual promise to transfer a distinct good/service or a bundle of goods/services. This is where multi-element deals become important. If your contract includes software access, onboarding, implementation, and ongoing support, those may be distinct performance obligations — each with its own recognition timing. If you treat them as one bundled obligation and recognize everything ratably over the subscription term, you may be recognizing onboarding revenue before or after the onboarding is actually delivered.
Step 3: Determine the transaction price
For fixed-fee subscriptions, this is simple. For deals with variable consideration — volume-based pricing, milestone bonuses, refund provisions — the transaction price requires judgment and documentation.
Step 4: Allocate the price across performance obligations
If a contract has multiple obligations, the total price needs to be allocated proportionally, typically based on standalone selling prices for each element. A $24,000 annual contract that bundles $4,000 of onboarding isn’t $24,000 of ratable subscription revenue — it’s $20,000 ratable plus $4,000 recognized when onboarding is complete.
Step 5: Recognize revenue as obligations are satisfied
For SaaS, this means ratable recognition over the service period for the subscription component, and point-in-time recognition for distinct services delivered at a specific moment.
| Contract type | Cash received | Common (wrong) treatment | Correct ASC 606 treatment | What breaks in diligence |
|---|---|---|---|---|
| $24K annual, paid upfront | $24K day 1 | $24K revenue day 1 | $2K/month; $22K deferred liability | Balance sheet understates liabilities; P&L overstates period revenue |
| $24K annual, signed Dec 31 | $24K in December | $24K December revenue | $2K December; $22K deferred to Jan–Nov | December margin and revenue overstated |
| SaaS + onboarding ($20K + $4K) | $24K at signing | All $24K ratable over subscription | $20K ratable + $4K at onboarding delivery | Revenue timing and mix distorted |
| Monthly subscription ($500/mo) | $500/month | $500 monthly (usually correct) | $500 recognized as billed | Minimal issue; already aligned |
| Annual contract, Q3 renewal not confirmed | — | Full contract at original ARR | Revenue recognized through actual term | ARR overstated; deferred overstated |
Multi-element arrangements
If your contracts include more than software access — onboarding, implementation, training, or custom configuration — you have a multi-element arrangement under ASC 606, and each element is a distinct performance obligation with its own recognition timing.
A common error: bundling implementation and software into one contract and recognizing everything rateably over the subscription term. As Acrux Advisory outlines in their guide to SaaS revenue recognition, if a contract includes software access, onboarding, customer support, and implementation, “those are separate obligations that may need separate recognition schedules.” Revenue recognition errors in bundled arrangements can derail funding rounds or M&A deals when the investor’s team identifies the mismatch.
The ARR-to-GAAP gap
The gap between ARR and GAAP revenue is expected — and even desirable for a fast-growing company. A company signing a lot of new annual contracts will always have ARR higher than trailing twelve-month GAAP revenue, because the annual contract value is counted at full annualized rate immediately while GAAP revenue is only recognized as it’s earned, month by month.
ARR projects the amount of recurring revenue a SaaS business will realize over the next 12 months from the current set of customers — forward-looking by definition. GAAP revenue is historical, and it is closely audited by external firms in ways that ARR is not. Neither number is wrong. They measure different things. The problem comes when the company can’t explain the bridge between them — or discovers the gap for the first time during a live diligence process.
What the QoE team actually tests
When a quality-of-earnings team tests revenue, they pull a sample of contracts and trace each one through the revenue schedule. They’re verifying: does revenue recognized in each period match service delivery for that period? Is there a deferred revenue entry for any advance payment? Does the schedule tie to the P&L?
As Kruze Consulting notes in their SaaS accounting guide, “the price of incorrectly accounting for revenue and deferred revenue can be high. During due diligence, experienced SaaS VCs will request your financial statements, and they expect the numbers to match.” When they don’t, the process slows while the company documents and explains every discrepancy.
Building revenue recognition correctly
The earlier you implement correct revenue recognition, the less expensive it is. The full cost of correcting it under diligence pressure — reconstructing deferred revenue schedules, restating prior periods, documenting a policy that was never written down — typically takes weeks and can delay a round by 6–10 weeks depending on complexity.
The correct build-out has three components. The revenue schedule is a living document maintained monthly. It lists every active customer, contract start and end dates, total contract value, monthly recognized amount, cumulative recognized to date, and remaining deferred balance. At month-end, the deferred revenue per this schedule should reconcile exactly to the deferred revenue liability on the balance sheet.
The deferred revenue policy is written down: which contracts create deferred revenue, how recognition is timed, how multi-element arrangements are treated, and what happens at renewal. Documentation is what tells an investor that accounting is intentional, not assembled after the fact.
The ARR-to-GAAP bridge is something your finance team can produce on request — ARR movements through the waterfall, and a clear explanation of why GAAP recognized revenue for the period differs from ARR-implied revenue.
The companies that move through revenue diligence fastest aren’t the ones with the simplest revenue models. They’re the ones that have documented their policies, applied them consistently, and can reconcile ARR to recognized revenue in 30 minutes. That waterfall — and where the deck-versus-books gap most commonly lives — is what the next part of this guide breaks down.
