ASC 606 Revenue Recognition: The Operator's Guide
ASC 606 doesn't fail because your rev rec engine is bad. It fails because billing and recognition live in separate systems and the contract-to-revenue trail breaks. LedgerUp runs both on one reconciled ledger. Here's the five-step model, where teams actually break it, and how to fix it.
What is ASC 606?
ASC 606 is the U.S. revenue recognition accounting standard — FASB Accounting Standards Codification Topic 606, “Revenue from Contracts with Customers.” It establishes a single five-step model that all entities apply to recognize revenue: (1) identify the contract, (2) identify the performance obligations, (3) determine the transaction price, (4) allocate the transaction price, and (5) recognize revenue as performance obligations are satisfied. For B2B SaaS companies, ASC 606 governs how subscription revenue, usage overages, implementation services, and contract modifications are recognized — and where most audit findings originate.
The five-step model, step by step
Each step requires specific upstream data. We'll walk through what the standard says, what it actually needs from your systems, and where teams most often break.
Identify the contract
A signed agreement with enforceable rights and obligations, identifiable payment terms, and commercial substance.
What it needs
The signed contract, all amendments, side letters, and order forms — in one place, with the latest version flagged.
Where it breaks
Sales closes a deal in DocuSign. Finance never gets the final PDF. Amendments live in email threads. The "contract" the rev rec engine sees is the original order form, not the side letter that cut the price 20%.
Identify performance obligations
Each distinct good or service promised to the customer is a separate performance obligation (PO).
What it needs
Line-item parsing of the contract — software access, implementation services, support, training, usage entitlements, professional services — each tagged as distinct or bundled.
Where it breaks
Implementation fees get bundled with subscription on the order form. The contract says "free onboarding" but the SOW priced it at $25K. Without consistent PO tagging, the rev rec engine recognizes the wrong amount on the wrong schedule.
Determine the transaction price
The amount of consideration the company expects to be entitled to in exchange for transferring promised goods or services. Includes variable consideration (discounts, rebates, usage overages, refunds, performance bonuses).
What it needs
Contract base price, tiered pricing rules, discount schedules, usage-based overage triggers, and any contingent payments — all reconciled to what the customer will actually pay.
Where it breaks
Usage-based contracts. A customer is on a $5K/mo platform fee with $0.10/event overages above 100K events. ASC 606 requires you to estimate variable consideration and constrain it. Spreadsheets do this manually. Billing systems track usage but not the estimate.
Allocate the transaction price
Allocate the transaction price to each performance obligation based on standalone selling price (SSP).
What it needs
A documented SSP for every product and service — refreshed regularly — plus the math to allocate bundled deal discounts proportionally.
Where it breaks
Custom enterprise deals bundle a 12-month subscription, 3 months of free professional services, and a 15% multi-year discount. The deal closes for $480K. Finance has to allocate that across 4 performance obligations using SSP — and SSP is rarely documented or kept current.
Recognize revenue
Recognize revenue when (or as) the company satisfies a performance obligation — over time for subscription services, at a point in time for one-time deliverables.
What it needs
Clean billing data tied to performance obligations, accurate timing of delivery or service period, and reconciliation between billed amounts, recognized revenue, and deferred revenue.
Where it breaks
Mid-cycle contract modifications. The customer upgrades on day 47 of a 90-day quarter. The rev rec engine needs to know the modification effective date, the new schedule, and the correction to already-recognized revenue. If billing data and the contract amendment don't tie out, neither does the journal entry.
Where teams actually break ASC 606
Audit findings rarely originate in the rev rec engine. They originate in upstream contract and billing data that nobody noticed was wrong.
Contract modifications
Upgrades, downgrades, mid-term price changes, and amendments are the single biggest source of ASC 606 errors. ASC 606 requires you to decide whether a modification is a separate contract, a continuation, or a termination-and-new-contract — and the answer changes how revenue is recognized.
Usage-based billing
ASC 606 treats usage overages as variable consideration. You're required to estimate it, constrain it to the amount you're reasonably confident in, and update the estimate every period. Most billing systems track usage events but don't produce an auditable variable-consideration estimate.
Multi-year contracts with escalators
A 3-year deal with 7% annual price increases requires the transaction price to be calculated over the full term, not year by year. If your contract data lives in DocuSign and your billing data lives in Stripe, the rev rec engine has to be told the right number twice and they have to match.
Bundled implementation and professional services
Implementation often gets sold as "free with annual contract" but has a real SSP. ASC 606 forces you to allocate transaction price to it anyway. Without documented SSP and disciplined PO tagging, this is where audits find restatements.
Side letters and out-of-band concessions
An account exec promises "we'll throw in three months free" over email. It never makes it into the contract system. The rev rec engine doesn't know. The auditor finds the email a year later. This is a contract-data hygiene problem, not a rev rec engine problem.
How do you recognize revenue on usage-based contracts under ASC 606?
Under ASC 606, usage-based fees are variable consideration. For pure pay-as-you-go billed in arrears, where the invoice corresponds to the value transferred, you can apply the right-to-invoice practical expedient (ASC 606-10-55-18) and recognize the amount you have the right to bill. For minimum commitments, tiered or retroactive pricing, or any case where you recognize ahead of invoicing, you estimate the variable consideration using the expected-value or most-likely-amount method, apply the constraint — including it only to the extent it is probable a significant revenue reversal will not occur — and re-estimate every reporting period.
A common error: the sales- and usage-based royalty exception (ASC 606-10-55-65) applies only to licenses of intellectual property, not to SaaS or services, so most usage-based software does not qualify. For the full mechanics — including prepaid-credit journal entries — see the usage-based revenue recognition guide.
Authoritative guidance: FASB ASC 606 and the converged IFRS 15.
A standalone rev rec engine vs. one reconciled ledger vs. manual reconciliation
The standalone engine recognizes revenue but depends on a separate billing system feeding it — and the two have to be reconciled every close. LedgerUp does both on one ledger.
| Dimension | Standalone rev rec engine | One reconciled ledger (LedgerUp) | Manual reconciliation |
|---|---|---|---|
| What it handles | Allocation math, recognition schedules, journal entry posting — fed by a separate billing system | Usage billing, contract parsing, PO tagging, ASC 606 schedules, and journal entries — all on one ledger | All of the above — by hand, in spreadsheets |
| How billing and rev rec connect | Two systems — billing in one, recognition in another — reconciled every close | One ledger bills and recognizes, so billed and recognized revenue reconcile by construction | Whatever the spreadsheet says this month |
| Where it breaks | Drift between the billing system and the engine — bad contract data produces bad journal entries | Nothing to drift — billing and recognition share one source of truth | Audit findings, restatements, slow close |
| Audit defensibility | High — if the upstream billing data is clean and reconciled | High — one trail from signed contract to billed amount to recognized revenue | Low — spreadsheet drift, version control issues |
| Examples | NetSuite Advanced Revenue Management, RightRev, Leeyo/Sovos, Zone Advanced Billing | LedgerUp (Ari) | Excel + monthly close meetings |
LedgerUp replaces the standalone rev rec engine — and the reconciliation between billing and rev rec — by running both on one ledger, then posting clean journal entries to your GL.
How LedgerUp runs ASC 606 on one ledger
Ari is the revenue subledger — it bills, recognizes, and posts the journal entries, with the contract trail behind every number.
Reads contracts and amendments
Ari ingests signed contracts, side letters, and amendments — extracts performance obligations, pricing tiers, modification terms, and effective dates onto one structured record that drives both billing and recognition.
Tags performance obligations
Each line item is tagged as a distinct or bundled performance obligation. Implementation, support, training, usage entitlements — each routed to the right recognition schedule.
Captures modifications in real time
When a customer upgrades, downgrades, or amends, Ari classifies the modification (separate contract, continuation, or termination-and-new), updates the billing record, and flags the cumulative catch-up for review.
Reconciles usage to billing
For usage-based contracts, Ari ties out usage events, billed overages, and the variable consideration estimate — producing an audit-defensible trail of how the number was calculated.
Recognizes revenue and posts to your GL
Ari builds the ASC 606 schedules, holds deferred revenue, and recognizes on the same ledger it billed from — then posts summarized journal entries to your GL (NetSuite, Sage Intacct, or QuickBooks). It replaces the standalone rev rec subledger; your accounting system stays the book of record.
Frequently asked questions about ASC 606
What is ASC 606?
ASC 606 is the U.S. revenue recognition accounting standard (FASB Accounting Standards Codification Topic 606, "Revenue from Contracts with Customers"). It establishes a single five-step model that all entities use to recognize revenue from customer contracts. Public companies have applied ASC 606 since fiscal years beginning after December 15, 2017; private companies since fiscal years beginning after December 15, 2018.
What are the five steps of ASC 606?
The five steps are: (1) Identify the contract with the customer, (2) Identify the performance obligations in the contract, (3) Determine the transaction price, (4) Allocate the transaction price to the performance obligations, and (5) Recognize revenue when (or as) the entity satisfies a performance obligation. Each step has specific requirements and judgment calls that finance teams have to document and defend during audits.
Does LedgerUp do ASC 606 revenue recognition?
Yes. LedgerUp runs ASC 606 recognition on one reconciled ledger — it builds the schedules, holds deferred revenue, estimates and constrains variable consideration for usage, and posts summarized journal entries to your GL. Because it recognizes on the same ledger it bills from, billed and recognized revenue reconcile by construction. It replaces the standalone rev rec subledger (NetSuite Advanced Revenue Management, RightRev, or a separate tool); your accounting system stays the book of record.
How does ASC 606 apply to usage-based billing?
ASC 606 treats usage overages as variable consideration. You are required to estimate the variable amount, constrain the estimate to the portion you are reasonably confident will not reverse, and update the estimate each reporting period. In practice this means your billing system has to track usage events, your contract system has to define the pricing tiers, and your finance team has to produce a defensible estimate that ties out to both. This is where most usage-based SaaS companies struggle with ASC 606.
How do contract modifications work under ASC 606?
ASC 606 requires you to classify each modification as one of three things: (a) a separate contract — when it adds distinct goods or services at standalone prices, (b) a termination of the existing contract and creation of a new one — when the remaining goods or services are distinct, or (c) a continuation of the existing contract with a cumulative catch-up adjustment — when the remaining goods or services are not distinct. The classification changes the recognition pattern, so getting modifications captured and tagged correctly upstream is essential.
Do I need separate revenue recognition software for ASC 606?
It depends on your contract complexity and billing model. Flat-fee subscription businesses can often handle ASC 606 inside their accounting system's native modules (NetSuite, Sage Intacct, QuickBooks Advanced). Companies with usage-based billing, multi-year contracts, frequent modifications, or bundled implementation services usually need a dedicated rev rec subledger. That is what LedgerUp is — except it runs billing and recognition on one reconciled ledger, so you are not bolting a separate rev rec engine onto a separate billing system and reconciling the two every close.
What is the difference between ASC 605 and ASC 606?
ASC 605 was the prior U.S. revenue recognition standard. It was industry-specific, prescriptive, and largely focused on the timing of delivery. ASC 606 replaced it with a principles-based, five-step model that applies across all industries. The biggest practical changes for B2B SaaS were the explicit handling of variable consideration, the requirement to allocate transaction price using standalone selling price, and the more rigorous treatment of contract modifications.
What is standalone selling price (SSP) and why does it matter for ASC 606?
Standalone selling price is the price at which an entity would sell a promised good or service separately to a customer. ASC 606 requires you to allocate the transaction price across performance obligations based on relative SSP. If you sell a $100K bundle that includes a subscription with $90K SSP and implementation with $30K SSP ($120K total at SSP), you allocate $75K to subscription and $25K to implementation. SSP has to be documented, defensible, and kept current — which is often the weakest link in ASC 606 compliance.
How does ASC 606 treat side letters and verbal concessions?
Under ASC 606, all enforceable contract terms — including side letters, email concessions, and amendments — must be reflected in the transaction price and performance obligations. If your account team gives a customer "three months free" over email and it never reaches your revenue ledger, your recognized revenue is overstated until you fix the data. This is why a clean, complete contract record (including all out-of-band concessions) is the foundation of correct recognition — and why LedgerUp captures concessions on the same ledger it recognizes from.
How does LedgerUp help with ASC 606 audits?
LedgerUp's AI agent Ari reads signed contracts and amendments, tags performance obligations, reconciles billing data to contract terms, captures modifications as they happen, and maintains an auditable trail of every change. When auditors ask "show me the contract, the amendment, the billing record, and how they tie out," that trail is one query away instead of three days of email and spreadsheet archaeology. Because Ari bills and recognizes on one ledger, the contract, the billing record, and the journal entry all live on the same system — so they tie out by construction.