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.
TL;DR
- ASC 606 applies five steps to identify the contract and obligations, determine and allocate the transaction price, and recognize revenue when each obligation is satisfied.
- Compliance depends first on consistent contract, billing, recognition, and reconciliation processes. Software automates those processes and preserves supporting records.
- Top automation options include LedgerUp, RightRev, DualEntry, Zenskar, BillingPlatform, and NetSuite Advanced Revenue Management. Each serves a different billing and accounting environment.
- LedgerUp suits B2B SaaS companies that want usage billing and revenue recognition reconciled on one ledger. RightRev and DualEntry operate as standalone revenue recognition engines connected to separate billing systems.
- Usage-based and hybrid contracts require extra control because consumption, credits, and true-ups can change the transaction price and recognition schedule.
Top ASC 606 / IFRS 15 compliance automation tools
The right ASC 606 or IFRS 15 tool depends on where billing, recognition, and ERP records currently live.
| Tool | Best for | Architecture |
|---|---|---|
| LedgerUp | B2B SaaS companies that need usage billing and revenue recognition reconciled on one ledger | Unified ledger |
| RightRev | Companies that want a dedicated engine for subscription or consumption-based revenue recognition | Standalone engine |
| DualEntry | Finance teams that need ASC 606 recognition connected with NetSuite or Sage Intacct | Standalone engine |
| Zenskar | Companies with subscription, usage-based, or hybrid pricing that want no-code billing and recognition automation | Unified billing and recognition platform |
| BillingPlatform | Enterprises managing complex billing and revenue operations across multiple entities | Unified enterprise platform |
| NetSuite Advanced Revenue Management | Enterprises already using NetSuite ERP that want native ASC 606 and IFRS 15 workflows | ERP-native module |
LedgerUp keeps usage charges and recognition entries on the same ledger, which reduces reconciliation work when metered consumption changes after an initial invoice. RightRev and DualEntry focus on revenue recognition, so companies generally operate them alongside separate billing systems and reconcile records between the two. NetSuite ARM keeps recognition inside NetSuite and fits companies already committed to that ERP, although the module requires dedicated configuration and may sit alongside separate billing software.
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.
What ASC 606 requires and why it exists
ASC 606 defines when and how a company records revenue from customer contracts under US GAAP. The closely related IFRS 15 standard governs international reporting. ASC 606 replaced much of the earlier industry-specific guidance with a shared framework that makes revenue reporting more consistent across business models.
The guidance generally applies to companies that exchange goods or services with customers, although separate rules cover areas such as leases and insurance. For B2B SaaS companies, ASC 606 separates revenue recognition from invoicing. An annual invoice does not automatically justify recognizing the full amount when billed.
Usage-based pricing makes compliance harder because the contract value can change after service begins. Metered consumption, overages, credits, and contract modifications can alter the amount you expect to collect or the period in which you recognize it. Hybrid contracts add another layer by combining recurring fees with variable charges. Finance must connect contract terms with usage records and ledger entries instead of relying on the billing schedule alone.
The five-step ASC 606 model turns those contract terms into a repeatable recognition decision. Each step establishes what evidence finance needs before recording revenue.
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
Identify the contract with the customer and establish enforceable rights. You need evidence of approval, clear payment terms, commercial substance, identifiable rights, and probable collection.
What it needs
The signed contract, all amendments, side letters, and order forms — in one place, with the latest version flagged. You may also need to combine related agreements or assess whether an amendment creates a separate contract.
Where it breaks
The contract assessment breaks when signed order forms, master agreements, side letters, and later amendments contain conflicting terms or live in separate systems. The "contract" the rev rec engine sees is the original order form, not the side letter that cut the price 20%.
Identify performance obligations
A promised good or service qualifies as a distinct performance obligation (PO) when the customer can benefit from it independently and the promise remains separately identifiable within the contract.
What it needs
Line-item parsing of the contract. A SaaS arrangement may include a hosted subscription, implementation work, support, training, usage entitlements, or an option that gives the customer a material right — each tagged as distinct or bundled.
Where it breaks
The performance obligation assessment breaks when a sales bundle uses one commercial description even though its components follow different delivery schedules or recognition patterns. The contract says "free onboarding" but the SOW priced it at $25K.
Determine the transaction price
Start with fixed consideration, then assess variable amounts such as usage charges, service credits, rebates, refunds, and performance bonuses. ASC 606 generally requires either an expected-value estimate or the single most likely amount, followed by a constraint that limits recognition when a significant reversal remains possible.
What it needs
Contract base price, tiered pricing rules, discount schedules, usage-based overage triggers, and any contingent payments. Usage-based SaaS contracts complicate the estimate because metering delays, customer disputes, minimum commitments, and overage tiers can change the amount you expect to collect.
Where it breaks
The transaction price calculation breaks when billing data arrives after the close or finance applies estimates without preserving the assumptions behind them. Spreadsheets do this manually; billing systems track usage but not the estimate.
Allocate the transaction price
Allocate consideration based on each obligation's relative standalone selling price (SSP) at contract inception. Observable standalone prices provide the strongest basis, but you may need an adjusted market assessment, expected cost plus margin, or a residual approach when ASC 606 permits it.
What it needs
A documented SSP for every product and service — refreshed regularly — plus the math to allocate bundled deal discounts proportionally. Certain discounts or variable amounts can belong entirely to one performance obligation when the contract terms and selling-price evidence support that treatment.
Where it breaks
The allocation breaks when you treat list price as standalone selling price, reuse stale estimates, or spread a contract-specific discount across unrelated obligations. SSP is rarely documented or kept current.
Recognize revenue
Recognize revenue when or as control transfers to the customer. Hosted SaaS subscriptions commonly qualify for recognition over time because you provide continuous access or a stand-ready service throughout the contract term.
What it needs
A consistent measure of progress and related balances such as deferred revenue or contract assets. Distinct implementation deliverables may follow a different pattern, while usage charges may track the period in which the customer consumes the service when the contract and allocation analysis support that treatment.
Where it breaks
The recognition schedule breaks when usage records, invoices, contract changes, and general-ledger entries update on different close cycles, leaving finance to reconcile timing differences manually.
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.
Most recurring ASC 606 failures begin when the billing system and general ledger hold different versions of the customer agreement. Billing may track invoice dates, usage, credits, and renewals, while accounting receives summarized journal entries. Finance then uses spreadsheets to connect those records. Each manual handoff can omit a contract amendment, map revenue to the wrong obligation, or apply an outdated recognition schedule.
Contract changes expose the disconnect quickly. A sales representative may approve a ramp deal or renewal change, and the billing administrator may update the invoice schedule. Accounting must separately update the transaction price, allocation, and recognition records. When either update arrives late, the invoice can look correct while the revenue schedule still reflects the original terms.
Usage data creates another source of mismatch. A metering system may finalize consumption after accounting begins the close, or billing may apply a credit after the general ledger records an estimate. Finance can reconcile the monthly total while leaving customer-level differences unresolved. Those differences accumulate across true-ups, overages, and contract changes.
Multi-entity operations add ownership and mapping problems. One entity may issue the invoice while another entity delivers part of the service. If billing and accounting use different customer identifiers or currency treatments, revenue can land in the wrong entity even when the consolidated amount appears reasonable.
Month-end controls often catch arithmetic errors but miss broken data lineage. A journal entry may agree with a spreadsheet total without tying each recognized amount back to the signed contract and billing record. Auditors then have to reconstruct why finance recognized a specific amount in a specific period.
Finance should test whether every contract event reaches both billing and the general ledger through a controlled workflow. Training on the five-step model cannot correct stale terms, incomplete usage data, or disconnected schedules. Reliable compliance requires a traceable path between the commercial event and the accounting entry.
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.
Usage-based variable consideration under ASC 606
How consumption, true-ups, ramp deals, and credits change the transaction price and recognition schedule.
How does consumption affect variable consideration?
Consumption fees make the transaction price in step 3 uncertain until the customer uses the service. You should estimate variable revenue only when a significant reversal is unlikely once the uncertainty resolves. When usage fees relate directly to distinct services delivered during the same period, recognition in step 5 may follow actual consumption instead of a forecast. Your accounting policy should document why actual usage provides an appropriate allocation.
How should you handle usage true-ups?
True-ups adjust billed usage after late meter data, corrected records, or a contractual reconciliation period. You should recognize revenue using the best available usage data, then record a cumulative adjustment when verified consumption arrives. The billing system and revenue ledger must retain the original reading, correction, approval, and accounting entry. Without that trail, finance may recognize the correction in the wrong period or bill it without updating revenue.
How do ramp deals and hybrid contracts change the analysis?
Ramp deals often combine a fixed platform fee with changing commitments or usage rates. Finance must determine whether each increase reflects additional service, a contract modification, or variable consideration under the original contract. A hybrid contract may require separate treatment for the subscription and consumption components when they transfer different services. Minimum commitments also require care because unused capacity may create breakage or a contract liability rather than immediate revenue.
How do credits affect recognized revenue?
Service credits, usage rebates, and volume discounts can reduce the amount finance expects to collect. You should include probable credits in the constrained transaction price instead of waiting for the customer to claim them. For example, a service-level credit tied to monthly uptime may require an estimate before the measurement period closes. Finance should revise that estimate at each reporting date as operational data becomes available.
What operational control reduces errors?
Finance should reconcile meter records, invoices, credits, and revenue entries at the contract level. A usage correction should update billing and recognition through linked records rather than separate spreadsheet adjustments. The reconciliation gives reviewers evidence that recognized revenue reflects delivered service and current estimates.
Standalone rev rec engine vs. one reconciled ledger vs. manual reconciliation
The main difference between ASC 606 tools is where recognition sits relative to billing and the general ledger. Each approach creates a different reconciliation burden.
| Approach | Named tools | How it works | Common failure point | Who it fits |
|---|---|---|---|---|
| Standalone revenue recognition engine | RightRev, DualEntry | The engine imports contracts, invoices, and usage data, then sends recognition entries to the ERP. | Billing changes, credits, and usage adjustments can arrive after recognition schedules run. Finance must detect and reconcile the mismatch across systems. | Companies that already trust their billing data and want a dedicated recognition layer. |
| Reconciled billing and recognition ledger | LedgerUp | LedgerUp records usage billing and ASC 606 recognition against the same operational ledger, while Ari reads contract terms and routes exceptions for review. | Incorrect contract terms or source usage still require correction, but billing and recognition do not need a separate cross-system reconciliation. | B2B SaaS companies with consumption, subscription, or hybrid pricing. |
| Broader billing platform | Zenskar, BillingPlatform | Billing and revenue capabilities sit within a wider order-to-cash or enterprise billing product. | Configuration depth can increase implementation work. Buyers should verify how each product handles contract modifications, ERP posting, and entity-level reporting. | Companies replacing more of their billing stack rather than adding one recognition engine. |
| ERP-native revenue management | NetSuite Advanced Revenue Management | NetSuite ARM creates allocations, schedules, and revenue entries inside NetSuite ERP. | Third-party billing and usage sources still need reliable feeds into NetSuite. Complex configurations may require specialist support. | Companies committed to NetSuite that want recognition governed inside the ERP. |
| Manual reconciliation | Unmanaged spreadsheets | Finance exports billing records, calculates schedules, and posts journal entries manually. | Version conflicts, late adjustments, and weak audit trails increase as contract volume grows. | Low-volume businesses with simple contracts and limited usage billing. |
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.
Go deeper on variable consideration and the constraint, how to keep recognition audit-ready, or how IFRS 15 compares for international reporters.
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.
One shared operational ledger
LedgerUp uses a shared operational ledger for billing activity and revenue recognition, then syncs approved accounting entries to the ERP. Each invoice, usage event, contract change, and recognition entry refers back to the same customer and contract records — finance can trace recognized revenue without reconciling two independent data models first.
Ari starts from the signed contract
Ari begins with the signed contract and connected CRM data. It extracts billing terms and uses them to inform invoice timing, while finance configures the applicable recognition policies and approves exceptions. Contract amendments update the underlying record rather than creating a separate spreadsheet adjustment.
Usage data lands on the same ledger
For usage-based contracts, LedgerUp brings consumption data from systems such as Stripe or Chargebee into the same ledger. The platform can calculate billing and recognition from the same usage record under the approved policy. True-ups, credits, and overages remain connected to the period and contract that produced them.
Close comparison and exception routing
During the close, LedgerUp compares expected billing and recognition activity with recorded transactions. Ari routes mismatches or missing data through Slack for review.
Approved entries post to your ERP
After approval, LedgerUp sends the relevant entries to NetSuite, Sage Intacct, QuickBooks, or Xero. It replaces the standalone rev rec subledger; your accounting system stays the book of record.
RightRev and DualEntry operate as standalone revenue recognition engines beside a separate billing system. Their architecture requires finance to verify that billing inputs, contract updates, and recognition outputs transferred correctly between systems. LedgerUp reduces that interface risk by calculating usage billing and revenue recognition against the same operational ledger. Finance still owns ASC 606 judgments, but the supporting records remain connected throughout the workflow.
Getting started with ASC 606 compliance automation
Trace one representative contract through signed terms, usage records, invoices, journal entries, and close. Record each spreadsheet handoff, manual adjustment, timing mismatch, and unresolved exception. The audit should show whether billing and recognition use the same source data or require manual reconciliation.
Evaluate each tool using your actual billing model. Ask vendors to demonstrate how a usage true-up, contract modification, credit, and journal adjustment flow through the product. Check its audit trail, ERP synchronization, entity support, and exception handling.
If LedgerUp meets those requirements, book a walkthrough using a sample contract and recent billing period. A real scenario will expose reconciliation gaps that a standard product demo may miss.
Closing takeaway
ASC 606 compliance depends on consistent records across contracts, usage data, billing, and the general ledger. A recognition schedule can follow the standard while mismatched source records still create close adjustments and audit exceptions. Choose software based on how well it keeps billing and ledger entries reconciled and makes discrepancies visible, rather than on the length of its feature checklist.
Frequently asked questions about ASC 606
LedgerUp updated this guide in August 2026.
What are the top ASC 606 and IFRS 15 compliance software tools?
The top tools are LedgerUp, RightRev, DualEntry, Zenskar, BillingPlatform, and NetSuite Advanced Revenue Management. LedgerUp reconciles usage billing and recognition on one ledger, while RightRev and DualEntry operate as dedicated revenue recognition engines alongside separate billing systems. Zenskar combines flexible billing with recognition, while enterprise buyers can compare BillingPlatform's multi-entity scope with NetSuite ARM's ERP-native model.
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 ASC 606 apply to SaaS companies?
ASC 606 applies to SaaS companies that enter contracts with customers, including subscription, usage-based, and hybrid arrangements. LedgerUp connects SaaS contract terms with usage billing and revenue recognition records. Finance teams can trace recurring fees, overages, credits, and contract changes without rebuilding schedules in spreadsheets.
How do ASC 606 and IFRS 15 differ?
ASC 606 governs revenue recognition under US GAAP, while IFRS 15 governs recognition under international reporting standards. LedgerUp supports revenue workflows that use the shared five-step framework behind both standards. Companies reporting across jurisdictions can maintain consistent contract and transaction records while applying the required accounting policies.
Can ASC 606 compliance be automated?
Compliance software can automate revenue schedules, allocations, journal entries, reconciliations, and audit records. LedgerUp adds contract interpretation and usage billing reconciliation to that accounting workflow. Automation reduces repetitive calculations while preserving review points for judgments such as performance obligations and variable consideration.
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.