ASC 606 for SaaS Founders: A Plain-English Guide

What is ASC 606, really?

ASC 606 is the U.S. accounting standard that tells you when to recognize revenue. Specifically, it tells you that you can only count money as "revenue" when you've actually delivered the thing you promised to deliver — not when you got paid.

That sounds obvious. It's not.

Imagine you sell a $12,000 annual SaaS subscription on January 1st. The customer pays you the full $12,000 upfront.

You did not earn $12,000 of revenue in January.

You earned $1,000 of revenue in January. And $1,000 in February. And $1,000 every month through December. The other $11,000 sits on your balance sheet as a liability called "deferred revenue" — basically, "money I owe the customer if I stop delivering service."

This is the heart of ASC 606. Cash is not revenue. Revenue is what you've delivered.

If you've been tracking revenue based on what hits your bank account, you've been doing it wrong. And your auditor will eventually notice. Hence: this guide.

Why does this exist?

ASC 606 was published jointly by the FASB (the U.S. accounting rule-makers) and the IASB (the international version, called IFRS 15) in 2014. It became mandatory for public companies in 2018 and private companies in 2019.

The point was to unify how every industry recognizes revenue. Before 2018, software companies, construction firms, and media companies all had different rules. ASC 606 created one framework that applies to everyone.

For SaaS founders specifically, the implication is: you have to think about revenue at the contract level, not just at the invoice level. Every signed contract is a story that plays out over time. Your job is to recognize the revenue at the pace you actually deliver the service.

---

Do you actually need to comply right now?

Honest answer: probably, but the urgency depends on what's about to happen to your business.

Here's the practical test. Ask yourself which of these is closest to your situation:

Bucket 1 — You don't need to worry about ASC 606 yet

• You have <5 customers
• You're under $500K ARR
• Nobody has audited you (and nobody plans to in the next 6 months)
• Your investors aren't asking for GAAP-compliant financials
• You're not raising in the next 6 months

If you're in this bucket, you can defer formal ASC 606 compliance. But — and this is the catch — you should still track deferred revenue in a basic way. Even a spreadsheet. Because:

1. Going back and reconstructing 18 months of historical contracts is brutal
2. Your future Series A diligence will ask about it
3. Your auditor will eventually want a clean trail

So: track it informally, but don't stress about the framework yet.

Bucket 2 — You need to start now (this is most readers)

• You have 10-50 customers
• You're between $500K and $5M ARR
• You're raising a seed or Series A in the next 6-12 months
• Your investor diligence has mentioned revenue recognition
• You're starting to send monthly investor updates with revenue numbers
• A fractional CFO or bookkeeper has flagged it

If you're in this bucket, ASC 606 compliance is a "this quarter" problem, not a "next year" problem. Investors will pressure-test your numbers. Your future audit will be much cleaner if you start now.

Bucket 3 — You are urgently behind

• You're being audited (Big4 or regional firm)
• You're closing a Series A or B
• A customer asked for SOC 2 or compliance audit
• Your last quarterly board update had a revenue number that doesn't match what hit your bank account, and someone asked why
• Your CFO/auditor said the words "we need to restate"

If you're in this bucket, stop reading this article and either hire help or start using a real tool today. The cost of fixing this retroactively grows every week.

---

The five-step framework, in founder language

ASC 606 is structured as a five-step model. The original FASB language is dense. Here's what each step actually means in practice.

Step 1: Identify the contract

What this means: Is this an enforceable agreement between you and the customer that creates obligations on both sides?

For most SaaS, this is trivial. The signed Order Form or MSA is the contract. The customer is obligated to pay; you're obligated to deliver service.

The cases where it gets weird:

• Free trials don't count as contracts until the customer converts to paid.
• A Master Services Agreement (MSA) without an Order Form usually isn't a contract — it's a framework. The Order Form (or Statement of Work) is the contract.
• Verbal agreements and Slack DMs don't count even if you've delivered service. You need something signed (electronically is fine).

The founder takeaway: Your contract starts when the Order Form is signed (or the customer clicks "I agree" on a subscription page).

Step 2: Identify the performance obligations

This is where founders get tripped up the most. A "performance obligation" is a distinct promise to deliver something.

Most SaaS contracts have one obligation: deliver the software for the term. Some have multiple. Examples:

• One obligation: "$12,000/year subscription to our product" → one performance obligation (the subscription)
• Two obligations: "$12,000/year subscription + $5,000 one-time implementation" → two performance obligations (subscription + implementation), if the customer could theoretically use your product without the implementation
• One obligation: "$12,000/year subscription with included onboarding" → could be one or two, depending on whether the onboarding is genuinely distinct

The technical test (ASC 606-10-25-19) is:

1. Can the customer benefit from the good or service on its own?
2. Is the good or service separately identifiable from other things in the contract?

If both are "yes," it's a distinct performance obligation.

The founder takeaway: Most SaaS subscriptions are one obligation. But if you also sell implementation services, professional services, or hardware, those are likely separate obligations.

Step 3: Determine the transaction price

How much consideration are you expecting to receive in exchange for the contract?

For straightforward subscriptions, this is just the total contract value (TCV). $12,000/year contract = $12,000 transaction price.

It gets complicated when there's "variable consideration":

• Usage-based pricing: "$0.10 per API call above 10,000/month" → you don't know in advance how much you'll bill
• Service Level Credits: "If uptime drops below 99.5%, we'll credit 10%" → potential reduction
• Volume discounts: "10% off if you spend $50K+/year" → tiered pricing
• Refunds and concessions: "30-day money-back guarantee"

For variable consideration, you have to estimate the most likely amount and apply a "constraint" — only include amounts you're highly confident you'll actually receive.

There's a practical expedient (ASC 606-10-32-40) that helps with pure usage-based pricing: you can recognize variable consideration entirely in the period you deliver the service, instead of estimating upfront. Most SaaS companies with usage tiers use this expedient.

The founder takeaway: For fixed-price contracts, transaction price = TCV. For usage-based, you'll recognize the variable amounts when they're billed.

Step 4: Allocate the transaction price

If your contract has more than one performance obligation, you need to allocate the transaction price across them based on each obligation's standalone selling price (SSP).

Example: You sell a bundle for $40,000 that includes:

• Marketing Hub Pro ($30,000 SSP)
• Sales Hub Pro ($15,000 SSP)
• Service Hub Pro ($9,000 SSP)
• Onboarding ($5,000 SSP)

Total SSPs = $59,000. Bundle price = $40,000. So you're giving a 32.2% discount on the bundle.

Under ASC 606, you allocate the discount proportionally:

• Marketing Hub: $30,000 × ($40,000 / $59,000) = $20,339
• Sales Hub: $15,000 × ($40,000 / $59,000) = $10,169
• Service Hub: $9,000 × ($40,000 / $59,000) = $6,102
• Onboarding: $5,000 × ($40,000 / $59,000) = $3,390

The onboarding gets a chunk of the revenue even though it's "free" in the marketing copy.

The founder takeaway: If you sell bundles or have multiple product lines, you'll need to maintain a list of "standalone selling prices" for each product. This is one of the most under-appreciated things a SaaS finance team needs to do.

Step 5: Recognize revenue

Finally — when do you actually count it as revenue?

Three main patterns:

1. Ratable / over time: Most subscription revenue. Spread it evenly across the contract term.
2. As consumed: Usage-based revenue. Recognize when the customer actually uses it.
3. Point in time: Discrete deliverables like implementation, training, hardware. Recognize when delivered.

A $12,000 annual subscription becomes $1,000/month of recognized revenue. A $5,000 one-time onboarding becomes $5,000 of revenue in the month onboarding is completed. A $0.10/API call usage fee becomes revenue at the moment the API call is made (aggregated daily or monthly for practical purposes).

The founder takeaway: Each performance obligation gets its own recognition pattern. Your "revenue waterfall" is the schedule that shows how each contract's revenue gets recognized over time.

---

Real-world examples

Abstract theory is exhausting. Here's how this actually plays out for the contract shapes most SaaS founders see.

Example 1: Vanilla annual subscription

Contract: Customer signs $24,000 annual subscription on March 1, 2026. Pays full amount upfront.

ASC 606 analysis:

• 1 performance obligation: deliver the subscription for 12 months
• Transaction price: $24,000
• Allocation: 100% to the subscription
• Recognition: Ratable, $2,000/month from March 2026 through February 2027

Journal entries:

• March 1: Cash $24,000 / Deferred Revenue $24,000 (when payment received)
• March 31: Deferred Revenue $2,000 / Subscription Revenue $2,000 (monthly recognition)
• ...and repeat through February 2027

Simple. 90% of early-stage SaaS contracts look like this.

Example 2: Subscription + Implementation

Contract: Customer signs $36,000/year subscription + $8,000 one-time implementation. Implementation is delivered in April (1 month after start).

ASC 606 analysis:

• 2 performance obligations (assuming the customer could use your product without the implementation):
  • Subscription: 12 months ratable
  • Implementation: point-in-time when complete
• Transaction price: $44,000
• Allocation: at SSP, since both priced separately. $36K to subscription, $8K to implementation.
• Recognition:
  • Subscription: $3,000/month × 12 months
  • Implementation: $8,000 fully recognized in April

Example 3: Multi-product bundle

Contract: Customer signs annual deal for $50K, includes:

• Product A (SSP $30K)
• Product B (SSP $20K)
• Product C (SSP $10K)
• Onboarding (SSP $5K, but "included free")

ASC 606 analysis:

• 4 performance obligations
• Transaction price: $50,000
• Allocation by relative SSP (total SSP = $65,000, allocation factor = 76.9%):
  • Product A: $23,077
  • Product B: $15,385
  • Product C: $7,692
  • Onboarding: $3,846

Even though onboarding was "free" in the contract, it gets $3,846 of revenue allocated to it. Onboarding is recognized when delivered (typically month 1). Products A, B, C are recognized ratably over 12 months.

Example 4: Usage-based pricing

Contract: Customer signs $0 monthly base, pays $0.10 per API call. In March, customer uses 50,000 API calls.

ASC 606 analysis:

• 1 performance obligation: stand-ready to provide API access
• Transaction price: variable
• Practical expedient (ASC 606-10-32-40): recognize as consumed
• Recognition: $5,000 of revenue in March (50,000 × $0.10)

If usage drops to 10,000 calls in April → $1,000 revenue in April. Volatile, but that's the right answer.

Example 5: Mid-term upgrade

Contract: Customer signs $24,000/year subscription on January 1. On July 1, they upgrade to a higher tier worth $48,000/year (6 months remaining).

ASC 606 analysis:

• The upgrade is a contract modification (ASC 606-10-25-10)
• Determine treatment based on whether the upgrade adds distinct services priced at SSP increment
• If yes → separate contract (606-10-25-12) → recognize the additional revenue over the remaining 6 months
• If no (e.g., the upgrade replaces, not adds) → prospective treatment (606-10-25-13(b)) → recompute remaining revenue based on the new total

Most tier upgrades that add features get treated as separate contracts. The original $24K continues recognizing at $2K/month. The incremental $24K from the upgrade ($48K – $24K) recognizes at $4K/month from July through December.

---

The five most common mistakes SaaS founders make

After watching dozens of founders work through ASC 606, the same five mistakes show up over and over.

Mistake 1: Recognizing revenue when cash hits the bank

The single most common founder error. "We got paid $50K in March, so March revenue is $50K." Wrong. If that $50K was for an annual contract, only $4,166 is March revenue. The other $45,834 is deferred revenue.

This mistake shows up everywhere: investor updates, board decks, ARR calculations, runway projections. It's also the first thing your auditor will catch.

Fix: Build the discipline of recording deferred revenue at the moment cash hits. Even in a spreadsheet. Track the monthly recognition separately.

Mistake 2: Treating every line item as a separate performance obligation

The opposite error: founders read about "performance obligations" and try to split every line of their contracts into separate POs.

A typical SaaS contract has 1-2 POs, sometimes 3-4 for multi-product bundles. Not 12.

Fix: Apply the two-prong test (ASC 606-10-25-19). If the customer can use the product without that line item, and the line item is separately identifiable, it's a distinct PO. Otherwise it's combined with another PO.

Mistake 3: Ignoring contract modifications

A customer upgrades from $24K/year to $48K/year mid-term. The founder just changes the recurring invoice amount and calls it good.

That's a modification. ASC 606 has specific rules (606-10-25-10 through 25-13) for how to account for modifications. Skipping this analysis is one of the top three things auditors find during diligence.

Fix: Whenever a contract changes mid-term, ask: "Does this add distinct services at the standalone selling price?" If yes, treat as a separate contract. If no, treat as a prospective modification of the existing contract.

Mistake 4: Recognizing usage revenue too early

You quote your customer "$0.10 per API call." You record $0.10 of revenue when you set up their account. Wrong — that's not when the service was delivered.

Usage revenue gets recognized when the customer uses it. Not when the contract is signed. Not when the invoice is sent. When the meter ticks.

Fix: Build a daily or monthly aggregator that converts your usage logs into a recognition schedule. Recognize revenue in the period of consumption.

Mistake 5: Not documenting your judgments

ASC 606 is full of judgment calls. Distinct vs. combined performance obligations. SSP allocation methodology. Variable consideration constraint estimation. Modification treatment.

The founder mistake: making these judgments quietly in a spreadsheet, with no documentation of why.

When your auditor shows up, they will ask you to justify every judgment. If your only answer is "that's what we did," you're going to have a bad time.

Fix: For every judgment call in your rev rec, write a one-paragraph memo documenting (a) the decision, (b) the ASC citation that supports it, and (c) the alternative you considered. This is what professional CPAs call a "workpaper memo." It's painful to write but priceless during audit.

---

Your two realistic options

You have two practical paths to ASC 606 compliance.

Path 1: Build it in spreadsheets

The free option. Many founders start here.

You set up a Google Sheet or Excel workbook with:

• A contracts tab
• A waterfall tab (revenue schedule by contract)
• A deferred revenue rollforward
• A journal entry log

You manually update it every time a contract is signed, modified, or cancelled.

When this works: Under 10 contracts, simple subscriptions only, no audit pressure, you have spare time.

When this breaks: Around 20-30 contracts, when contract modifications start happening, when you realize you've made copy-paste errors that cascade through three months of board decks, when your auditor asks for your judgment documentation and you don't have any.

Average lifespan of a SaaS founder's rev rec spreadsheet: 8-14 months. Then it breaks at the worst possible moment.

Path 2: Use a tool

The tool that should exist: connects to your existing stack (Stripe, QuickBooks, DocuSign), reads your contracts with AI, applies real ASC 606 judgment, posts journal entries to your books, and generates audit-defensible workpapers.

That's what we built RevRec Engine to do. Specifically:

• Connect Stripe + QuickBooks in 60 seconds each
• Upload contracts from DocuSign, email, or PDF — Claude reads them and proposes the ASC 606 treatment in plain English
• Review and approve — one click, with every judgment flagged for your sign-off
• Auto-post journal entries to QuickBooks every month
• Generate audit workpapers that document every judgment with ASC citations

Built by a CPA, for founders without one. Free up to 3 contracts. $99/mo for up to 25 contracts. $299/mo for complex contracts with modifications and multi-element allocation.

Start free →

---

Frequently asked questions

Do I need a CPA on staff to do ASC 606?

No. ASC 606 is complex but the framework is well-defined. With either a good tool or a competent fractional CFO/bookkeeper, you can comply without a full-time CPA. Most SaaS companies don't hire a Controller until $5-10M ARR.

What's the difference between ASC 606 and IFRS 15?

ASC 606 is the U.S. standard (FASB). IFRS 15 is the international equivalent (IASB). They were developed jointly and are functionally identical. If your investors or auditors care about international standards, they're asking about IFRS 15. For 99% of U.S.-incorporated SaaS companies, ASC 606 is the relevant standard.

Does QuickBooks Online handle ASC 606 natively?

Not really. QuickBooks Online has basic deferred revenue functionality but doesn't automate the five-step framework. You can manually create journal entries to track deferred revenue, but you'll be doing the analysis elsewhere (spreadsheet or specialized tool) and posting the results to QBO.

When do I need to start tracking ARR vs. revenue?

Different metrics for different audiences. ARR (annual recurring revenue) is a forward-looking measure of contract value, used for investor updates and growth tracking. Revenue (under ASC 606) is what you've actually delivered, used for GAAP-compliant financial statements. You'll track both. They should never be confused with each other.

What happens if I get audited and my ASC 606 is wrong?

Depends on materiality. Small errors (<$50K) often result in "audit adjustments" — your auditor proposes corrections, you post the journal entries, and life goes on. Material errors (>$1M or >5% of revenue) can trigger restatements, which damage investor confidence and create legal exposure. The point of doing ASC 606 right now is to never get to the "material error" stage.

Do I need ASC 606 if I'm pre-revenue or just starting out?

Technically yes (it applies to any GAAP-reporting entity), but practically you can defer formal compliance until you have meaningful revenue (~$500K+). Until then, just track deferred revenue informally so you have a clean trail later.

Is the audit workpaper something I create, or something my auditor creates?

Both. You create the workpaper documenting your accounting policies, judgments, and the supporting evidence. Your auditor reviews your workpaper, tests samples of your transactions, and creates their own internal workpaper documenting what they tested. Your workpaper is the thing you hand to the auditor when they start.

Should I be doing ASC 606 in real-time or only at year-end?

Real-time, ideally monthly. If you only do ASC 606 at year-end, you're working from memory and incomplete documentation. The deferred revenue balance you report to investors during the year will be wrong. And reconstructing the analysis after the fact is painful.

How long does it take to get ASC 606 compliant?

If you have <30 contracts and use a tool like RevRec Engine: under a week to set up, ongoing automation thereafter. If you do it in spreadsheets: 1-3 weeks of initial setup plus 8-20 hours per month of maintenance forever. If you hire a fractional CFO to do it manually: 2-6 weeks of onboarding plus their ongoing hourly fees.

What's the most expensive ASC 606 mistake I could make?

Misclassifying a long-term contract modification. If you treat a modification as a separate contract when it should be cumulative catch-up (or vice versa), you can materially misstate revenue for multiple periods. That's the kind of error that triggers restatements during audits. Always document modification treatment carefully.

---

The bottom line

ASC 606 isn't optional for any company that wants to scale beyond the seed stage. It's a 5-step framework that turns "we got paid" into "we earned revenue" — and the distinction matters more as your revenue grows.

The good news: 80% of SaaS contracts are simple. Vanilla annual subscriptions follow a single pattern. You can get the basics right with discipline and either a good spreadsheet or a tool.

The bad news: the other 20% (modifications, multi-element bundles, usage variability, contract upgrades) is where founders consistently make mistakes that bite them at their first audit.

If you're at the stage where you have 5-50 contracts and the pain of spreadsheets is starting to outweigh the cost of a tool, try RevRec Engine free. Built by a CPA who watched too many founders go through this the hard way.

If you're not at that stage yet, bookmark this article. You'll be back when you are.

---

About the author: Chris is a CPA and the founder of RevRec Engine, the audit-ready revenue engine for AI-native SaaS founders. He spent years working inside SaaS finance teams before founding RevRec Engine to solve the rev rec problem he'd watched dozens of founders struggle with.

Have questions? Email Chris directly: chris@revrecengine.com.

---

Related reading:

• How to talk to your auditor about ASC 606 (coming soon)
• The 47-tab spreadsheet: why DIY rev rec breaks at scale (coming soon)
• Variable consideration explained for SaaS founders (coming soon)
• Contract modifications and ASC 606: when to treat as separate vs. cumulative (coming soon)

---

Author notes (not for publication — for Chris's reference)

SEO optimization checklist

• H1 contains primary keyword ("ASC 606 for SaaS Founders")
• H2s contain keyword variations
• Word count >3,000
• Internal links (placeholders for future articles)
• FAQ section (rich snippet potential)
• CTA at multiple points
• Author bio with E-E-A-T signal
• Meta description tight (155 chars)
• Add original images / screenshots before publishing
• Add JSON-LD schema for FAQPage
• Submit to Search Console after publication

Content distribution strategy

1. Publish on revrecengine.com/blog/asc-606-for-saas-founders
2. Cross-post excerpts on LinkedIn (3-4 posts over a week)
3. Twitter thread version (15-20 tweets)
4. Email to founder list (Mercury/Brex partner newsletters if achievable)
5. Submit to Hacker News with title "Show HN: ASC 606 for SaaS founders, by a CPA who's seen this play out 50 times"
6. Indie Hackers post
7. Update quarterly with new examples or regulatory changes

Conversion targets

• 2-3% of readers click "Start free" CTA → product trial
• 5-7% of readers sign up for email newsletter
• 0.5-1% of readers email Chris directly within first 30 days

Update cadence

• Quarterly review for accuracy
• Add new examples as new contract patterns emerge
• Refresh meta description and title tag annually