The 5-Step Model of IFRS 15 / ASC 606 Explained for SAP Teams

ASC 606 and IFRS 15 share one core framework: a five-step model that determines when and how much revenue a company recognizes. Accountants usually know the model well. SAP teams often know the system well. Problems arise where the two meet – when accounting judgments have to become master data, configuration and integration logic.

This article walks through each step and shows what it means in an SAP landscape.

Step 1: Identify the Contract

A contract exists when there is an agreement between parties that creates enforceable rights and obligations, has commercial substance, and where collection of the consideration is probable.

What it means in SAP: The accounting contract is rarely identical to a single sales order. A customer agreement can span several sales orders, service contracts and billing documents across different systems. In SAP Revenue Accounting and Reporting (RAR), source documents are transferred as revenue accounting items and combined into revenue accounting contracts. The combination logic – which items belong together – is one of the most important design decisions in any implementation.

Typical questions to answer early:

• Which reference (quote, master agreement, customer project) links related documents?

• Must contracts concluded at or near the same time be combined?

• How are contracts from non-SAP systems integrated?

Step 2: Identify the Performance Obligations

A performance obligation is a promise to transfer a distinct good or service – or a series of distinct goods or services that are substantially the same and follow the same pattern of transfer.

What it means in SAP: Not every order item is a performance obligation, and not every performance obligation has an order item. Service-type warranties (for example, an extended warranty included free of charge), material rights, or implied services may need to be modeled as separate performance obligations even though they never appear on an invoice. A standard assurance-type warranty, by contrast, is not a separate performance obligation. In SAP RAR, performance obligations are derived from source items and can be supplemented by additional, system-generated performance obligations.

Getting this step right requires a joint view: accounting defines what is distinct, the system design defines where that information comes from.

Step 3: Determine the Transaction Price

The transaction price is the amount of consideration a company expects to be entitled to. It includes fixed amounts, variable consideration (discounts, rebates, penalties, bonuses), significant financing components, and non-cash consideration.

What it means in SAP: Pricing conditions in SAP SD are the starting point, but they are not automatically the transaction price. Rebates agreed separately, expected returns, or financing components may need additional logic. The more variable the pricing, the more important it is to define which estimates are made, where they are stored, and how updates flow into revenue accounting.

Step 4: Allocate the Transaction Price

The transaction price is allocated to the performance obligations based on their relative standalone selling prices (SSP). Discounts are generally allocated proportionally unless specific criteria for a different allocation are met.

What it means in SAP: Allocation is where SAP RAR adds the most value compared to traditional billing-based revenue. RAR determines SSPs – typically via condition tables or rule-based logic – and reallocates the transaction price across all performance obligations of a contract. The quality of the result depends directly on the quality and maintenance of SSP data. (We cover SSP in detail in a separate article.)

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

Revenue is recognized when control of a good or service transfers to the customer – either at a point in time or over time.

What it means in SAP: The fulfillment event must be captured reliably. For point-in-time obligations, this is usually a goods issue or proof of delivery. For over-time obligations, it can be time-based, based on progress, or event-based. In SAP RAR, fulfillment types and deferral methods control this behavior. Event-based fulfillment needs a trigger from a source system – RAR does not create these events on its own. Time-based fulfillment, by contrast, is calculated by RAR from the start and end dates of the performance obligation.

Where Implementations Typically Struggle

Across industries, the same issues come up repeatedly:

• Contract combination that does not reflect how the business actually sells.

• Missing performance obligations for items that are not invoiced, such as service-type warranties included free of charge.

• SSP data that is incomplete, outdated, or not maintained by a clear owner.

• Fulfillment events that arrive late or not at all from source systems.

• Reconciliation between operational systems, revenue accounting and the general ledger that was not designed from the start.

Related Articles

• Standalone Selling Price (SSP): Methods and Common Mistakes

• Contract Modifications: Prospective vs. Cumulative Catch-up

• IFRS 15 vs. ASC 606: Where the Standards Still Differ

The Bottom Line

The five-step model is an accounting framework, but in SAP it becomes a data and process design. Successful implementations translate each step into clear rules: where the information comes from, who owns it, and how it is validated. That is where accounting expertise and SAP engineering have to work together – from the first design workshop through go-live.

Planning or modernizing an SAP RAR implementation? Talk to our experts.