Revenue Recognition
Contract Modifications: Prospective vs. Cumulative Catch-up
How ASC 606 and IFRS 15 classify contract modifications, when to apply prospective or cumulative catch-up treatment, and what this means for SAP RAR.
Contracts change. Customers add products, extend terms, cancel services, or renegotiate prices. Under ASC 606 and IFRS 15, every change in scope or price that is approved by both parties is a contract modification – and the accounting treatment depends on what exactly changed.
For many companies, contract modifications are the scenario where revenue accounting becomes truly complex, both in policy and in system design.
What Counts as a Contract Modification?
A contract modification is a change in the scope, the price, or both, that is approved by the parties. It can be written, oral, or implied by customary business practice. A modification can exist even if the price change has not been finalized, as long as the change in scope is approved and the price change can be estimated.
The Three Accounting Treatments
The standards define three ways to account for a modification:
1. Separate Contract
A modification is treated as a separate contract if both conditions are met:
the scope increases because of additional distinct goods or services, and
the price increases by an amount that reflects their standalone selling prices.
The original contract remains unchanged. The additional items are accounted for as a new contract.
Example: A customer orders additional equipment units at the regular price. The original contract is not affected.
2. Prospective Treatment (Termination of the Old Contract and Creation of a New One)
If the modification is not a separate contract and the remaining goods or services are distinct from those already transferred, the modification is accounted for prospectively. The remaining consideration – the unrecognized portion of the original contract plus the consideration from the modification – is allocated to the remaining performance obligations.
Revenue already recognized is not adjusted.
Example: A multi-year service contract is extended at a discounted rate. Past service periods are complete; future periods are distinct. The new price is spread over the remaining term.
3. Cumulative Catch-Up
If the remaining goods or services are not distinct and form part of a single, partially satisfied performance obligation, the modification is treated as part of the existing contract. The measure of progress and the transaction price are updated, and revenue is adjusted on a cumulative catch-up basis at the date of the modification.
Example: The scope of a customized installation project is changed while the work is in progress. The change affects a single performance obligation, so revenue to date is adjusted.
Combinations
A single modification can trigger more than one treatment, for example when some remaining items are distinct and others are part of a partially completed obligation. In these cases, the effects must be split accordingly.
Why This Is Difficult in Practice
Classification requires judgment. Whether the price reflects SSP, or whether remaining items are distinct, is not always obvious.
Changes arrive through many channels. Order changes, credit memos, new orders referencing old ones, or changes in service systems can all represent modifications.
Timing matters. The modification date determines what has already been satisfied and how the remaining price is allocated.
Volume. In subscription or leasing businesses, modifications are not exceptions but daily operations.
Contract Modifications in SAP RAR
SAP Revenue Accounting and Reporting supports both retrospective (cumulative catch-up) and prospective handling of contract changes. Which treatment applies depends on configuration and, where required, customer-specific logic that classifies the type of change.
Key design questions include:
How is a change identified and linked to the original contract?
Which change types exist in the business, and which accounting treatment applies to each?
How is the modification date determined and transferred?
How are the effects reconciled between source systems, RAR, and the general ledger?
Scenarios such as early terminations, upgrades, term extensions, or price changes typically need to be defined one by one – with clear accounting rules and test cases for each.
Related Articles
The 5-Step Model of IFRS 15 / ASC 606 Explained for SAP Teams
SAP Subscription Billing and RAR: How Subscription Revenue Gets Recognized
The Bottom Line
Contract modifications are where accounting policy, business processes, and system logic must align precisely. Companies that define their change types upfront, assign a clear accounting treatment to each, and test them systematically avoid the most common sources of manual corrections and audit findings.
Dealing with complex contract changes in SAP RAR? Talk to our experts.
Revenue Recognition
Revenue Recognition for GPU and Compute Capacity Contracts
Reserved capacity, usage fees, minimum commitments, and embedded leases – how ASC 606 and ASC 842 apply to GPU and compute capacity contracts, and how to implement them in SAP.
Read article →
Revenue Recognition
The 5-Step Model of IFRS 15 / ASC 606 Explained for SAP Teams
How the five steps of ASC 606 and IFRS 15 translate into SAP processes, data and system design – a practical guide for finance and IT teams.
Read article →
Revenue Recognition
Standalone Selling Price (SSP): Methods and Common Mistakes
How to determine standalone selling prices under ASC 606 and IFRS 15, which estimation methods are allowed, and the mistakes that cause problems in SAP RAR.
Read article →
Ready to Make Your SAP Finance Landscape Agentic?
Whether you are implementing SAP RAR, modernizing revenue processes, or exploring agentic finance operations, Revident helps you move from strategy to execution.