SAP RAR vs. Legacy SD Revenue Recognition

SD Revenue Recognition decides the timing of revenue per sales document item, while SAP Revenue Accounting and Reporting (RAR) applies the full ASC 606 and IFRS 15 model at contract level. Because SD Revenue Recognition is not available in SAP S/4HANA, RAR is the path forward for companies moving there.

Many SAP ECC customers recognized revenue for service contracts, maintenance agreements, and event-driven deliveries long before ASC 606 existed. They did it with SD Revenue Recognition – a function inside Sales and Distribution that separates revenue from billing. For years it worked well enough. This comparison explains how the two approaches differ and why the decision is largely made for companies moving to S/4HANA.

What SD Revenue Recognition Does

SD Revenue Recognition is configured per item category and works at the level of individual sales document items. It decouples the timing of revenue from the timing of the invoice using a few methods:

• At billing – revenue at the time of billing, the standard behavior without a revenue recognition category.

• Time-related – revenue spread evenly between defined dates, typical for maintenance or service contracts.

• Service-related – revenue triggered by an event, such as a delivery or a service call-off.

Differences between billed and recognized amounts are carried on balance sheet accounts for deferred revenue and unbilled receivables. Revenue lines are posted periodically from the sales document.

The design reflects its origin: it answers the question "when should the revenue of this item be recognized?" It was not built to answer "how should the price of the whole contract be allocated across its promises?"

What SAP RAR Does Differently

SAP Revenue Accounting and Reporting (RAR) moves revenue recognition out of the operational document and into a dedicated accounting layer:

• Revenue contracts and performance obligations. Operational documents are transferred as revenue accounting items and build revenue contracts with performance obligations – the structure of the ASC 606 five-step model.

• Allocation based on standalone selling prices. The transaction price is allocated across performance obligations, so bundles, discounts, and free items are reflected in revenue rather than in item prices.

• Contract combination and modifications. Items from several source documents can form one revenue contract, and changes flow into the contract with defined handling.

• Multiple accounting principles. Contracts are processed per accounting principle, which supports parallel US GAAP and IFRS reporting.

• Multiple sources. Besides SD, RAR receives data from SAP BRIM and other sender components, including non-SAP systems.

• Contract balances and disclosures. Contract assets and contract liabilities are determined at contract level, which is what ASC 606 presentation requires.

Side-By-Side

• Unit of account – SD Revenue Recognition: Sales document item; SAP RAR: Performance obligation within a revenue contract

• Allocation – SD Revenue Recognition: Not designed for relative SSP allocation; SAP RAR: SSP-based allocation across obligations

• Bundles across documents – SD Revenue Recognition: Limited to item level; SAP RAR: Contract combination across sources

• Accounting principles – SD Revenue Recognition: One view per item; SAP RAR: Parallel processing per accounting principle

• Contract assets/liabilities – SD Revenue Recognition: Deferred revenue and unbilled receivables per item; SAP RAR: Determined per contract

• Data sources – SD Revenue Recognition: SD documents; SAP RAR: SD, BRIM, other sender components, non-SAP systems

• Availability in S/4HANA – SD Revenue Recognition: Not available; SAP RAR: Available

The S/4HANA Factor

For most companies, the comparison ends with one fact: SD Revenue Recognition is not available in SAP S/4HANA, and SAP RAR is the designated successor. Legacy transactions such as VF44 for posting revenue lines are not supported there. Open SD Revenue Recognition documents have to be transferred to RAR before the S/4HANA conversion – SAP provides migration tools and a dedicated migration guide for this. The detailed migration approach is covered in our article on migrating existing contracts to RAR.

This has a planning consequence: the move to RAR is not something to deal with after go-live. It is a prerequisite that should be scoped and tested as its own workstream.

What Changes for Finance

The technical switch is the smaller part. The bigger change is in how finance works with revenue:

• Policies become configuration. SSP determination, performance obligation types, and fulfillment rules are defined explicitly, often through BRF+ rules, instead of being implied by item categories.

• Revenue is reviewed per contract. Finance reviews revenue contracts, allocation effects, and contract balances – not just revenue lines per sales document.

• Reconciliation changes. Billing and revenue are deliberately separated, so reconciliation between RAR, the general ledger, and the source documents becomes a routine close activity.

• SOX controls move. Key controls shift from SD configuration and billing to RAR configuration, manual contract changes, and posting runs.

When Item-Level Logic Is Still Enough

Not every company needs the full power of RAR from day one. If revenue is mostly point-in-time, with few bundles and no material allocation effects, a simple RAR configuration may mirror the old behavior closely. Some S/4HANA scenarios also use event-based revenue recognition for specific processes, which we compare separately. The point is to make that choice consciously, based on ASC 606 requirements, not on what the old system happened to do.

The Bottom Line

SD Revenue Recognition answered a timing question at item level and served many ECC customers well. SAP RAR answers the full ASC 606 and IFRS 15 question – contract, performance obligations, allocation, and contract balances – across sources and accounting principles. For companies moving to S/4HANA, RAR is not an option among several but the path forward, and the transition is best planned before the conversion, not after.

Related terms: SAP SD · Contract Combination · Deferred Revenue

Related articles: SAP RAR Architecture: From Source Documents to Postings

Moving from SD Revenue Recognition to SAP RAR? Talk to our experts.