What ASC 606 Actually Means for SaaS Revenue (In Plain English)

What ASC 606 Actually Means for SaaS Revenue (In Plain English)

A founder closes a $120,000 annual contract in January, the cash lands in the bank, and the dashboard says the company just did $120K in revenue that month.

It didn't. Under the accounting standard that governs this, the company earned $10,000.

That gap — between the money you collected and the revenue you're allowed to report — is the whole reason ASC 606 SaaS revenue explained badly costs founders so much grief. They read their own P&L wrong, misjudge their growth rate, and walk into a due-diligence call with numbers that don't survive contact with an auditor. Here's what 606 actually says, without the FASB decoder ring.

ASC 606 SaaS Revenue Explained: You Earn It When You Deliver, Not When They Pay

ASC 606 is the revenue recognition standard the FASB issued to replace the old industry-by-industry rules. Its core principle is one sentence: you recognize revenue as you transfer the promised service to the customer, in the amount you expect to be entitled to.

For a subscription business, that means a 12-month plan is delivered over 12 months. So you recognize one-twelfth of it each month.

Sell that $120,000 annual contract and you book $10,000 in January, $10,000 in February, and so on through December. The cash showed up on day one. The revenue shows up across the year, because that's when you're actually doing the work the customer paid for.

This is the single most common place revenue recognition SaaS founders trip. Bookings, billings, and recognized revenue are three different numbers, and 606 only lets one of them onto the income statement.

Cash You Haven't Earned Yet Is a Liability

So where does the other $110,000 sit in January?

On the balance sheet, as deferred revenue — also called unearned revenue. And here's the part that surprises people: it's a liability, not an asset.

That's not an accounting quirk. If you collected a year of cash and delivered one month, you still owe the customer eleven months of service. If you shut down in February, you'd owe most of that money back. A liability is exactly the right label.

Each month, as you deliver, an equal slice moves off the deferred revenue line and onto the P&L as earned revenue. Deferred revenue shrinks, recognized revenue grows, and the cash never moved — it was always in the bank.

For a deferred revenue startup that sells annual plans, this balance is often one of the largest items on the balance sheet. Lenders and investors read it as a signal of committed future revenue. Getting it wrong doesn't just misstate one month — it distorts the whole growth story.

The Five-Step Model Behind ASC 606 SaaS Revenue, Explained

The standard isn't vibes. It's a defined five-step model, and every SaaS contract runs through all five:

• Step 1 — Identify the contract. A real agreement with enforceable rights, payment terms, and a reasonable expectation you'll actually collect.
• Step 2 — Identify the performance obligations. Each distinct promise you made: the software, the onboarding, the premium support. Each one is a separate thing you owe.
• Step 3 — Determine the transaction price. The total consideration you expect to be entitled to, including any discounts or variable pieces.
• Step 4 — Allocate the price across the obligations. Split the total across each promise based on its standalone selling price.
• Step 5 — Recognize revenue as each obligation is satisfied. Some over time (the subscription), some at a point in time (one-time setup).

Most software companies live in steps 4 and 5. That's where the money gets sliced up and metered out — and where a generalist bookkeeper who's never touched a SaaS contract starts guessing.

Why Multi-Element Contracts Are Where It Gets Hairy

Real SaaS deals are rarely "here's the software, pay monthly." They're software plus a one-time onboarding fee plus a premium support tier. ASC 606 treats those as separate performance obligations and makes you allocate the price across each.

Say a customer signs a $60,000 deal: $48,000 for a year of the platform, $9,000 for implementation delivered in month one, and $3,000 for a priority support add-on running the full year.

The math: the $48,000 platform fee recognizes at $4,000 a month. The $9,000 implementation recognizes when implementation is done — likely all in month one. The $3,000 support recognizes at $250 a month. Three obligations, three different schedules, one contract.

Skip this allocation and you'll either front-load revenue you haven't earned or strand revenue you should have booked. Both make your numbers wrong in a way an investor's accountant will find in about four minutes.

Usage-Based Pricing Adds "Variable Consideration"

Then there's metered and usage-based pricing, where you don't even know the final number when the contract starts. ASC 606 calls this variable consideration, and it has its own estimation rules — you estimate the amount you expect to be entitled to and constrain it so you're not booking revenue that might reverse later.

For a consumption-priced API or seat-based plan that flexes monthly, this turns revenue recognition into an ongoing estimate, not a fixed schedule. It's doable. It's just not something you eyeball.

The Gap Between Cash and Revenue Is Normal — Confusing Them Is the Problem

Here's the thing nobody tells first-time founders: under 606, your bank balance and your revenue line are supposed to disagree. Cash spikes when you collect annual prepayments. Revenue is smooth because it's earned over time. That's the system working.

The danger isn't the gap. The danger is treating cash as revenue — celebrating a "record month" that was really one big prepayment, then watching the recognized revenue line tell investors a much flatter story than your bank account did.

Set this up correctly once and your metrics finally tell the truth: real MRR, real growth, a deferred revenue balance that reads as a strength instead of a landmine.

Get Your SaaS Books Built for ASC 606 From Day One

The five-step model isn't hard once someone who's done it a hundred times sets up your schedules. It's brutal to retrofit at Series A when an investor's accountant is restating two years of revenue in real time.

The SaaS Bookkeeper does this for a living — deferred revenue schedules, multi-element allocation, and 606-clean books that hold up in diligence. They focus on software companies, so they've already seen the contract structure you're about to sign.

Read their verified reviews on Sam's List, then book an intro call before your next annual contract lands and turns into a revenue-recognition headache. Fixing it now is cheap. Restating it later is not.