Revenue recognition under ASC 606 sounds intimidating until you reduce it to one core principle: revenue follows performance, not cash.
That single sentence explains why a software company can receive $120,000 on January 1 and still recognize zero revenue that day. The money is in the bank. The payment cleared. But if the company has not yet delivered what it promised, it has not earned revenue under ASC 606.
That is the heart of ASC 606 revenue recognition. The standard is trying to answer two questions consistently across industries and revenue streams:
- How much revenue should be recognized?
- When should it be recognized?
To do that, ASC 606 uses a five-step model. Once that framework clicks, the standard becomes much easier to work through, even when customer contracts get messy.
Why ASC 606 Exists
Before ASC 606, revenue recognition was spread across a patchwork of industry-specific guidance. Two companies could enter into economically similar arrangements and still account for revenue in very different ways.
ASC 606, issued by the Financial Accounting Standards Board (FASB) in 2014 and effective for most public companies for annual reporting periods beginning after December 15, 2017, replaced ASC 605 with a single comprehensive framework. The standard lives in the Accounting Standards Codification as Topic 606.
The goal was consistency. Not necessarily simplicity.
That distinction matters. ASC 606 is conceptually cleaner than the old model, but it still requires significant judgment. A lot of it. Terms like distinct, control, performance obligation, and transaction price are doing a lot of work. If those terms feel abstract, the fastest way to make them real is to walk through them using a simple example.
ASC 606 and IFRS 15: The International Counterpart
ASC 606 does not exist in isolation. It has an international counterpart: IFRS 15, Revenue from Contracts with Customers.
ASC 606 and IFRS 15 both provide a comprehensive framework for recognizing revenue from customer contracts, emphasizing the identification of performance obligations and the transfer of control of goods or services to the customer.
The FASB and the International Accounting Standards Board (IASB) issued the two revenue recognition standards jointly in 2014, with the explicit goal of bringing U.S. generally accepted accounting principles (GAAP) and IFRS into alignment on revenue. The core principle and five step model are the same under both:
- The same five-step model
- The same definition of a performance obligation
- The same focus on transfer of control
Both ASC 606 and IFRS 15 became effective for public companies in 2018. ASC 606 is primarily followed in the United States, while IFRS 15 has been adopted in more than 140 jurisdictions globally.
A company reporting under U.S. GAAP applies ASC 606. A company reporting under IFRS applies IFRS 15. In most situations, the answer is the same under both.
Where ASC 606 and IFRS 15 Differ
While both standards follow the same five-step revenue recognition model, a few narrow differences remain. They show up in areas like:
- Collectibility assessment at contract inception, where the two standards apply slightly different thresholds and procedural steps
- Licensing arrangements, particularly the distinction between licenses that provide a right to use intellectual property versus a right to access intellectual property
- Nonrefundable upfront fees and how they are allocated across performance obligations
- Disclosure requirements, where the volume and granularity expected can differ between U.S. and IFRS filers
For most companies, especially in SaaS, services, and product sales, these differences rarely change the bottom-line revenue number. The practical reality is that ASC 606 and IFRS 15 produce the same answer on revenue recognition in most fact patterns. That is by design.
The Scope of ASC 606 Revenue Recognition
ASC 606 revenue recognition applies broadly to customer contracts across most industries. But not every arrangement belongs here.
Some transactions are carved out because they are covered by other accounting standards. A few common examples:
- Leases fall under ASC 842
- Insurance contracts fall under ASC 944
- Financial instruments are covered elsewhere, such as ASC 320
So one of the first questions in practice is simple: Does this arrangement even fall within the scope of ASC 606?
If it is not explicitly excluded, the answer is usually yes.
The Core Principle That Holds the Entire Standard Together
If you only remember one sentence about ASC 606 revenue recognition, make it this one:
Revenue is recognized when control transfers to the customer.
In plain English, that means revenue is recognized when the customer actually obtains control of the promised goods or services — when they receive the benefit of what was promised.
Not when they pay.
Not when the invoice goes out.
Not when cash hits the bank.
When the value is delivered.
That is why prepaid contracts often create deferred revenue instead of immediate income. And that is why revenue recognition timing under ASC 606 can look completely different from cash flows.
A Simple SaaS Example to Make ASC 606 Concrete
Assume Big Tech signs a one-year SaaS agreement with Sandbox for $120,000. Sandbox pays the full amount upfront on January 1.
That sounds straightforward, but it turns into a perfect illustration of how ASC 606 revenue recognition works. We will use that same fact pattern through all five steps.
Step 1: Identify the Contract With the Customer
The first step in implementing ASC 606 is to identify the contract with a customer, which involves determining whether an agreement exists that creates enforceable rights and obligations between the parties involved.
That sounds obvious, but the standard does not treat every handshake, proposal, or unsigned understanding as a contract for revenue recognition purposes.
ASC 606 defines a contract as an agreement between two or more parties that creates enforceable rights and obligations. At contract inception, the standard requires that:
- The parties have approved the agreement
- Each party’s rights can be identified
- The payment terms can be identified
- The contract has commercial substance
- Collection is probable
In plain English, ASC 606 is asking:
- Is this a real, enforceable business arrangement?
- Do we actually expect to get paid?
That last point matters more than people often realize. If collectibility is in serious doubt, the entity may not yet have a contract under ASC 606, even if something was signed.
In the Big Tech example, this step is clean. Both parties approved the agreement. The payment terms are clear. And Sandbox already paid upfront, so collectibility is not really in question.
Conclusion for Step 1: There is a contract.
Step 2: Identifying Performance Obligations
The second step is to identify the performance obligations within the contract, which are promises to transfer goods or services to the customer and can be either explicit or implied.
This is where the judgment starts to ramp up.
Under ASC 606, a performance obligation is the entity’s promise to transfer goods or services that are distinct to the customer. Those promises can be explicit — clearly written into the contract — or implied through customary business practices, published policies, or specific statements made during negotiations.
That word, distinct, is one of the most important words in the standard.
A promised good or service must meet two tests to stand as its own performance obligation:
- Capable of being distinct
- Distinct within the context of the contract
What “distinct” means in plain English:
Capable of being distinct means the customer can benefit from the good or service on its own, either alone or together with other readily available resources.
Distinct within the context of the contract means the promise is separately identifiable from the other promises in the deal.
If a promised item fails either test, it does not stand on its own as a separate performance obligation. Instead, it gets bundled together with other promises.
This is a big deal in real contracts.
A SaaS arrangement might include several promised goods or services:
- Implementation services
- Ongoing platform access
- Training
- Future technical support hours
Depending on the facts, those may be distinct performance obligations. If they are, the entity may need to allocate revenue across them and recognize that revenue at different times.
In the Big Tech example, the customer is simply buying access to the software platform for 12 months. There is no separate implementation project, no custom development, and no distinct training package.
Conclusion for Step 2: Big Tech has a single performance obligation — to provide access to the software over the one-year subscription period.
Step 3: Determine the Transaction Price
The third step is to determine the transaction price, which is the amount of consideration the entity expects to be entitled to in exchange for transferring promised goods or services to the customer.
In plain English: How much does the company realistically expect to earn from this contract?
Sometimes that is simple. Sometimes it is not.
Real-world contracts can include all kinds of complications that require significant judgment:
- Variable consideration (bonuses, performance penalties, usage-based pricing)
- Significant financing component (when payment timing creates a financing element)
- Noncash consideration (equity, goods in trade)
- Consideration payable to the customer (rebates, credits)
- Discounts and refunds
- Sales taxes collected on behalf of third parties (generally excluded)
When those features exist, companies may need to estimate amounts before all uncertainty is resolved.
But Big Tech’s contract is refreshingly clean. The contract price is a fixed $120,000. No bonus. No rebate. No usage charges. No financing element.
Conclusion for Step 3: The transaction price is $120,000.
Step 4: Allocate the Transaction Price to the Performance Obligations
The fourth step involves allocating the transaction price to the identified performance obligations based on their relative standalone selling prices, which may require estimation techniques if the prices are not directly observable.
In plain English: How much of the total contract price belongs to each separate promise?
Standalone Selling Price: The Allocation Anchor
The standalone selling price is the price the entity would charge for that specific good or service if it were sold to customers individually. When a company sells a bundle, ASC 606 wants the total contract price split across the performance obligations in proportion to what each piece would sell for on its own.
When a standalone selling price is not directly observable, the entity has to estimate it — using an adjusted market assessment, expected cost plus a margin, or in some cases a residual approach. Fair value concepts often inform that estimate.
This matters because different obligations may be satisfied at different times. If so, their related revenue will also be recognized at different times.
Take a bundled arrangement that includes:
- A software license
- A one-time implementation project
- Two years of premium support
That deal could contain three separate performance obligations. Step 4 is where the entity decides how much of the total contract price belongs to each one, using the standalone selling price of each piece as the anchor.
In the Big Tech example, this step is almost a non-event because there is only one performance obligation.
Conclusion for Step 4: The entire $120,000 is allocated to the single performance obligation — providing software access over one year.
Step 5: Recognize Revenue When or As the Performance Obligation Is Satisfied
The fifth step is to recognize revenue when or as the entity satisfies a performance obligation by transferring control of the promised goods or services to the customer.
This is the step most people really care about because it determines timing.
ASC 606 says revenue is recognized when or as the entity satisfies a performance obligation, meaning when the customer obtains control of the promised goods or services.
In plain English: When did the customer actually receive the value?
There are two broad possibilities:
- Point in time
- Over time
Point-in-time recognition applies when control transfers all at once and the customer reaches complete satisfaction of the performance obligation in a single moment.
Think about selling a product, delivering equipment, or transferring inventory. The customer gets substantially all of the remaining benefits in a single moment, so revenue is recognized at that point.
Over-time recognition applies when arrangements transfer value continuously. SaaS contracts are a classic example.
When revenue is recognized over time, the entity has to measure progress toward complete satisfaction. The two common approaches are:
- Input methods — measuring progress based on costs incurred or labor hours expended
- Output methods — measuring progress based on units delivered, milestones reached, or time elapsed
With Big Tech, the customer does not obtain control of the full benefit on January 1. Big Tech is standing ready and providing access every day across the subscription period. That means the performance obligation is satisfied over time, and a time-elapsed output method works naturally.
So the $120,000 is recognized gradually over the 12-month contract term:
$120,000 ÷ 12 months = $10,000 per month
Conclusion for Step 5: Big Tech recognizes revenue monthly over the life of the subscription, not all at once when cash is received.
Why Revenue Does Not Equal Cash Under ASC 606
This is where people often get turned around.
Sandbox paid the full $120,000 upfront on January 1. But Big Tech recognized zero revenue that day.
Why?
Because under ASC 606 revenue recognition, payment timing and revenue timing are separate questions. Cash does not drive recognition. Performance does.
Big Tech earns revenue month by month as it provides access to the platform. That is when the value is delivered, so that is when the revenue is recognized — and that is what shows up in the financial statements as a revenue stream.
This is the original question that tends to trip people up:
- Cash received on January 1: $120,000
- Revenue recognized on January 1: $0
That is not an accounting trick. That is the logic of ASC 606 working exactly as intended.
So Where Does the Cash Go If It Is Not Revenue Yet?
If the company has cash but has not yet earned revenue, the amount does not just disappear into the accounting void. It shows up on the balance sheet as a contract balance.
When cash and performance happen at different times, the difference usually lands in one of two places:
- Deferred revenue
- Accrued revenue or a contract asset
Deferred Revenue (Contract Liability)
Deferred revenue happens when the company gets paid before it performs.
The company has the cash, but it still owes the customer goods or services. That makes deferred revenue a liability. Under ASC 606, it is a contract liability.
That is exactly what happens in the Big Tech example on January 1.
Debit Cash...................... 120,000
Credit Deferred Revenue.......... 120,000
Over time, as Big Tech provides access to the software, deferred revenue is reduced and revenue is recognized.
Accrued Revenue or Contract Asset
Accrued revenue is the opposite situation. It happens when the entity performs before it has billed or collected cash.
Instead of a liability, the company records an asset. ASC 606 refers to this as a contract asset. In practice, many companies also call it unbilled revenue or accrued revenue. Both are contract balances under ASC 606.
If Big Tech had already provided one month of software access before it was entitled to bill the customer, the entry would look like this:
Debit Contract Asset (or Accrued Revenue)
Credit Revenue
Same standard. Same economics. Different balance sheet outcome depending on whether cash comes before or after performance.
Not All Software Revenue Is Recognized Over Time
This is another important point that is easy to miss.
People often assume software automatically means over-time revenue recognition. But ASC 606 revenue recognition is not focused on labels like “software.” It is focused on how control transfers.
- A one-time perpetual software license that gives the customer control outright may transfer at a single point in time.
- An ongoing SaaS subscription transfers value over time.
Same broad category. Completely different recognition outcome.
That is the discipline ASC 606 requires: look past the label and trace the transfer of control to the customer.
The Full 5-Step ASC 606 Revenue Recognition Model at a Glance
- Identify the contract with the customer
- Identify the performance obligations in the contract
- Determine the transaction price
- Allocate the transaction price to the performance obligations
- Recognize revenue when or as performance obligations are satisfied
Behind all five steps are the same recurring questions:
- What was promised?
- How much should be recognized?
- When was the promise actually satisfied?
Final Thoughts on ASC 606 Revenue Recognition
ASC 606 revenue recognition replaced a fragmented system of old guidance with one comprehensive framework that works across industries — and through IFRS 15, it brought U.S. GAAP and international financial reporting into alignment on this topic. That does not eliminate significant judgment from the process, but it does create a common logic.
And that logic becomes much more manageable when you stop treating the standard like a pile of terminology and start treating it like a sequence of questions.
First, confirm there is a contract.
Then identify what was actually promised.
Figure out the transaction price the entity expects.
Assign that amount to the promises based on relative standalone selling prices.
Then recognize revenue when control transfers.
If that framework is clear, the harder topics become easier to handle later — including variable consideration, contract modifications, contract costs, and the disclosure requirements that come with all of it.
And if you are still holding onto the opening question, here is the clean answer one more time:
Big Tech received $120,000 on January 1.
Revenue on January 1: zero.
Why: because revenue follows performance, not cash.
ASC 606 Disclosure Requirements
ASC 606 does not stop at the income statement. The standard also requires companies to disclose both quantitative and qualitative information about their revenue recognition practices, which can complicate compliance efforts due to the need for detailed reporting.
The disclosure framework is designed to give financial statement users enough information to understand the nature, amount, timing, and uncertainty of revenue and cash flows arising from customer contracts.
In practice, ASC 606 disclosures generally cover:
- Disaggregation of revenue — breaking total revenue down by category (product line, geography, customer type, contract duration, timing of recognition)
- Contract balances — opening and closing balances for receivables, contract assets, and contract liabilities, with explanations of significant changes
- Performance obligations — a description of when the entity typically satisfies its performance obligations and the significant payment terms
- Significant judgments — the methods, inputs, and assumptions used to determine the transaction price, allocate it, and identify when performance obligations are satisfied
- Remaining performance obligations — the aggregate amount of the transaction price allocated to performance obligations that are unsatisfied at the reporting date
For private companies, some of these requirements are scaled back. But for public filers, the disclosure burden is substantial — and it is often the area where ASC 606 implementation runs into real friction.
Common ASC 606 Implementation Challenges
Implementing ASC 606 can pose several challenges for organizations, including understanding the new revenue recognition rules, data collection and analysis, and system and process changes.
Even years after the effective date, many companies still wrestle with the operational side of the standard. The framework is principles-based, which gives it flexibility — but flexibility creates judgment calls, and judgment calls require documentation, controls, and consistent application.
A few of the most common implementation challenges:
Identifying performance obligations. This step is harder than it looks. Identifying performance obligations can be difficult under ASC 606, as it requires determining when a promise to transfer goods or services stands alone as its own performance obligation within a larger contract. Bundled deals, implied promises, and customer options for additional goods or services all complicate the analysis.
Estimating variable consideration. Bonuses, penalties, rebates, refunds, and usage-based pricing all require estimation before uncertainty is resolved. The standard requires significant judgment in choosing between the expected value method and the most likely amount method, and in applying the constraint that limits how much variable consideration can be recognized.
Data collection and system changes. The transition to ASC 606 may require significant changes to existing systems and processes, which can be disruptive if not managed properly, leading to compliance challenges. Many companies discover that their ERP, billing, and contract management systems were not built to track performance obligations, standalone selling prices, or contract modifications at the level ASC 606 demands.
Allocating the transaction price. When standalone selling prices are not directly observable, companies have to estimate them and document the methodology. That estimation needs to be defensible, repeatable, and applied consistently across similar contracts.
Disclosure preparation. The disaggregation and remaining performance obligation disclosures often require pulling data from systems that were never designed to produce it. For many companies, the disclosure workstream is where ASC 606 implementation gets most expensive.
Ongoing contract modifications. Real contracts change. ASC 606 has specific guidance for how to account for modifications, and applying that guidance consistently across hundreds or thousands of customer contracts requires process discipline most organizations had to build from scratch.
None of these challenges are reasons to be discouraged. They are the reality of moving from a rules-based to a principles-based standard. Companies that invested in process and system changes early generally find the ongoing application of ASC 606 manageable. The companies that did not are still catching up.
Frequently Asked Questions
What are the 5 steps of ASC 606 revenue recognition?
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 based on relative standalone selling prices, and (5) recognize revenue when or as each performance obligation is satisfied. The framework is built around one question: when does control of the promised goods or services transfer to the customer?
When did ASC 606 become effective?
ASC 606 became effective for public companies for annual reporting periods beginning after December 15, 2017, which meant fiscal year 2018 for most calendar-year companies. Private companies followed one year later. The standard was originally issued by the Financial Accounting Standards Board (FASB) in May 2014 as ASU 2014-09.
What is the difference between ASC 606 and IFRS 15?
ASC 606 and IFRS 15 are substantively converged revenue recognition standards that the FASB and IASB issued jointly in 2014. The five-step model is identical, as are the core concepts of performance obligation and transfer of control. The differences are narrow and relate mainly to collectibility assessment at contract inception, certain licensing arrangements, and some disclosure requirements. For most companies, ASC 606 and IFRS 15 produce the same accounting answer.
What standard did ASC 606 replace?
ASC 606 replaced ASC 605, Revenue Recognition, along with most of the industry-specific guidance in U.S. GAAP. The old framework had grown into a patchwork of rules that produced inconsistent results for economically similar transactions. ASC 606 consolidated that guidance into a single principles-based standard within the Accounting Standards Codification that applies across nearly all customer contracts.
How is SaaS revenue recognized under ASC 606?
SaaS revenue is generally recognized over time under ASC 606 because the customer receives and consumes the benefits of the service as the entity performs. The total transaction price is typically recognized ratably over the subscription term using a time-elapsed output method. Cash collected upfront is recorded as deferred revenue (a contract liability) and converted to revenue as the service is delivered.
Is deferred revenue the same as a contract liability under ASC 606?
Yes. Under ASC 606, what accountants traditionally called deferred revenue is technically a contract liability — an obligation to transfer goods or services to a customer for which the entity has already received consideration. The terms are used interchangeably in practice, though “contract liability” is the technically correct ASC 606 terminology and is preferred in financial statement presentation.
