Partner, SDO CPA LLC / CEO, Growthy
You signed a $30,000 annual contract on January 15. Cash hit your bank on February 1. Your bookkeeper booked $30,000 in revenue that month. Six months later your auditor calls. You've been doing it wrong since day one. Welcome to ASC 606. It governs how SaaS companies recognize revenue. It drives more restatements at growth-stage SaaS companies than almost any other GAAP topic. For the bigger picture, the SaaS accounting hub walks the full stack from contract to financial statements.
This article walks the five-step ASC 606 model in plain language. We use one B2B SaaS contract as the running example. You'll see what each step requires. You'll see where operators most often miss. And you'll see what the journal entries look like at signing, monthly, and at month six. The goal is not GAAP citation. The goal is enough operating sense to hold a smart talk with your CPA, auditor, or CFO about how revenue gets recognized. See asc 606 revenue recognition.
One caveat up front. Bobby Huang runs Growthy and is a partner at SDO CPA LLC. He is not personally a CPA. ASC 606 reading for your specific contracts should go through a licensed CPA. This piece is educational, not a substitute for that review.
What does ASC 606 require for SaaS revenue recognition?
ASC 606 requires SaaS companies to recognize revenue when control of the service transfers to the customer. For most subscriptions, that means recognizing ratably over the contract term. The standard uses a single five-step model. Identify the contract. Identify performance obligations. Set the transaction price. Allocate the price to obligations. Recognize revenue as obligations are satisfied. For a typical $30,000 annual contract, you recognize $2,500 per month for 12 months. You do not book $30,000 on the day cash arrives. Distinct setup services may recognize at delivery. Multi-year prepayments over one year may need interest imputation under ASC 606-10-32-18. A practical expedient covers most SaaS deals.
ASC 606 took effect for public companies in 2018 and private companies in 2019. Before it landed, US GAAP had roughly 200 industry-specific revenue rules. Software had its own (SOP 97-2, then ASC 985-605). Construction had another. The patchwork made cross-industry compare almost impossible.
ASC 606 replaced all of that with one principle-based model. ASC 606-10-25-1 states the principle. Recognize revenue to show the transfer of promised goods or services. The amount should reflect what the entity expects to be entitled to. In plain language: recognize revenue when the customer gets the value, in the amount you expect to collect.
For SaaS, the practical translation is ratable delivery. Your customer signs up for 12 months of access. Each day, the customer gets a piece of the value they paid for. So each day, you recognize a piece of the revenue. Most companies simplify to monthly. The principle holds.
Three places operators most often miss. First, they treat billings as revenue and book the full annual prepay on cash receipt. Second, they treat setup services as part of the subscription. Those services often qualify as separate performance obligations. Third, they miss splits inside multi-element contracts. Each error compounds at audit time. The fix: walk the five steps, in order, every time a new contract comes in.
The pre-2018 world had software-specific rules. They included vendor-specific objective evidence of fair value, or VSOE. If you sold software with services and couldn't set VSOE for the services, you often had to defer 100% of contract value. You then recognized it ratably across the entire service period.
ASC 606 removed VSOE entirely. The replacement is standalone selling price (SSP). It is more flexible. It is based on what you actually charge or would charge for each element.
The most common mistake is mixing cash with revenue. A founder sees $30,000 hit the bank and reports $30,000 of revenue that month. The auditor later flags this as a $27,500 overstatement. Only $2,500 was actually earned. The fix is the deferred revenue liability. It holds the unearned portion on the balance sheet until it gets earned.
The second most common miss is bundling. A SaaS contract may include onboarding, training, and managed services. It can have three or four separate performance obligations. Lumping them into a single ratable subscription line distorts both revenue and margin reporting.
A contract under ASC 606 is not just any agreement. The standard sets five specific criteria. All must be met. They live in ASC 606-10-25-1. They apply equally to a signed master services agreement and a click-through terms of service.
The criteria:
For most SaaS companies, all five are met by a normal signup flow. The customer clicks accept on the terms. The terms identify what the customer gets and what the company gets. Payment is set up via credit card or invoice. Commercial substance is obvious. Collection is probable for credit-card signups. Creditworthiness is the judgment call for invoiced enterprise deals.
A written agreement is not required. Oral and implied contracts can qualify if the five criteria are met. In practice, SaaS companies meet all five through click-to-accept terms of service. The terms are the contract. The customer's act of clicking accept and entering payment is the approval and commitment.
For enterprise sales, the contract is typically a master services agreement plus an order form. The MSA sets rights and obligations. The order form sets price, term, and any custom terms. Both together form the contract.
The accounting outcome is usually the same either way. What differs is paperwork. A click-through generates a timestamp record. An MSA generates a signed PDF. Both qualify if the five criteria are met.
The one practical difference is collection probability. For credit-card-billed self-serve SaaS, collection is probable. The card has already been charged. For invoiced enterprise deals, the company has to judge whether the customer is likely to pay.
ASC 606-10-25-9 requires you to combine two or more contracts under three tests. First, they were entered into at or near the same time with the same customer. Second, one of three conditions is met:
This matters most for upsells. Say a customer signs the base subscription on Monday. They sign an add-on order form for premium support on Wednesday. Those may need to be combined. The result: discount or pricing on the bundle gets allocated across both contracts based on relative SSPs.
A performance obligation is a promise to transfer a distinct good or service. The keyword is distinct. ASC 606-10-25-19 sets a two-part test. A good or service is distinct if two things hold. First, the customer can benefit from it on its own or with other ready resources. Second, the company's promise is separately identifiable from other promises in the contract.
For a typical SaaS plan, the plan itself is one continuous performance obligation. The customer gets access every day of the term. Even though access has many features, you're not promising to ship each feature on its own. You're promising ongoing access.
Setup and implementation services are the most common second performance obligation. Ask two questions. Could a customer buy your setup work on its own? Does the setup have real value on its own (configuring their data, training their team, linking with their systems)? If both are yes, setup is distinct from the subscription.
Training and professional services often qualify too. The test is the same. Could the customer use these without the subscription? Does the company sell them on their own, or could it?
Premium support and customer success layers are usually combined with the subscription, not separate. They only have value alongside the core service. A CPA review is the right call for borderline cases.
The harder judgment is when implementation is truly integrated. The customer cannot use the software at all without it. In that case, the two combine into a single performance obligation. You recognize the combined revenue ratably across the subscription term.
Signal that setup is integrated: the customer cannot log in or use any real part of the product without it. Signal that it's distinct: the customer could use the basic product without it. The setup is an optional accelerator.
ASC 606-10-25-2 covers material rights. A contract may give the customer the option to acquire extra goods or services for free or at a discount. That option may itself be a performance obligation. The most common SaaS case is renewal discounts. Say a customer gets a contract right to renew at a 20 percent discount in year two. That may be a material right. You'd allocate a portion of year-one transaction price to the option.
Most SaaS companies do not treat standard renewal pricing as a material right. The pricing is at fair value. The concept kicks in when renewal pricing is well below what a new customer would pay.
The transaction price is the amount of consideration the company expects to be entitled to. For a simple fixed-fee contract, this is easy. A $30,000 annual contract has a transaction price of $30,000. For contracts with usage-based pricing, tiered discounts, rebates, or refund rights, the price requires an estimate.
ASC 606-10-32-2 calls these variable consideration. The standard requires you to estimate using one of two methods. Use expected value (probability-weighted average) or most-likely-amount (the single most likely outcome). Apply whichever better predicts the consideration you'll actually receive.
Fixed consideration is locked in: base subscription fee, setup fee, anything that doesn't depend on usage or future events. Variable consideration is everything else. That covers usage charges above a threshold, performance bonuses, refund rights, and volume discounts tied to annual buy volume.
For a contract with both, you total them at inception based on best estimate. As usage data comes in, you true up the estimate. You recognize the difference as a cumulative catch-up to revenue.
Many SaaS contracts have a base subscription plus usage charges above a threshold. Example: $1,000 per month base plus $0.01 per API call above 100,000 calls. The base is fixed. Overage is variable.
You estimate variable usage at contract start using past data and customer signals. Recognize the base each month at $1,000. Recognize the estimated variable component as it accrues. True up at period end as actual usage lands.
Minimum commitments add a wrinkle. Say a customer commits to $24,000 over the year regardless of usage. The $24,000 is fixed and recognized ratably. Any usage above that implied threshold is variable.
ASC 606-10-32-15 says this. If payment timing provides a significant benefit of financing, the contract has a significant financing component. The transaction price gets adjusted to reflect cash selling price. The difference goes to interest.
ASC 606-10-32-18 provides a practical expedient. If the gap between payment and delivery is one year or less, you do not adjust. Most annual SaaS prepays use this expedient. Multi-year prepays over one year may not. It depends on size and rate environment. A three-year $90,000 prepay in a high-rate environment likely needs imputation. This is one place where CPA review is truly warranted.
If the contract has only one performance obligation, allocation is simple. If it has multiple, you split the transaction price across them based on relative standalone selling prices.
SSP is the price at which the company would sell the good or service on its own. The ideal evidence is observable: you actually sell it on its own. For SaaS plans, this often works for the base tier.
When observable evidence is not available, ASC 606-10-32-33 allows three estimation methods.
For most SaaS companies, the practical approach is split. Use adjusted market assessment for the subscription (you have list pricing). Use expected cost plus margin for setup services.
A bundle discount means the bundled price is less than the sum of SSPs. The default is proportional allocation across all performance obligations based on relative SSP. Example: subscription SSP is $24,000. Implementation SSP is $6,000. You sell the bundle for $27,000. The $3,000 discount allocates 80 percent to subscription ($2,400) and 20 percent to implementation ($600).
ASC 606-10-32-37 allows specific allocation only with observable evidence. The discount must relate entirely to one or more (but not all) obligations. This is a high evidence bar in practice.
You recognize revenue when (or as) the customer obtains control. ASC 606-10-25-23 sets the over-time vs point-in-time split. Over-time applies if any of three criteria in ASC 606-10-25-27 is met:
For SaaS plans, criterion one applies. The customer at the same time receives and consumes the benefit of access each day. Over-time recognition is required.
Over-time is the default for SaaS plans. Within over-time, you choose a measure of progress. For a plan that delivers equal value each day, straight-line works. You recognize the contract value ratably across the term, typically monthly.
Point-in-time only applies to distinct services completed at a moment in time. A setup that delivers a configured environment is point-in-time at delivery. A one-time training session is point-in-time at the session.
The customer gets a fixed-value benefit each day (access). The company's work is essentially the same each day (keeping the service running). Straight-line ratable recognition reflects this economic reality. Monthly is practical because most companies close monthly. Daily is allowed and sometimes used for high-precision reporting.
Refund rights affect transaction price at inception. If you offer a 30-day money-back guarantee, the expected refund amount reduces the transaction price under variable consideration rules. You don't recognize the refundable portion as revenue until the refund window closes.
Contract modifications follow ASC 606-10-25-10 through 25-13. The standard splits two cases. First, a modification that adds distinct goods or services at a price reflecting SSPs is treated as a new contract (prospective). Second, a modification that changes existing services or adds services not priced at SSP is treated as a cumulative catch-up.
Let's walk all five steps for one contract. Acme Software signs a contract with Beta Corporation on March 1. Terms: $30,000 annual subscription paid up front on March 1, plus a $5,000 one-time setup fee also paid on March 1. The subscription runs March 1 through February 28. Setup is delivered by March 31. Base subscription would sell standalone for $30,000. Setup would sell standalone for $5,000.
Step 1: Contract criteria are met. MSA is signed. Rights and payment terms are clear. Commercial substance exists. Beta is creditworthy. Contract exists.
Step 2: Two performance obligations. First, the subscription (one continuous service over 12 months). Second, the setup. The setup is distinct because Beta could buy it separately and a third party could deliver it.
Step 3: Transaction price is $35,000 fixed. No variable consideration. No financing component (under the one-year practical expedient).
Step 4: Allocation. SSPs are $30,000 and $5,000, totaling $35,000. That matches transaction price. No discount to allocate. Subscription gets $30,000. Setup gets $5,000.
Step 5: Recognition. Subscription recognizes ratably over 12 months at $2,500 per month. Setup recognizes point-in-time on March 31 when delivered.
$35,000 paid up front. $5,000 earns by March 31 (setup). $30,000 earns ratably from March 1 through February 28 next year ($2,500 per month). For more contract patterns and how they map to ASC 606 mechanics, see six real ASC 606 contract examples.
On March 1 (cash receipt and contract signing):
Dr. Cash $35,000 Cr. Deferred revenue (subscription) $30,000 Cr. Deferred revenue (setup) $5,000
On March 31 (setup delivered):
Dr. Deferred revenue (setup) $5,000 Cr. Setup revenue $5,000
And on March 31 (monthly subscription recognition):
Dr. Deferred revenue (subscription) $2,500 Cr. Subscription revenue $2,500
Every month after, through February of the following year, the monthly subscription entry repeats. For more on how this liability behaves on the balance sheet across these entries, see deferred revenue on the SaaS balance sheet.
Six months in, on August 31, the books show two pieces. First, $5,000 setup revenue (recognized in March). Second, six months of subscription at $2,500 each, totaling $15,000. Total revenue recognized year-to-date: $20,000. Cash collected: still $35,000. Deferred revenue on the balance sheet: $15,000 ($30,000 subscription deferred, minus $15,000 recognized).
The customer is still receiving $35,000 worth of value. The statements show the earning of that value. That is the point of ASC 606. If you bill through Stripe, the cash flows and recognition flows both run through your books. But only one is your top-line revenue. The other is cash timing. For pulling Stripe data into your books cleanly, Stripe revenue recognition for SaaS walks through the bookkeeping mechanics.
A clean bookkeeping system makes this much easier. Growthy is bookkeeping software built for SaaS. It handles deferred revenue, invoice-to-revenue mapping, and the journal entries above. They get generated automatically from your Stripe data. We hit about 85% accuracy on a first import and 90%+ on returning books after 30 days. For the regulatory side (signing off on ASC 606 reading), Growthy is not a CPA firm. We'd point you to a licensed CPA.
Growthy is bookkeeping software, not a CPA firm. This content is educational, not professional advice. Full disclaimer.
Get Started with Growthy. See asc 606 revenue recognition examples.
Related: SaaS Accounting, Chart of Accounts, Stripe Bookkeeping.
Free during alpha. Read-only access. You review every sync.
CPA firm partner who got tired of watching bookkeepers click categorize 500 times a day. Built Growthy to fix it.
View author profileGrowthy is dedicated to helping businesses of all sizes make informed decisions. We adhere to strict editorial guidelines to ensure that our content meets and maintains our high standards.
Trace Stripe charges from gateway through bank deposit to recognized revenue. Clearing-account JEs, Stripe Billing RevRec vs GL-side recognition, and when to graduate to a dedicated tool.
Day-1 through end-of-year SaaS bookkeeping setup for founders. Chart of accounts, deferred revenue, Stripe, 1099s, and ASC 606 awareness without overengineering.
Practitioner comparison of 7 SaaS accounting options. QBO, Xero, Maxio, Chargebee, RecVue, Stripe Billing, and Growthy mapped to ARR stage and contract complexity.