ASC 605 vs ASC 606: Shift in Revenue Recognition Standards

Revenue recognition is not a passive compliance obligation. How and when a company records revenue determines what its financial statements say about profitability, what investors and lenders see when they evaluate the business, and what triggers covenant tests, earnout calculations, and investor reporting milestones. Getting the difference between ASC 605 vs ASC 606 right is not just an accounting matter — it is a strategic one. The transition from ASC 605 to ASC 606 represented the most significant overhaul of revenue recognition standards in U.S. GAAP in decades. Issued jointly by FASB and the International Accounting Standards Board in 2014, with mandatory compliance for public companies beginning in fiscal years after December 15, 2017, and for private companies after December 15, 2018, ASC 606 replaced not just ASC 605 but more than 100 pieces of industry-specific revenue guidance that had accumulated over the preceding decades.

Understanding the difference between the two standards — and more importantly, understanding where ASC 606 changes outcomes, not just procedures — is essential for any finance leader responsible for the integrity of financial reporting.

ASC 605: What the Old Standard Was and Why It Failed

ASC 605, Revenue Recognition, was not a single coherent standard. It was a collection of industry-specific guidance documents, interpretive releases, and sector-specific rules that had evolved over decades in response to specific transactions and industries. Software companies operated under ASC 985-605. Real estate recognition followed its own set of rules. Construction contractors applied percentage-of-completion or completed-contract methods under separate guidance. Long-term service contracts had their own interpretations.

The result was a fragmented system in which two companies offering economically similar arrangements — say, a software license bundled with implementation services and ongoing support — could recognize revenue on materially different schedules depending on how their contracts were structured and which industry-specific rules applied. This made peer comparisons unreliable and created significant opportunities to structure transactions to achieve a desired accounting outcome rather than an economically justified one.

The core recognition criteria under ASC 605 were conceptually straightforward: revenue was recognized when it was realized or realizable and earned. In practice, this was operationalized by transferring risks and rewards to the customer — the point at which the seller had substantially completed its obligation and collection was reasonably assured. For simple, point-in-time transactions, this worked reasonably well. For multi-element arrangements, subscription models, and contracts with variable consideration, it produced inconsistencies and, in many cases, front-loaded revenue that did not reflect the economic reality of the arrangement.

ASC 606: The Shift from Rules to Principles — and Why It Matters

ASC 606 replaced the fragmented rules-based system with a single, principles-based model applicable to all industries and all contract types. The core principle is deceptively simple: recognize revenue to depict the transfer of promised goods or services to customers in an amount that reflects the consideration to which the entity expects to be entitled in exchange for those goods or services.

The critical conceptual shift is from risks-and-rewards to control. Under ASC 605, the question was whether risks and rewards had substantially transferred to the customer. Under ASC 606, the question is whether the customer has obtained control of the good or service — the ability to direct its use and obtain all of the remaining economic benefits from it substantially. This is not merely a semantic distinction. In practice, it changes the recognition point for a meaningful category of transactions, particularly in technology, software, and professional services.

The second major shift is toward a contract-level analysis of performance obligations. Rather than evaluating each revenue transaction in isolation under industry-specific rules, ASC 606 requires finance teams to identify every distinct promise in every customer contract, establish a standalone selling price for each, allocate the total transaction price proportionally across those obligations, and recognize revenue as each obligation is satisfied — at a point in time or over time.

This contract-level discipline is more rigorous than what most organizations were doing under ASC 605. It is also more informative — when done correctly, it produces revenue recognition that genuinely reflects when and how customer value is delivered.

ASC 605 vs ASC 606: Side-by-Side Comparison

The ASC 606 Five-Step Model: Where Theory Becomes Judgment

The practical application of ASC 606 is structured around a five-step model that applies to every revenue-generating contract. Each step requires judgment, and each step is where common errors, audit findings, and restatements originate.

Step 1: Identify the Contract with the Customer

A contract exists under ASC 606 when five criteria are met: both parties have approved and committed to the agreement; each party’s rights regarding the goods or services can be identified; payment terms are identified; the contract has commercial substance; and collection of substantially all consideration is probable. The collectibility criterion is not a mere formality — for businesses with significant bad-debt exposure, it determines whether a contract qualifies for revenue recognition. Contracts that do not meet all five criteria are not within the scope of ASC 606 until they do.

Step 2: Identify the Performance Obligations

A performance obligation is a promise to transfer a distinct good or service to the customer. A good or service is distinct if the customer can benefit from it on its own or with other readily available resources, and if the promise is separately identifiable from other promises in the contract. This step is where the most significant structural differences from ASC 605 emerge. Under the old standard, a SaaS company might have recognized a bundled arrangement — subscription access, implementation services, and premium support — as a single deliverable at a single point in time. Under ASC 606, each element must be evaluated for distinctness. Implementation that can stand alone is a separate obligation. Support that delivers ongoing value is recognized over the service period. Getting the boundary wrong here misstates the revenue waterfall for the entire contract.

Step 3: Determine the Transaction Price

The transaction price is the amount the entity expects to be entitled to in exchange for transferring the promised goods or services. This step becomes complex when the considerations are variable — discounts, rebates, bonuses, usage-based fees, rights of return, or performance incentives. ASC 606 requires these to be estimated using either the expected value method or the most likely amount method, with a constraint: variable consideration can be included only to the extent that it is probable that a significant reversal of cumulative recognized revenue will not occur when the uncertainty resolves. This constraint prevents the aggressive front-loading of revenue that was one of the pathologies of ASC 605 practice. Sales commissions and other incremental contract acquisition costs are also affected hereunder ASC 606; these are capitalized as contract assets and amortized over the expected benefit period, rather than expensed immediately as was common under ASC 605.

Step 4: Allocate the Transaction Price to Performance Obligations

Once the transaction price and performance obligations are established, the total consideration is allocated to each obligation in proportion to its relative standalone selling price—the price at which the entity would sell that good or service separately. This allocation requirement is one of the most consequential changes for companies with bundled offerings. Under ASC 605, a common approach was the residual method allocation, which could result in one element receiving a disproportionate share of revenue. Under ASC 606, allocation must be based on observable or estimated standalone prices, applied consistently. For SaaS companies with tiered pricing, bundled features, and negotiated enterprise discounts, this requires robust SSP documentation and regular calibration.

Step 5: Recognize Revenue When or As Performance Obligations Are Satisfied

Revenue is recognized when control transfers to the customer — either at a point in time or over time. Recognition over time is appropriate when the customer simultaneously receives and consumes the benefits (ongoing services), the entity’s performance creates or enhances an asset the customer controls (construction or customization), or the entity’s performance does not create an asset with alternative use and the entity has a right to payment for performance to date. Recognition at a point in time applies when none of these criteria are met. The distinction between point-in-time and over-time recognition is not merely a classification decision — it determines the shape of the revenue curve across reporting periods.

ASC 605 vs ASC 606: Where Finance Teams Get ASC 606 Wrong and What It Costs

Misidentifying Performance Obligations in Bundled Arrangements

The most common material error in ASC 605 vs ASC 606 implementation is treating a bundle of goods and services as a single performance obligation when the components are individually distinct. A SaaS company that sells platform access, onboarding, and technical support under a single contract has at least two, and often three, separate obligations. Treating the contract as a single deliverable recognized at contract commencement front-loads revenue and understates deferred revenue on the balance sheet — a presentation that will attract scrutiny from auditors and investors alike.

Inconsistent Standalone Selling Price Documentation

ASC 606 requires that SSPs be established and applied consistently. Many companies establish SSP methodologies at implementation and do not update them as pricing evolves. When discounts, bundled pricing, or market conditions shift, stale SSP assumptions produce allocation errors that compound across large contract portfolios. Deloitte has identified spreadsheet-based SSP management as one of the highest-risk areas in ASC 606 compliance — and it remains common even among companies that have been under the standard for several years.

Underestimating the Impact on Commission Accounting

The treatment of sales commissions under ASC 606 catches many organizations unprepared, even years after adoption. Incremental costs to obtain a contract — commissions paid to sales personnel on executed deals — must be capitalized and amortized over the expected period of benefit if that period exceeds one year. For companies with large sales teams and multi-year contracts, this creates a meaningful contract asset on the balance sheet and changes the timing of expense recognition relative to revenue. The practical expedient — which permits immediate expensing when the amortization period would be one year or less — applies narrowly and should not be applied by default to all commission arrangements.

Variable Consideration Constraint Misapplication

The constraint on variable consideration requires genuine judgment: include variable amounts in the transaction price only to the extent it is probable that a significant cumulative revenue reversal will not occur. In practice, many finance teams either apply this constraint too conservatively — excluding variable consideration that is highly likely to be realized — or too aggressively, including optimistic usage estimates that subsequently require reversal. Both directions produce financial statements that do not fairly present the company’s revenue position, and both create audit risk.

Why the Difference Between ASC 605 vs ASC 606 Matters and What Finance Leaders Should Be Reviewing Now

ASC 606 is no longer new. But the assumption that compliance was a one-time transition project is where most ongoing risk originates. Revenue recognition under ASC 606 requires continuous reassessment as contracts evolve, pricing models change, and new service lines are introduced. A SaaS company that moves from per-seat to consumption-based pricing must change its performance obligation structure and reassess its recognition methodology. A professional services firm that adds a managed services component to an existing implementation contract may have created a new performance obligation mid-arrangement.

For CFOs and controllers, the practical mandate is three-fold: ensure that contract review processes are embedded in the revenue recognition workflow, not performed retrospectively at quarter-end; ensure that SSP documentation is actively maintained and tested for consistency; and ensure that the judgment calls embedded in each of the five steps — variable consideration estimates, performance obligation identification, over-time vs. point-in-time determinations — are supported by documented analysis that would withstand audit scrutiny.

For fractional CFOs and CPA firms advising growth-stage companies, the more pressing question is often not whether ASC 606 was adopted, but whether it was adopted rigorously. A company that adopted the standard but treated every multi-element contract as a single obligation, or that capitalized commissions only on certain contract types, may have a material misstatement embedded in its historical financials — one that will surface in due diligence, at audit, or in the first serious lender review.

Revenue recognition under ASC 606 is not a compliance footnote. It is the foundation of every revenue figure in the financial statements. Understanding where the standard departs from its predecessor — and where the judgment calls live — is not optional knowledge for anyone responsible for the integrity of those statements.