
ASC 606 is the accounting standard that decides when the cash a customer pays you actually becomes revenue on your income statement — and for a SaaS company, the answer is almost never “when the money hits the bank.” A customer can wire you $120,000 today for a year of software, and under ASC 606 you have earned exactly $0 of revenue at that moment. You earn it at roughly $10,000 a month as you deliver the service. Most founders at $5M to $15M ARR have a vague sense this is true and have never been walked through why, how, or what it costs them when they get it wrong. This guide fixes that.
I am writing this for the technical founder building toward an exit, not for an accountant. You do not need to do ASC 606 — your controller or outside CPA does that. You need to understand it well enough that it never surprises you: when a board member asks why recognized revenue is half your bookings, when a deferred-revenue balance shows up as a liability on your balance sheet, and — the moment it matters most — when a buyer’s accountants tear into your revenue during due diligence and decide whether your reported growth is real. ASC 606 is where “we signed $2M in new deals this quarter” and “we recognized $600K of revenue this quarter” stop being a contradiction and start being two different, both-correct numbers. If that gap has ever confused you, this is the article that closes it.
This is educational, not accounting or legal advice. I am explaining how ASC 606 works so you can have an informed conversation with your finance team and your buyer’s, not so you can apply it yourself. ASC 606 (formally FASB Accounting Standards Codification Topic 606, Revenue from Contracts with Customers) is a regulated standard, and the correct treatment depends entirely on the specific language in your contracts and your company’s circumstances. Engage a qualified CPA or auditor for your actual numbers, and run anything material past them before you act on it.
What ASC 606 Actually Is — and Where It Came From
Start with the name, because it tells you the scope. ASC stands for Accounting Standards Codification — the organized rulebook of U.S. Generally Accepted Accounting Principles (GAAP), the standard accounting language every audited U.S. company speaks. 606 is the specific topic number inside that rulebook that governs revenue. Its full title is Revenue from Contracts with Customers, and that phrase is the whole idea in five words: revenue comes from delivering on a contract, so the accounting follows the delivery, not the payment.
ASC 606 was issued by the Financial Accounting Standards Board (FASB) — the independent body that writes U.S. accounting rules — through Accounting Standards Update (ASU) 2014-09, released in May 2014. It was a joint project with the international standard-setter, so there is a near-identical global twin called IFRS 15 (International Financial Reporting Standards, standard 15) that companies outside the U.S. use. If you ever sell to or merge with a company on international books, the two standards share the same five-step backbone, which is the point — they were built together so revenue means the same thing everywhere.
The timeline matters for one practical reason: ASC 606 is not optional and not new. Public companies adopted it for fiscal years starting after December 15, 2017. Private companies — which is you — were required to adopt it for annual reporting periods beginning after December 15, 2018 (the deadline was later pushed one year, to periods beginning after December 15, 2019, for companies that had not yet adopted, under a separate update). Either way, if your books are audited or you are heading toward a sale, your financials are expected to be on ASC 606 already (the SEC’s Financial Reporting Manual lays out these adoption dates and the IFRS 15 alignment). A buyer will assume it. If your revenue is still recognized the old way — or worse, recognized when cash arrives — that is a finding, and findings cost you.
Before ASC 606, revenue rules were a patchwork of industry-specific guidance (the prior standard was ASC 605). The whole reason FASB replaced it was to create one principle-based model that works the same for a software company, a manufacturer, and a construction firm. For SaaS, that single model is the five-step process this guide is built around.
Why ASC 606 Matters to You Specifically: The Exit Lens
Here is the framing no generic accounting article will give you, and the reason this matters more for you than for a CFO who just wants clean books. When you sell your company, the buyer does not pay you for the cash that came in the door. They pay a multiple of your recurring, recognized revenue — and ASC 606 is the standard that defines what counts as recognized revenue and how predictable it is.
Three things a buyer cares about run straight through ASC 606:
- Revenue quality. A buyer pays the highest multiples for revenue that is contractual, recurring, and recognized ratably (smoothly, over the service period) rather than lumpy or front-loaded. ASC 606 is what forces the smoothing. A company that books a $1.2M three-year deal and correctly recognizes it over 36 months looks like a steady, durable revenue stream. A company that recognized the whole $1.2M upfront looks like it had one good quarter and nothing since. Same contract, very different story to a buyer — and only one of them is ASC 606-compliant.
- The bookings-to-revenue bridge. During diligence, a buyer reconciles what you sold (bookings) to what you recognized (revenue) to what you collected (cash). If those three do not tie out cleanly under ASC 606, every number you have reported is suspect, and suspicion is what compresses a multiple. Clean ASC 606 accounting is part of what makes a company easy to buy.
- Deferred revenue as an assumed obligation. That $120,000 annual prepayment sits on your balance sheet as deferred revenue — a liability, because you owe the customer a year of service they already paid for. When a buyer acquires you, they inherit that obligation: they have to deliver the service without collecting the cash, because you already spent it. Buyers know this and adjust the deal for it. If you do not understand your deferred revenue, you will be blindsided at the negotiating table.
The through-line of how the best founders think is that you are not selling the business you have today — you are selling a predictable, low-risk engine the buyer can run for years. Risk is the gap between your Excel model and reality, and sloppy revenue recognition is one of the most common places that gap hides. ASC 606 done right is a quiet form of de-risking. Done wrong, it is a landmine you step on at the worst possible moment. This is exactly the kind of financial hygiene that belongs in any serious SaaS exit strategy, and it is squarely the job of a SaaS CFO — if you do not have one yet, ASC 606 complexity is one of the signals you are close to needing one.
Bookings vs. Billings vs. Recognized Revenue vs. ARR
You cannot understand ASC 606 until four words stop blurring together. Founders use these interchangeably in board meetings and then wonder why their finance lead winces. Each measures a different thing, at a different moment, and ASC 606 governs only one of them. Here is the crisp version.
| Term | What it measures | When it is counted | Where it lives | Governed by ASC 606? |
|---|---|---|---|---|
| Bookings | The total value a customer has committed to in a signed contract | When the contract is signed | A sales metric — not on the financial statements | No |
| Billings | The amount you have invoiced the customer so far | When you send the invoice | Drives accounts receivable and cash | No (billing terms are a business choice) |
| Recognized Revenue | The portion of the service you have actually delivered | Ratably, as you deliver the service | The income statement (P&L) | Yes — this is what ASC 606 governs |
| ARR | Your annualized recurring revenue run-rate at a point in time | A snapshot, anytime | An operating metric, not a GAAP figure | No (but built from recognized recurring revenue) |
Walk through one deal to see all four at once. A customer signs a 2‑year contract for your software at $60,000 per year, paid annually in advance.
- Bookings the day they sign: $120,000 — the full two-year committed value (this is also the Total Contract Value, or TCV). If you want the deeper distinction here, see the difference between bookings and revenue and what TCV is.
- Billings in year one: $60,000 — you invoice the first annual period now; you will invoice the second $60,000 a year from now.
- Recognized revenue in the first month: $5,000 — one month of a $60,000 annual service ($60,000 / 12). ASC 606 says you have earned exactly that much by delivering one month.
- ARR the day they sign: $60,000 — the annualized recurring run-rate from this customer.
Four different numbers — $120,000, $60,000, $5,000, $60,000 — all from the same single deal, all correct, all answering different questions. Founders get confused because they reach for “bookings” when a buyer or board wants “recognized revenue,” and on a multi-year deal the two diverge sharply — here, $120,000 of bookings versus $60,000 of recognized revenue in the first year, a 2x gap that widens with the contract length. ASC 606 is the rulebook that pins down the $5,000-a-month number specifically. Everything else in this guide is about how that number gets calculated when the contract is more complicated than one clean subscription. The relationship between the run-rate and the GAAP figure is worth understanding on its own; I have written the full breakdown of ARR vs. revenue and how annual recurring revenue differs from revenue.
A note on a common trap: ARR is an operating metric, not a GAAP number, and ASC 606 does not define it. That is not a loophole — it means you have to be disciplined about what you put in your ARR. Counting a one-time setup fee or a cancellable pilot as “ARR” inflates a number a buyer will recompute and discount. Keep ARR to genuinely recurring, contracted revenue; the meaning of ARR vs. revenue and what ARR actually is are worth getting precise about before a diligence process, not during one.
The ASC 606 Five-Step Model
The entire standard reduces to a five-step decision process the standard calls the five-step model. Your accountant runs every customer contract through these five steps to decide how much revenue to recognize and when. You should understand each step well enough to know where the judgment calls — and the audit risk — live.
Here is each step in plain English, with the SaaS-specific judgment calls flagged.
Step 1: Identify the Contract
A contract is an agreement that creates enforceable rights and obligations. Under ASC 606 it does not have to be a signed paper document — it can be a click-through, an oral agreement, or one implied by your normal business practice — but it does have to clear a bar: both parties have approved it and are committed, the rights and payment terms are identifiable, it has commercial substance, and it is probable you will actually collect what you are owed.
That last condition — the collectibility threshold — is the SaaS gotcha. If a customer’s ability to pay is genuinely shaky, you may not have a contract for accounting purposes yet, even though sales is celebrating the win. The other trap is the cancellable contract: if your “annual” deal lets the customer walk after 30 days with no penalty, the enforceable term for accounting is closer to that 30-day out than the year on the order form. That distinction quietly shrinks how much you can treat as committed — and it is exactly the kind of thing a buyer’s diligence team checks line by line.
Step 2: Identify the Performance Obligations
A performance obligation is a distinct promise inside the contract — a specific thing you have committed to deliver. The question ASC 606 forces is: how many separate promises did you actually make? Each distinct one gets accounted for on its own.
For a pure-subscription product, this is easy: the promise is “access to the software for the term,” one performance obligation, recognized smoothly over time. It gets interesting when you bundle. Sell a SaaS subscription plus a one-time onboarding/implementation service plus premium support, and you may have three performance obligations — each potentially recognized on its own schedule. A promise is “distinct” if the customer can benefit from it on its own and it is separately identifiable from the other promises. Getting this count right is the hinge the next two steps swing on, and it is where companies most often need an outside accountant to make a defensible call.
Step 3: Determine the Transaction Price
The transaction price is the total consideration you expect to be entitled to for delivering everything in the contract — the real economic price, not necessarily the list price. For a clean subscription it is just the contract value. The complications, all common in SaaS, are:
- Variable consideration — amounts that are not fixed, like usage-based overage fees, tiered pricing, or performance bonuses. ASC 606 makes you estimate this variable amount up front (using either the most-likely-outcome or a probability-weighted expected value) and only include it to the extent it is highly probable it will not reverse later.
- Discounts and credits — a promo discount or service credits reduce the transaction price.
- Refunds and money-back guarantees — expected refunds come out of the transaction price.
Note what is not in here: the customer’s creditworthiness was already handled in Step 1, and sales tax you collect on the government’s behalf is excluded. The transaction price is what you get to keep for what you deliver.
Step 4: Allocate the Transaction Price
If you identified more than one performance obligation in Step 2, Step 4 splits the total transaction price among them — and the rule is that you allocate based on each obligation’s standalone selling price (SSP): what you would charge for that item if you sold it by itself.
This is where bundling and discounting collide. Say you sell a bundle for $100,000 that includes a subscription with an SSP of $90,000 and an implementation service with an SSP of $30,000. The standalone prices total $120,000, but the customer paid $100,000 — a $20,000 bundle discount. ASC 606 makes you spread that discount proportionally across both obligations based on their relative SSPs, not dump it all on whichever one is convenient. So the subscription is allocated 90/120 of the $100,000 and implementation gets 30/120. When you do not have a clean standalone price for something (common for a bespoke implementation), the standard lets you estimate the SSP — but the estimate has to be defensible, which again is where your accountant earns their fee.
Step 5: Recognize Revenue as Obligations Are Satisfied
Finally, you recognize revenue for each performance obligation as you satisfy it — as control of the service transfers to the customer. ASC 606 splits this into two patterns:
- Over time — when the customer consumes the benefit continuously, which is the typical SaaS subscription. You recognize ratably across the service period (usually evenly, month by month).
- At a point in time — when control transfers at a single moment, like a one-time setup task that is done and delivered, or a perpetual license handed over.
For most of your recurring revenue, Step 5 means “spread it evenly over the term,” which is why a $60,000 annual subscription becomes $5,000 of recognized revenue each month. The setup fee or the one-time piece may land differently, which is the whole reason the previous four steps exist. This idea — that the nature of the revenue determines how and when it hits the P&L — is the foundation of the entire SaaS revenue model and what separates durable SaaS revenue from one-time sales dressed up to look recurring.
A Full Worked Example: A $1.35M Multi-Element Deal
Abstract steps do not stick. Here is a realistic deal for a company in your range, run all the way through ASC 606 so you can see the numbers move.
A mid-market customer signs a 2‑year contract with three elements. Here are the contract prices and the standalone selling prices for each:
| Element | What it is | Contract price | Standalone selling price (SSP) |
|---|---|---|---|
| Software subscription (2 years) | Recurring access to the platform | $1,200,000 | $1,300,000 |
| Implementation (one-time) | Onboarding, data migration, configuration | $100,000 | $150,000 |
| Premium support (2 years) | Dedicated support tier | $50,000 | $50,000 |
| Total | $1,350,000 | $1,500,000 |
The customer committed to $1,350,000 in bookings (TCV). Their standalone prices would have totaled $1,500,000, so they received a $150,000 bundle discount. Now run the five steps.
Step 1 — Contract. Approved, committed, payment terms set, collectibility probable, non-cancellable for the two years. It is a valid contract.
Step 2 — Performance obligations. Three distinct promises — subscription, implementation, support — because the customer benefits from each and they are separately identifiable. (In practice you must test whether implementation is truly distinct or so intertwined with the subscription that it is not separable; here we treat it as distinct.)
Step 3 — Transaction price. $1,350,000 total. No variable consideration in this version, no expected refunds.
Step 4 — Allocate by relative SSP. Spread the $1,350,000 across the three obligations in proportion to their $1,500,000 of standalone prices. The allocation ratio is $1,350,000 / $1,500,000 = 0.90, so each obligation is recognized at 90% of its SSP:
| Element | SSP | Allocation ratio | Allocated transaction price |
|---|---|---|---|
| Subscription | $1,300,000 | 0.90 | $1,170,000 |
| Implementation | $150,000 | 0.90 | $135,000 |
| Premium support | $50,000 | 0.90 | $45,000 |
| Total | $1,500,000 | $1,350,000 |
Step 5 — Recognize as satisfied.
- Subscription ($1,170,000) recognized over time, evenly across 24 months = $48,750 per month.
- Premium support ($45,000) recognized over time, evenly across 24 months = $1,875 per month.
- Implementation ($135,000) recognized when that one-time obligation is satisfied. Assume it is delivered over the first 3 months of onboarding, recognized evenly = $45,000 per month for months 1 through 3, then $0.
So your recognized revenue in month 1 is $48,750 + $1,875 + $45,000 = $95,625. In month 4, once implementation is done, it drops to $48,750 + $1,875 = $50,625 per month for the remainder of the term. Notice the shape: revenue is higher in the first three months because the implementation obligation is being satisfied, then settles into the steady recurring run-rate.
Now contrast that with the cash. If the customer prepaid year one — $600,000 of subscription plus $100,000 of implementation plus $25,000 of support = $725,000 invoiced upfront, depending on billing terms — you collected far more in month 1 than you recognized. The difference becomes deferred revenue, a liability, and it releases into recognized revenue as you deliver. That gap between cash-in and revenue-earned is the single most important thing ASC 606 creates, and it is the subject of the next section.
Deferred Revenue: The Liability That Confuses Every First-Time Founder
When a customer pays you before you have delivered the service, you have collected cash you have not earned. ASC 606 (working with the broader balance-sheet rules) says that unearned cash is a liability called deferred revenue (sometimes “unearned revenue” or a “contract liability”). It is a liability because you owe the customer something — the service they paid for — and if you went out of business tomorrow you would theoretically have to refund the undelivered portion.
This feels backwards to founders the first time they see it. You have more cash and your balance sheet shows a bigger liability. But that is exactly right, and it is one of the healthiest liabilities a business can have: it is an interest-free prepayment from customers that funds your operations. Strong SaaS companies often carry large deferred-revenue balances precisely because customers are happy to pay annually upfront.
Here is the mechanic, using the annual-prepaid subscription from earlier ($600,000/year, billed upfront):
| Month | Cash collected | Revenue recognized | Deferred revenue remaining (end of month) |
|---|---|---|---|
| Month 0 (invoice paid) | $600,000 | $0 | $600,000 |
| Month 1 | $0 | $50,000 | $550,000 |
| Month 2 | $0 | $50,000 | $500,000 |
| Month 3 | $0 | $50,000 | $450,000 |
| Months 4 through 11 | $0 | $50,000 each | declining by $50,000 each |
| Month 12 | $0 | $50,000 | $0 |
Each month, $50,000 ($600,000 / 12) moves off the balance sheet (deferred revenue shrinks) and onto the income statement (recognized revenue grows). The cash came in once; the revenue is earned over twelve months. By month 12 the liability is fully burned down to zero and you have recognized the entire $600,000.
Why you care at exit: deferred revenue is a real obligation a buyer inherits. They take on the duty to deliver the service, but you already spent the cash. In most deals this gets accounted for explicitly in the purchase price (the buyer is effectively compensated for funding the obligation they are assuming). A large, well-documented deferred-revenue balance is also positive evidence — it proves customers pay you upfront, which signals confidence and improves cash dynamics. But it must be clean and reconcilable. A deferred-revenue balance that does not tie to your contracts and billing is a diligence red flag. This is core to the broader SaaS financial model and shows up directly in any SaaS revenue forecasting model you build.
The SaaS-Specific Issues ASC 606 Forces You to Get Right
The clean examples above are the easy case. Real SaaS contracts have wrinkles, and each one changes the recognition pattern. Here are the ones that matter most for a company at your stage.
Upfront, Setup, and Implementation Fees
A one-time setup fee (also called an implementation or onboarding fee — a charge to get the customer live) is the classic ASC 606 trap. Your instinct is to recognize it immediately because you did the work upfront and collected the cash. ASC 606 often disagrees. The question is whether that setup activity is a distinct performance obligation (something the customer separately values and could benefit from on its own) or merely a setup activity that is part of giving them access to the subscription.
If the setup work is not distinct — if it is just the cost of switching the customer on, with no standalone value — then ASC 606 says you cannot recognize it upfront. Instead you spread that fee over the period the customer benefits, which is the expected life of the relationship, not just the contract term. A $30,000 setup fee on a customer you expect to keep for three years might be recognized at roughly $833/month over 36 months, not booked as $30,000 of revenue on day one. That single rule has sunk more than one startup’s “great quarter.”
Multi-Year Prepaid Contracts
A customer who prepays two or three years upfront hands you a pile of cash and a large deferred-revenue liability. The recognition is straightforward — spread evenly over the service term — but two things bite. First, the cash-vs-revenue gap is huge in year one (you collected three years, recognized one), which makes your bank balance look far healthier than your P&L. Second, if there is a material financing component — meaning the multi-year prepayment is large enough that it effectively includes you receiving a loan from the customer — ASC 606 can require you to account for an implied interest element. For most SaaS deals of a couple of years or less this is ignored as immaterial, but on long, large prepayments it is a real consideration your accountant will flag.
Usage-Based and Consumption Pricing
Usage-based pricing (billing for what the customer actually consumes — API calls, storage, seats used, messages sent) is variable consideration, and it is recognized differently from a flat subscription. The general principle: you recognize usage revenue as the usage occurs, in the period the customer consumes it, because that is when you satisfy the obligation. A customer who runs 2 million API calls in March generates March revenue, not revenue smoothed across the year. Where it gets complex is tiered pricing, minimum commitments, and prepaid usage credits — each requires estimating variable consideration and constraining it to amounts that will not reverse. If usage is a meaningful slice of your revenue, this is one of the first places a buyer’s accountants will dig, because it is the easiest place to accidentally overstate revenue.
Contract Modifications, Upgrades, and Downgrades
Customers upgrade, downgrade, add seats, and renew early — a contract modification is any change to the scope or price of an existing contract. ASC 606 has specific rules for whether a modification is treated as (a) a separate new contract, (b) a termination of the old contract and creation of a new one, or © a change blended into the existing contract and caught up. Which path applies depends on whether the added goods or services are distinct and priced at their standalone value:
- Add a clearly distinct service at its standalone price, and it is usually a separate contract, accounted for on its own.
- Upgrade to a more expensive tier mid-term, and it is often a modification of the existing contract, with revenue prospectively re-spread over the remaining term.
- A mid-term downgrade or partial cancellation means you adjust recognized revenue and the remaining schedule accordingly.
For a fast-growing SaaS company where expansion revenue is the engine of net revenue retention, modifications are not an edge case — they are constant. Getting the treatment consistent is what keeps your reported expansion revenue trustworthy, which directly supports the revenue retention story you will tell a buyer.
Commission Capitalization Under ASC 340–40
Here is the companion rule most founders have never heard of, and it surprises people because it is about costs, not revenue. ASC 340–40 is the cost-side guidance that ships alongside ASC 606, and it governs the incremental costs of obtaining a contract — overwhelmingly, that means sales commissions.
The plain-English version: when you pay a sales rep a commission to close a deal, ASC 340–40 says you generally cannot expense that whole commission in the month you pay it. Because that commission “bought” you a customer who will generate revenue for years, the cost has to be capitalized (recorded as an asset) and amortized (expensed gradually) over the period you benefit from that customer — which is the expected customer lifetime, not just the initial contract term. The logic is matching: spread the cost of acquiring the customer over the same period you recognize the revenue they bring.
A concrete version: you pay a rep a $24,000 commission to land a customer on a 1‑year contract, but your data says that type of customer stays an average of 4 years. ASC 340–40 generally makes you capitalize the $24,000 and amortize it at $500/month over 48 months — not expense $24,000 in month one. There is a practical shortcut — the practical expedient — that lets you expense commissions immediately if the amortization period would be one year or less. But here is the catch most founders miss: because SaaS customers typically renew and stay multiple years, that expected-life period is usually well over a year, so most SaaS companies do not qualify to expense new-customer commissions immediately. Misusing that shortcut is one of the most common revenue-and-cost findings auditors and buyers catch.
Why this matters to you: capitalizing commissions changes the shape of your profitability. Expensing commissions upfront makes a high-growth quarter look unprofitable; capitalizing them spreads the cost and reveals the real unit economics underneath. It connects directly to your cost of goods sold for SaaS treatment and to how a buyer reads your margins — and it is the kind of thing a thorough SaaS finance function has buttoned up long before diligence starts.
What Most Founders Get Wrong About ASC 606
The same handful of mistakes show up again and again, and every one of them is avoidable.
- Confusing cash with revenue. The single most common error: treating money collected as revenue earned. A $300,000 annual prepayment is not $300,000 of Q1 revenue — it is $25,000/month of recognized revenue and a $275,000 deferred-revenue liability after month one. Founders who run their mental P&L on cash get a nasty surprise when their accountant shows them GAAP revenue.
- Recognizing setup and implementation fees upfront. As covered above, a non-distinct setup fee usually cannot be taken as day-one revenue. Booking it upfront overstates current revenue and creates a restatement risk in diligence.
- Counting bookings (or even billings) as revenue in board decks. Reporting “$2M in revenue this quarter” when $2M was bookings and recognized revenue was $600K is not lying — but it confuses your board and trains everyone to watch the wrong number. A buyer will only credit recognized, recurring revenue.
- Calling cancellable or shaky-collectibility deals “ARR.” If the customer can leave in 30 days or might not pay, the enforceable, recognizable amount is far less than the order-form number. Inflated ARR is the first thing a buyer recomputes — and the gap between your ARR and their recomputed ARR poisons trust for the whole deal.
- Expensing all sales commissions immediately. Under ASC 340–40 most SaaS companies must capitalize and amortize new-customer commissions over the expected customer life. Getting this wrong distorts profitability and is a frequent audit finding.
- Waiting until the deal is live to clean up revenue recognition. Discovering during diligence that three years of revenue was recognized inconsistently is a brutal, expensive time to find out. ASC 606 compliance is cheap to maintain as you go and painful to retrofit under deal pressure.
The pattern: each mistake makes your reported numbers diverge from the numbers a buyer (or auditor) will independently recompute. Every point of divergence is a point of risk, and risk is what compresses your multiple. Clean ASC 606 accounting is not bureaucracy — it is protecting the value of the thing you are building toward selling.
How ASC 606 Connects to Your Valuation and Diligence
Tie it all together with the lens that matters: the sale. When a buyer evaluates your company, ASC 606 shapes the three things that drive your price.
Revenue quality and the recurring-revenue premium. Buyers pay the richest multiples for revenue that is contractual, recurring, and recognized smoothly over time — exactly the profile ASC 606 produces for a clean subscription business. The more of your revenue that is genuinely recurring and ratably recognized (versus one-time services, lumpy implementation revenue, or front-loaded fees), the higher the multiple. ASC 606 is the standard that proves the recurring nature of your revenue to a skeptical buyer. If you want the market context for what that premium looks like, see how SaaS revenue multiples move with revenue quality and growth, and why businesses with recurring revenue command a premium.
The quality-of-earnings review. Serious buyers commission a Quality of Earnings (QoE) study — an independent deep-dive that reconstructs your real, normalized revenue and earnings. The QoE team lives and breathes ASC 606. They will test your performance-obligation judgments, your deferred-revenue burn-down, your commission capitalization, and your bookings-to-revenue-to-cash bridge. If your accounting holds up, diligence moves fast and your credibility rises. If it does not, every problem becomes a price negotiation in the buyer’s favor.
De-risking the forecast. The buyer is underwriting your future revenue, and the credibility of that forecast depends on the integrity of your historical revenue. Consistent ASC 606 accounting means your past is reliable, which makes your projections believable, which protects your multiple. This is the practical mechanism behind the idea that risk — the gap between your model and reality — is a multiple killer. When you eventually sell your SaaS company, the cleanliness of your revenue recognition is one of the quiet differences between a smooth close at a strong multiple and a grinding negotiation that chips away at your number.
The takeaway for a founder at $5M to $15M ARR: you do not need to become a revenue-recognition expert, but you do need to make sure someone on your team is, well before you run a process. ASC 606 is not a tax you pay — it is an asset you build. Done routinely and correctly, it is invisible. Neglected, it surfaces at the exact moment you can least afford it.
Frequently Asked Questions
What is ASC 606 in simple terms?
ASC 606 is the U.S. accounting standard (issued by the FASB) that governs how and when a company records revenue from customer contracts. Its core rule is that you recognize revenue as you deliver the service, not when you get paid. For SaaS, that means a $120,000 annual prepayment is not $120,000 of revenue today — it is recognized at roughly $10,000 per month over the year as you provide access. The cash you have collected but not yet earned sits on your balance sheet as deferred revenue. The standard organizes all of this into a five-step model: identify the contract, identify the performance obligations, determine the transaction price, allocate that price, and recognize revenue as obligations are satisfied.
What are the five steps of ASC 606?
The ASC 606 five-step model is: (1) Identify the contract with the customer — confirm it is enforceable and collection is probable; (2) Identify the performance obligations — the distinct promises you have made, like subscription, implementation, and support; (3) Determine the transaction price — the total you expect to keep, adjusted for discounts, refunds, and variable amounts; (4) Allocate the transaction price across the obligations based on each one’s standalone selling price; and (5) Recognize revenue as you satisfy each obligation, either over time (typical subscriptions) or at a point in time (one-time deliverables).
When did ASC 606 take effect for private companies?
Private companies were required to adopt ASC 606 for annual reporting periods beginning after December 15, 2018 (public companies adopted a year earlier, for periods after December 15, 2017). The private-company deadline was later deferred by one year — to periods beginning after December 15, 2019 — for companies that had not yet adopted. The practical takeaway: if your books are audited or you are heading toward a sale today, your financials are expected to already be on ASC 606. The standard was issued by the FASB via ASU 2014-09, and its international twin, IFRS 15, shares the same five-step model.
What is the difference between bookings, billings, recognized revenue, and ARR?
They measure four different things. Bookings is the total value a customer commits to when they sign — counted at signing, not on the financials. Billings is what you have invoiced so far — it drives cash and receivables. Recognized revenue is the portion of the service you have actually delivered — this is the only one ASC 606 governs, and it is what hits your income statement. ARR is your annualized recurring revenue run-rate at a point in time — an operating metric, not a GAAP figure. On a 2‑year, $120,000 deal billed annually, you could simultaneously have $120,000 of bookings, $60,000 of year-one billings, $5,000 of first-month recognized revenue, and $60,000 of ARR — all correct, all different.
How does ASC 606 treat SaaS setup and implementation fees?
It depends on whether the setup work is a distinct performance obligation. If the implementation has standalone value the customer separately benefits from, it can be recognized as its own obligation, often as it is delivered. But if the setup is simply the cost of switching the customer on — not distinct from giving them access to the subscription — ASC 606 generally requires you to spread that fee over the expected customer relationship, not recognize it upfront. A $30,000 setup fee for a customer you expect to keep three years might be recognized around $833/month over 36 months rather than as day-one revenue. Recognizing non-distinct setup fees upfront is one of the most common ASC 606 mistakes.
What is ASC 340–40 and how does it relate to ASC 606?
ASC 340–40 is the companion cost-capitalization guidance that ships with ASC 606. While ASC 606 governs revenue, ASC 340–40 governs the incremental costs of obtaining a contract — mainly sales commissions. It generally requires you to capitalize a commission (treat it as an asset) and amortize it (expense it gradually) over the expected customer lifetime, rather than expensing the whole amount when you pay it. A $24,000 commission on a customer expected to stay four years would typically be amortized at $500/month over 48 months. There is a practical expedient allowing immediate expensing if the period is a year or less, but because SaaS customers usually stay multiple years, most SaaS companies do not qualify to use it for new-customer commissions.
Why does ASC 606 matter when I sell my company?
Because a buyer pays a multiple of your recognized, recurring revenue — and ASC 606 defines what counts. During diligence, a buyer (and their Quality of Earnings team) reconciles your bookings to your recognized revenue to your cash, tests your performance-obligation and deferred-revenue judgments, and checks your commission capitalization. Clean ASC 606 accounting makes your revenue look as durable and predictable as it really is, which supports the highest multiples. Sloppy or inconsistent recognition turns every discrepancy into a price negotiation in the buyer’s favor. ASC 606 done right is a quiet form of de-risking the business you are selling.

