By Shawn Elliott, CFO at High Rock Accounting
Yep, you signed your Series A. The deck was beautiful. The investors said yes. And now the term sheet has a clause that makes your stomach turn: audited financials, due in 180 days. You start Googling “ASC 606” at 11pm on a Tuesday, and what comes back reads like it was written by lawyers, for lawyers, in a language only auditors speak.
I’ve sat across the table from a lot of founders in that exact moment. So let me walk you through what ASC 606 actually means for your SaaS business, where founders trip themselves up before that first audit, and what we do to get books squeaky clean before the auditors show up. No jargon dump, just the practical version.
Why This Matters Now
ASC 606, issued by the Financial Accounting Standards Board (FASB) in May 2014, replaced a patchwork of industry-specific revenue rules with a single, principle-based framework that applies to virtually every business with customer contracts. Public companies adopted it for fiscal years beginning after December 15, 2017, and private companies followed for fiscal years beginning after December 15, 2018, with a one-year COVID-era extension granted under ASU 2020-05.*1
So if you’ve been operating on a “we recognize when we invoice” approach because nobody’s asked yet, the audit is the moment that approach stops working. Banks want GAAP financials before they’ll lend. Private equity wants GAAP financials before they’ll buy. Series B and beyond investors want GAAP financials before they’ll wire. And auditors will not pass you on an audit unless your revenue is recognized in accordance with GAAP. Period.
Here’s the part founders don’t always realize: if you’ve been recognizing revenue too early in prior periods, getting compliant means restating those numbers, and you’re going to show some ugly revenue in the year you right that ship. That’s a conversation worth having with your board now, not three weeks before audit fieldwork starts.
The Five-Step Model in Plain English
ASC 606’s core principle is straightforward enough: recognize revenue to depict the transfer of promised goods or services in an amount that reflects the consideration you expect to receive for them.*2 Sounds simple. The complexity lives in five steps the standard walks you through.
Step 1: Identify the contract. For most SaaS, this is your subscription agreement, your MSA with a signed order form, or your click-through terms. The contract has to be approved, identifiable as to rights and payment terms, have commercial substance, and collection has to be probable.*3 Where I see founders stumble: month-to-month rolling agreements with no signed paper, or auto-renewing contracts where nobody can tell me when the renewal actually started. Document it.
Step 2: Identify the performance obligations. This is where SaaS gets interesting. Your subscription is rarely just access to the platform. You’ve got onboarding, implementation, training, premium support, custom integrations, API credits, sandbox environments. Under ASC 606, anything that’s distinct, meaning the customer can benefit from it on its own and it’s separately identifiable from the rest of the contract, is a separate performance obligation that needs its own accounting treatment.*4
Step 3: Determine the transaction price. The whole nut you expect to receive over the contract term. If your pricing is a flat monthly fee, easy. If you’ve got usage-based components, performance bonuses, volume discounts, refunds, or service credits for SLA misses, you’ve got variable consideration. ASC 606 requires you to estimate that variable amount at contract inception and apply a constraint, meaning you only include it in your transaction price to the extent it’s probable a significant reversal won’t happen later.*5
Step 4: Allocate the transaction price across performance obligations. If you’ve got a $100K bundle that includes a $90K annual subscription and a $10K implementation, and you’re discounting the whole package to $85K, you allocate that $85K based on the relative standalone selling price (SSP) of each piece.*4 SSP is the price you’d charge for that item if you sold it on its own. Founders without strong sales operations often haven’t documented SSPs at all, and that’s a flag the auditor will pull on hard.
Step 5: Recognize revenue when (or as) the obligation is satisfied. For subscription access, control transfers over time, so you recognize ratably across the term. For a one-time deliverable like data migration that’s genuinely distinct, recognition might happen at a point in time. For usage-based pricing, you recognize as the customer consumes.
The Traps I Actually See
All right, here’s where the rubber meets the road. These are the patterns I’ve watched trip up SaaS founders heading into their first audit.
Trap 1: Recognizing annual contracts upfront. This is the most common one. Customer signs a $120K annual deal in January, pays the whole thing upfront, and revenue gets booked at $120K in January. Wrong. That’s $10K a month over 12 months under ASC 606, with $120K sitting in deferred revenue on the balance sheet at signing, releasing $10K each month into recognized revenue.*6
Trap 2: Booking implementation and setup fees on day one. Founders love this one because the cash hits the bank. But if your setup work doesn’t provide standalone value, meaning the customer can’t actually use what they paid for the setup without the ongoing subscription, that fee gets recognized over the contract term, not upfront.*7 If implementation IS distinct, like a real data migration with documented deliverables that have value on their own, then it’s a separate performance obligation with its own recognition pattern. The auditor is going to ask which one applies, and they’re going to want documented analysis behind your answer.
Trap 3: Prepaid credit and consumption models. This is the new wild west in SaaS pricing. Customer pays $100K upfront for credits they consume against AI calls, API hits, or some other unit of usage. That cash sits as deferred revenue until the credits actually get used, and you recognize per credit consumed. The math gets cumbersome fast when you’ve got 200 customers, each with different per-credit pricing, different usage patterns, and credits rolling over month to month. I’ve seen this go sideways where the company’s ARR number from their CRM didn’t match recognized revenue in the books by hundreds of thousands, because nobody had built the bridge between the usage data and the general ledger.
Trap 4: Contract modifications mid-stream. Customer upgrades from Pro to Enterprise mid-contract. Or downgrades. Or adds a module. Each one requires a judgment: is this a separate contract priced at standalone selling price, or is it a modification of the existing contract that triggers a reallocation across the remaining term? Skipping this analysis is a fast way to misstate revenue.*8
Trap 5: Variable consideration without a constraint. You signed a deal with a $200K performance bonus if the customer hits a usage threshold by year end. Including the full $200K in your transaction price on day one, when there’s a real chance it gets reversed, is exactly what the constraint is designed to prevent. You estimate, and you only include the amount where significant reversal isn’t probable. Then you re-estimate at every reporting period.*5
What Auditors Actually Want to See
A few things separate the audits that go smoothly from the ones that turn into a six-month forensic project.
A revenue recognition policy. Documented. Written down. Applied consistently. If you can’t hand the auditor a policy memo that walks through how you treat each type of contract, they’re going to write the policy themselves and then test you against it. That goes badly.
Standalone selling price documentation. For each performance obligation, what’s your SSP, how did you arrive at it, and is it consistent across customers? If you’re using the residual approach for items where SSP is highly variable or uncertain, document why.
Contract files. Every contract, every order form, every modification. Filed where someone other than you can find it. Auditors are going to pull a sample and want to trace from contract to recognized revenue and back to deferred revenue on the balance sheet. If they can’t follow the breadcrumbs, the sample fails and they pull a bigger one.
Roll-forward schedules. Deferred revenue at the start of the period, plus billings, less revenue recognized, equals deferred revenue at the end. Tied out, supported, by customer. We have our team build these as part of the monthly close so they’re sitting on a silver platter when audit fieldwork shows up.
Disclosures. ASC 606 expanded the disclosure requirements significantly: disaggregation of revenue, contract balances, remaining performance obligations, and significant judgments. Your audited financials are going to include footnotes you’ve probably never written before.*9
The Tech Stack That Makes This Manageable
You can run all of this in spreadsheets up to a point. I’ve got clients doing it manually through Excel and getting it right because their volume is low enough. But once you get past 30 to 50 active contracts with any complexity, the spreadsheet approach becomes a liability.
Our preferred SaaS stack at High Rock looks like this: Xero for the general ledger, Brex or Ramp for spend management, Gusto or Rippling for payroll, and Maxio for revenue recognition automation when contract complexity warrants it. Maxio handles the contract parsing, performance obligation tracking, deferred revenue waterfalls, and the disclosures auditors expect, which means your team isn’t living in a 47-tab spreadsheet during fieldwork.*10 Tabs has positioned itself in the prepaid-credit and usage-based space, and that area is still maturing, so be honest with yourself about what your billing actually looks like before picking a tool. In that type of scenario, the data piping between your CRM, your billing engine, and your GL matters more than any single tool.
The Game Plan
If you’re staring down your first audit and the rev rec piece feels foggy, here’s what I’d do this week.
Pull your top 10 customer contracts and read them. Line up signed date, term, total contract value, billing cadence, and any non-subscription components like setup, training, or professional services.
Map each contract to performance obligations. Subscription access is one. Anything else, ask the distinct test: can the customer benefit from it without the subscription, and is it separately identifiable?
Build the deferred revenue waterfall. For each contract, map out month by month how much revenue gets recognized. Tie that back to your bank deposits and your invoicing.
Document your policy. Even a one-page memo is better than nothing. Auditors want to see that you thought about it before they walked in the door.
Get a second set of eyes on it before the auditor sees it. That’s the part where we usually come in.
We’ve taken founders through a lot of first audits, including a few where we had to clean up two or three years of revenue that had been recognized the wrong way. The cleanup is doable, but it’s a whole lot easier if we catch it before the auditor does. We want to dot the I’s and cross the T’s, get your books squeaky clean, attach all the support so the auditor can follow the breadcrumbs, and have you ready to go off to the races without sweating fieldwork. Once we’re working together, we’re just a Slack message away if you need a quick sanity check.
If you want a gut check on where you stand before audit fieldwork, two ways to grab time on my calendar:
• Hawaiian Shirt Friday Ask an Accountant Hour, every Friday at 10AM PT, no charge, no commitment: Join the Zoom
• 30-minute meeting on my calendar: Book a slot
Sources
*1 ASC 606 effective dates and ASU 2020-05 deferral for private entities, Holthouse Carlin & Van Trigt LLP. https://www.hcvt.com/article-ASC-606-Revenue-Recognition-Contracts
*2 Core principle of ASC 606 (Topic 606, Revenue From Contracts With Customers), BDO Blueprint. https://arch.bdo.com/revenue-recognition-under-asc-606
*3 Step 1 contract criteria under ASC 606, Stripe ASC 606 how-to guide. https://stripe.com/resources/more/asc-606-how-to-guide
*4 SaaS performance obligations, distinct test, and standalone selling price allocation, DualEntry. https://www.dualentry.com/blog/saas-revenue-recognition
*5 Variable consideration and the constraint under ASC 606, Deloitte DART (ASC 606-10-32-9 through 32-13). https://dart.deloitte.com/USDART/home/codification/revenue/asc606-10/roadmap-revenue-recognition/chapter-6-step-3-determine-transaction/6-3-variable-consideration
*6 Annual SaaS subscription recognition example, Maxio. https://www.maxio.com/blog/saas-revenue-recognition-asc-606
*7 Setup and implementation fee treatment under ASC 606, HubiFi. https://www.hubifi.com/blog/asc-606-implementation-fees-guide
*8 Contract modifications under ASC 606 (606-10-25-10 through 25-13), BillingPlatform. https://billingplatform.com/blog/contract-modifications-revenue-recognition
*9 ASC 606 disclosure requirements for SaaS companies, Synder. https://synder.com/blog/asc-606-revenue-recognition/
*10 SaaS revenue recognition tooling and Maxio Advanced Revenue Management, Maxio. https://www.maxio.com/blog/saas-revenue-recognition-asc-606
Enjoyed this article? Consider Sharing
Author
