ASC 606 Revenue Recognition: The Operator's Guide
ASC 606 doesn't fail because your rev rec engine is bad. It fails because your contracts, modifications, and billing data don't tie out — and the engine has nothing clean to recognize. Here's the five-step model, where teams actually break it, and how to fix the upstream.
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.
Rev rec software vs. billing data quality vs. manual reconciliation
These three are often confused. They solve different problems and most B2B SaaS finance teams need at least two of them.
| Dimension | Rev rec engine | Billing data quality (LedgerUp) | Manual reconciliation |
|---|---|---|---|
| What it handles | Allocation math, recognition schedule, journal entry posting | Contract parsing, PO tagging, usage reconciliation, modification capture | All of the above — by hand, in spreadsheets |
| What it requires upstream | Clean contracts, accurate billing data, documented SSP, modification log | The contract itself, the billing system, and the CRM | A finance team willing to maintain it |
| Where it breaks | Garbage in, garbage out — bad contract data produces bad journal entries | Doesn't replace the rev rec engine; feeds it | Audit findings, restatements, slow close |
| Audit defensibility | High — if upstream data is clean | High — provides the audit trail for contract terms and modifications | Low — spreadsheet drift, version control issues |
| Examples | NetSuite Advanced Revenue Management, RightRev, Leeyo/Sovos, Zone Advanced Billing | LedgerUp (Ari) | Excel + monthly close meetings |
LedgerUp doesn't replace your rev rec engine. It makes sure the engine has clean contract and billing data to work with.
How LedgerUp fits in your ASC 606 stack
Ari operates upstream of your rev rec engine. It doesn't post journal entries — it makes sure the data going into them is correct.
Reads contracts and amendments
Ari ingests signed contracts, side letters, and amendments — extracts performance obligations, pricing tiers, modification terms, and effective dates. The data your rev rec engine needs, in the structure it expects.
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.
Hands clean data to your rev rec layer
NetSuite Advanced Revenue Management, RightRev, Sage Intacct, Zone Advanced Billing — Ari feeds whichever rev rec engine you already use. We don't replace it; we make it work.
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?
LedgerUp does not replace your revenue recognition engine. Most B2B SaaS companies already use NetSuite Advanced Revenue Management, RightRev, Sage Intacct, or similar tools to post recognition journal entries. What LedgerUp does is fix the upstream data those engines depend on — extracting performance obligations from signed contracts, capturing modifications, reconciling usage to billing, and tying out the audit trail. ASC 606 fails when the contract-to-billing data is dirty, not when the rev rec engine is bad.
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 engine. Either way, the rev rec engine is only as good as the upstream contract and billing data it receives — which is where LedgerUp fits.
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 the rev rec engine never sees it, your recognized revenue is overstated until you fix the data. This is why a clean, complete contract record (including all out-of-band concessions) matters more than the rev rec engine itself.
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. Ari operates upstream of your rev rec engine — it doesn't post journal entries, but it makes sure the data going into them is correct.