Pomegra Wiki

Revenue Recognition Five-Step Model

The five-step revenue recognition model is the standard framework under ASC 606 (U.S. GAAP) and IFRS 15 (international standards) that governs when a company records revenue. Companies follow five sequential steps—identify the contract, identify performance obligations, determine the transaction price, allocate the price to obligations, and recognize revenue as obligations are satisfied—to ensure revenue is recorded when (and only when) the company has satisfied its promise to transfer goods or services to the customer.

Overview of the Five-Step Framework

Before ASC 606 and IFRS 15, revenue recognition rules varied by industry: software used percentage-of-completion; real estate used different criteria; retail used point-of-sale. This fragmentation created comparability problems and audit friction.

In 2014–2015, the FASB and IASB converged on a unified contract-based model: the five-step framework. The core principle is simple: recognize revenue when the company transfers control of a promised good or service to the customer. Control means the customer can use and obtain substantially all remaining benefits.

Step 1: Identify the Contract with the Customer

A contract is an agreement between a company and customer that creates enforceable rights and obligations.

Identify whether a written, oral, or implied agreement exists. The company must expect to collect the consideration promised; if payment is uncertain, revenue recognition may be deferred or reduced for expected credit losses.

Assess contract approval and intent to perform. Both parties must have approved the contract and intended to perform their obligations.

Establish contract terms: What goods or services is the company promising? On what timeline? At what price or payment terms?

Exclude non-contracts: A gift, donation, or contingent commitment may not rise to the level of a contract requiring revenue recognition.

Example

A software company signs a contract with a customer to deliver a three-year subscription to a cloud platform for $30,000. The contract specifies 12 monthly billing periods, each due upon invoice. This is a contract; Step 1 is satisfied.

Step 2: Identify Performance Obligations

A performance obligation is a promise to transfer a distinct good or service (or group of distinct items) to the customer. Most contracts have one; some have several.

Goods or services are distinct if:

  • The customer can benefit from the good/service on its own or with readily available resources, OR
  • The good/service is separately identifiable from other promised items (e.g., software license vs. support services are often distinct; a mobile phone without contract and monthly service are distinct; but a phone bundled with a two-year service plan may not be—the package is a single obligation).

Group related items if they are not distinct individually but function together as a single obligation. For example, a car with integrated electronics is a single obligation, not electronics + body + wheels.

Does the company have control? The company must be the principal (not an agent). If a company arranges but does not control delivery, it may record only the commission, not gross revenue.

Example

The software subscription contract (above) includes:

  • Cloud platform access (distinct good/service)
  • Customer support (distinct good/service)

Two performance obligations. If the customer could buy the platform without support elsewhere, both are distinct. If support is bundled inseparably (e.g., critical to platform utility), they may be one combined obligation.

Step 3: Determine the Transaction Price

The transaction price is the total amount of consideration (cash, goods, credit, discounts) the company expects to receive in exchange for satisfying performance obligations.

Include fixed amounts: The stated price is straightforward.

Include variable amounts if probable: If the contract includes volume discounts, contingent fees, rebates, or penalties, estimate the variable component using one of two methods:

  • Expected value: Probability-weighted average across all possible outcomes.
  • Most-likely amount: The single most-likely scenario.

Choose the method that best predicts actual amounts. For a discount guaranteed if the customer buys 1 million units, the expected value is precise. For a contingent bonus that might occur, estimate conservatively.

Adjust for the time value of money: If the contract allows extended payment terms (e.g., payment 5 years after delivery), discount the transaction price to present value using an implicit rate embedded in the contract.

Exclude amounts collected on behalf of third parties (e.g., sales tax the company passes to the government). These are not consideration.

Example

The software subscription is $30,000 fixed. However, the contract includes a 10% volume bonus if the customer renews for a second three-year term. The expected value of that bonus (probability-weighted) is estimated at $2,500. The company includes the $2,500 in the transaction price unless it becomes remote. If payment is received quarterly in arrears (not upfront), the company discounts the quarterly payments to present value.

Step 4: Allocate the Transaction Price to Performance Obligations

If multiple performance obligations exist, divide the transaction price among them. The allocation is based on standalone selling prices (the price the company charges for each item if sold separately).

Standalone selling price is:

  • The actual price if the item is sold separately, OR
  • If not directly observable, an estimated price based on expected cost-plus-margin, comparable items, or adjusted market assessment.

Allocate proportionally: If cloud platform access sells for $18,000 standalone and support sells for $12,000 standalone (total $30,000), allocate $18,000 to platform and $12,000 to support.

Discounts: If the bundle is discounted (e.g., $30,000 instead of $35,000 in standalone prices), allocate the discount proportionally unless the contract indicates the discount applies to a specific item.

Example

Standalone prices: Platform $20,000, Support $15,000 (total $35,000 if separate). Bundle price is $30,000 (5% discount on total). Allocate:

  • Platform: $20,000 / $35,000 × $30,000 = $17,143
  • Support: $15,000 / $35,000 × $30,000 = $12,857

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

Revenue is recognized when control of the promised good or service transfers to the customer. This occurs either:

At a point in time: Control transfers immediately (typically for product sales, single deliveries). Example: A retail sale; the customer has control and possession at checkout.

Over time: Control transfers gradually (typically for services, subscriptions, custom projects). Example: A three-year subscription; the customer gains control of the platform continuously over 36 months, so revenue is recognized ratably or based on usage.

Indicators of over-time satisfaction:

  • The customer simultaneously receives and consumes the benefits (e.g., a subscription).
  • The company creates or enhances an asset controlled by the customer (e.g., custom software being built for the customer).
  • The company does not have an alternative use for the asset if the customer cancels (e.g., a custom manufacturing process).

Progress measurement for over-time obligations:

  • Output method: Measure progress by deliverables, milestones, or units delivered (e.g., units shipped).
  • Input method: Measure progress by inputs used—cost incurred, labor hours, machine hours—as a proxy for effort expended.

Example

The three-year software subscription recognizes revenue over time (36 months) because the customer simultaneously receives and consumes access. If billed monthly at $833/month, recognize $833 in revenue each month as the platform is available. If the contract includes usage-based pricing, measure progress by actual usage or hours consumed.

A custom manufacturing contract recognizes revenue over time based on percentage of completion—either by input (labor hours spent / total estimated hours) or output (units completed / total units).

A one-time product delivery recognizes revenue at the point of transfer of control, typically upon shipment or customer acceptance.

Common Recognition Patterns

Goods sold at point of sale (retail, e-commerce): Revenue recognized when the customer obtains control, usually upon receipt or upon payment if payment occurs afterward.

Subscriptions and memberships: Revenue recognized over the subscription period (over time) as the customer receives continuous access or benefits.

Long-term service contracts (construction, custom software): Revenue recognized over time, typically using input-based or output-based progress measurement.

Licenses and intellectual property: Revenue recognized at the point of transfer of control (upfront if the customer receives a perpetual license; over the term if the license is limited-duration).

Performance bonuses and variable consideration: Estimated and included in the transaction price only if the amount is probable (not contingent on uncertain future events).

Impact on Earnings Quality

The five-step model aims to produce comparable, predictable revenue recognition across companies and industries. However, judgment remains:

  • Estimating standalone selling prices for bundled items.
  • Determining whether obligations are satisfied over time or at a point in time.
  • Measuring progress on long-term contracts.
  • Assessing probability of variable consideration.

Aggressive interpretations (e.g., recognizing upfront revenue for long-term contracts when over-time recognition is more appropriate) inflate reported revenue and earnings. Auditors focus heavily on revenue contracts to flag manipulation.

See also

  • ASC 606 — the U.S. GAAP revenue recognition standard codifying the five-step model
  • Revenue Recognition — broader overview of revenue timing and estimation
  • Earnings Quality — how aggressive revenue recognition distorts reported profitability
  • Income Statement — where recognized revenue is reported
  • Accrual Accounting — the principle underlying revenue accrual before cash receipt

Wider context