The revenue recognition method that fit your business a year ago can break the moment you add usage, credits, or AI-agent pricing. Revenue recognition is the accounting process of recording revenue when your company earns it, by satisfying a promise to a customer, rather than when the cash lands in the bank. Modern pricing turns one clean subscription line into thousands of consumption-based performance obligations, and the approaches built for flat subscriptions quietly misstate revenue when they cannot keep up.

We believe modern pricing, across usage, hybrid, and AI-agent models, breaks the classic five-method model. Finance and engineering teams now need revenue recognition that works across contracts and consumption in one place. Today 51% of recurring-revenue companies combine subscription with usage-based pricing, and 75% keep a subscription element, so the model your recognition policy was written for has already changed. That shift is why Chargebee RevRec recognizes revenue across contracts and usage models, ready for Accounting Standards Codification (ASC) Topic 606 and International Financial Reporting Standard (IFRS) 15.

What is revenue recognition, and why does it matter?

The revenue recognition principle in one sentence

Revenue recognition records revenue in the period a company earns it, by transferring a promised good or service to a customer. Under U.S. Generally Accepted Accounting Principles (GAAP), the core principle of ASC 606 is that a company “recognizes 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”. The revenue recognition principle ties the timing of revenue to performance, not to payment.

Revenue recognition vs. cash collection

Recognized revenue and collected cash are two separate measures. Accrual accounting, which GAAP and IFRS require, records the financial effects of transactions “in the periods in which those transactions, events, and circumstances occur rather than only in the periods in which cash is received or paid”. When a customer prepays for an annual plan, that cash becomes a contract liability, and the company recognizes revenue only as it satisfies each performance obligation. Getting that timing wrong creates audit and reporting risk, because the income statement stops reflecting the work delivered.

What are the main revenue recognition methods?

Several recognition methods were in common use before ASC 606, each designed for a particular kind of transaction. ASC 606 now governs the timing of recognition through a single control-transfer model, so treat the list below as a practical map of methods rather than a named standard.

Sales-basis (point-in-time) method

The sales-basis method recognizes all revenue at the point of sale, when control of the good or service transfers to the customer. Use it when delivery happens at a single moment, such as a one-time software license sold outright. ASC 606 recognizes revenue at a point in time when a performance obligation does not meet the criteria for recognition over time.

Percentage-of-completion method

This method recognizes revenue in proportion to the work completed over the life of a contract. Use it for long-duration projects where the customer receives value as work progresses, such as a multi-phase implementation. Under ASC 606, this maps to recognition over time, which applies when the customer simultaneously receives and consumes the benefits, when performance creates an asset the customer controls, or when the asset has no alternative use and the company holds an enforceable right to payment.

Completed-contract method

The completed-contract method defers all revenue until the project is finished and control transfers in full. Use it when reliable progress estimates are not available until completion. This legacy construction-contract approach was superseded when ASC 606 replaced the pre-2018 industry guidance in Topic 605.

Cost-recovery method

The cost-recovery method recognizes revenue only up to the costs incurred until the outcome can be measured reliably. Use it when collection or final measurement is uncertain early in a contract. ASC 606 retains a form of this: a company “shall recognize revenue only to the extent of the costs incurred until such time that it can reasonably measure the outcome of the performance obligation”.

Installment method

The installment method spreads revenue across the periods in which the customer pays, in line with cash received. Use it mainly for extended-payment sales where collectibility is a real question, such as certain real estate deals. ASC 606 does not codify a separate installment method, so recognition timing follows the control-transfer framework instead of the payment schedule.

What are the five steps of revenue recognition under ASC 606?

The five steps, in order

ASC 606 gives all companies one framework, and it is the model many older pages leave out. The Financial Accounting Standards Board (FASB) defines five steps:

  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.

  5. Recognize revenue when, or as, each performance obligation is satisfied.

Each step gets harder when the contract carries variable, usage-based consideration, because the transaction price is no longer a single fixed number. The dedicated ASC 606 guide works through each step in detail.

What a performance obligation is

A performance obligation is the unit you recognize revenue against. The FASB defines it as “a promise in a contract with a customer to transfer to the customer either a good or service (or a bundle of goods or services) that is distinct, or a series of distinct goods or services that are substantially the same and that have the same pattern of transfer”. In practice, that means one contract can contain many obligations, and each metered charge in a usage model can become its own promise to fulfill.

How do ASC 606 and IFRS 15 differ?

Same converged model, two standard-setters

ASC 606 and IFRS 15 came from the same place. The FASB and the International Accounting Standards Board (IASB) ran a joint project and issued the two standards together in May 2014 to create common revenue guidance for U.S. GAAP and IFRS. ASC 606 is the FASB standard, IFRS 15 is the IASB equivalent, and both apply the same five-step model.

Where the two standards diverge in practice

The standards are largely converged, not identical, and companies reporting under both must reconcile the gaps. The table below summarizes four practical differences drawn from the FASB standard and Deloitte’s IFRS-versus-GAAP comparison.

Topic

ASC 606 (FASB)

IFRS 15 (IASB)

Collectibility threshold

“Probable” means likely to occur, interpreted in practice as roughly 70% or higher

“Probable” means more likely than not, a probability greater than 50%

Reversal of impairment losses

A company cannot reverse an impairment loss on capitalized contract costs

A company is required to reverse an impairment loss if conditions improve

Shipping and handling

A company may elect to treat post-control-transfer activities as a fulfillment expense

No policy election; such activities are typically a separate performance obligation

Licensing classification

Based on whether the intellectual property is functional or symbolic

Based on whether the customer can direct use of and benefit from the IP when the license is granted

How does revenue recognition work for usage-based and consumption pricing?

Why metered revenue breaks the classic methods

The classic methods assume you can price a contract up front. Usage-based pricing breaks that assumption, because the transaction price depends on consumption the customer has not yet generated. When usage volume spikes, spreadsheets break, and finance rebuilds recognition schedules by hand at month-end, tying thousands of metered events back to performance obligations. The top challenges for usage-based pricing are explaining the structure to customers and building metering infrastructure, and both feed directly into how hard the revenue is to recognize.

Recognizing overages, caps, and prepaid credits

Each usage construct maps to a recognition trigger. Overages are recognized as the customer consumes beyond a threshold, caps limit the variable consideration you can recognize, and prepaid credits sit as a contract liability that draws down into revenue as the customer uses them. Getting the accounting model right also protects margin: 67% of companies on a hybrid pricing model expect improved margins, compared with 32% on pure usage-based pricing. Chargebee RevRec recognizes this usage and consumption revenue, including application programming interface (API) call charges, token consumption, compute-based pricing, and prepaid credit drawdowns, under ASC 606. The metering of that usage happens in Chargebee Billing; the recognition of it happens in Chargebee RevRec. Keeping the two straight matters, because they are separate products.

How is revenue recognized for AI, token, credit, and agentic pricing?

Tokens, API calls, and agent runs as performance obligations

AI-native pricing pushes the performance-obligation model to its limit. A token consumed, an API call served, or an agent run completed is a distinct promise the company fulfills, and each one is a candidate performance obligation you recognize revenue against. This is where a generic answer falls short, because the accounting has to tie a specific metered event to the moment control transfers. The pricing shift is already here: 80% of companies adding AI to their products are also evolving their pricing, and those that aligned pricing with AI innovation are twice as likely to expect high growth.

Accrual vs. cash-basis treatment for consumption revenue

Consumption revenue needs accrual-basis handling. Without it, revenue defaults to cash-basis timing, which recognizes revenue when payment arrives rather than when the service is delivered, and auditors question that timing. Accrual basis, required under GAAP and IFRS, ties recognition to the satisfied obligation instead. Chargebee RevRec handles token, credit, and consumption recognition within the same rules engine as subscription revenue, so agentic and consumption models produce correct accrual-basis recognition rather than defaulting to cash-basis treatment.

How do you choose the right revenue recognition method?

Map your pricing model to a recognition method

The recognition gap opens when a team picks a method by habit rather than by pricing model. The table below maps each modern pricing model to its applicable method, its ASC 606 recognition trigger, and the operational challenge finance feels most. Because your model has likely already moved, this mapping matters: 77% of companies changed their pricing model in 2024.

Pricing model

Applicable method

ASC 606 recognition trigger

Main operational challenge

Flat subscription

Ratable over the service period

Over time, as the customer consumes the benefit

Proration on mid-term upgrades and downgrades

Usage / consumption

Recognize as consumed

Point in time, as each metered event is delivered

Tying thousands of metered events to obligations

Hybrid (base plus usage)

Split: ratable base plus usage recognition

Combination of over time and point in time

Allocating the transaction price across elements

Credit / token (prepaid)

Draw down a contract liability

Over time, as credits are consumed

Tracking breakage and unused credits

Outcome / agentic

Recognize on the outcome or run delivered

Point in time, as each outcome is satisfied

Defining the distinct obligation per outcome

A short decision path

Start with how you charge, not with the method you used last year. If the customer consumes value evenly over a term, recognize ratably. If value transfers at discrete metered moments, recognize at those points in time. If you blend both, split the contract and allocate the transaction price across each performance obligation. One engine applying all of these rules keeps the answer consistent as your pricing evolves.

What are the risks of using the wrong method?

Misstated revenue and restatement risk

The wrong method misstates revenue, and misstated revenue is expensive to unwind. It leads to restatements, audit findings, and lost investor confidence. Revenue recognition is a long-standing regulatory focus: the Securities and Exchange Commission (SEC) has called it “the largest single issue involved in restatements of financial statements”. More recently, Cornerstone Research found that revenue recognition and internal control violations were alleged in 63% of the SEC’s fiscal year 2022 accounting enforcement actions.

Slower close and audit exposure

Getting the method wrong also slows the close. When finance cannot tie thousands of metered events to performance obligations, the team reconciles by hand, the close stretches for days, and auditors question the timing of consumption revenue. You can also recognize revenue before a signed contract only in narrow cases, because ASC 606 first requires an enforceable agreement that meets its contract criteria. The operational pain compounds every time pricing changes, since explaining the structure and maintaining metering infrastructure remain the hardest parts of usage-based pricing.

How does revenue recognition software help?

What to look for in a rev-rec tool

Complex contracts overwhelm a manual close, and the fix is a rules-driven subledger. Strong revenue recognition software should apply configurable recognition rules across every pricing model, handle contract modifications such as upgrades and co-terms without manual journal entries, produce an audit trail automatically, and post clean, summarized entries to the general ledger. It should recognize revenue across contracts and usage models under both ASC 606 and IFRS 15.

How Chargebee RevRec recognizes revenue across contracts and usage

Chargebee RevRec is a revenue recognition product and subledger that sits between billing systems and the general ledger. It absorbs contract and usage complexity, applies recognition rules, and posts clean, summarized journal entries downstream, so it complements the general ledger rather than replacing it. It recognizes revenue across subscription, usage, hybrid, and credit-based contracts from one rules engine.

SA International offers a concrete example of the operational payoff. Before Chargebee, the team ran a homegrown system that could not adapt to pricing changes without developer work. After moving to Chargebee, the project manager cut time spent on the subscription system from 80% to 10%. That result reflects billing-system effort rather than a rev-rec-specific metric.

Frequently Asked Questions

What is ASC 606?

ASC 606 is the U.S. GAAP standard for recognizing revenue from contracts with customers, issued by the FASB. Its core principle is that a company recognizes revenue to depict the transfer of promised goods or services in the amount it expects to be entitled to. IFRS 15 is the converged IASB equivalent used outside the United States.

What are the five steps of revenue recognition under ASC 606?

The five steps are: identify the contract, identify the performance obligations, determine the transaction price, allocate the transaction price to the obligations, and recognize revenue as each obligation is satisfied.

How do SaaS companies recognize revenue?

Software as a service (SaaS) companies typically recognize subscription revenue ratably over the service period, because the customer consumes the benefit evenly across the term. Usage and overage charges differ, since the company recognizes them as the customer consumes them. The SaaS revenue recognition guide covers these patterns in depth.

How is revenue recognized for usage-based and AI pricing?

Each token, API call, or agent run is treated as a distinct promise, so the company recognizes revenue as it delivers each metered event. This calls for accrual-basis treatment rather than cash-basis, which auditors prefer for consumption revenue. The shift is widespread, as 80% of companies adding AI are also evolving their pricing.

What is a performance obligation?

A performance obligation is a promise in a contract to transfer a distinct good or service to the customer. For example, one year of access to a software product is a single performance obligation satisfied over the subscription term.

Conclusion

The method that fit a pure subscription a year ago strains once you add usage, credits, and AI-agent pricing, because one clean revenue line becomes thousands of consumption-based performance obligations. We believe modern pricing breaks the classic five-method model, which means finance and engineering teams need revenue recognition that works across contracts and consumption, and that is why Chargebee RevRec recognizes revenue across contracts and usage models, ready for ASC 606 and IFRS 15. Start from how you charge, map that model to its recognition trigger, and let one engine apply the rules consistently as your pricing keeps evolving.

See how Chargebee RevRec recognizes revenue across contracts and usage models.