SAP RAR Architecture: From Source Documents to Postings

SAP Revenue Accounting and Reporting (RAR) is SAP’s solution for revenue recognition under ASC 606 and IFRS 15. Many finance and IT teams know what it does – allocate the transaction price and recognize revenue – but less about how it works internally. Understanding the architecture is essential for design decisions, troubleshooting, and reconciliation.

This article walks through the flow from operational source documents to postings in the general ledger.

The Basic Principle: Separation of Operations and Accounting

In a traditional SAP setup, revenue is posted directly by the billing document. With RAR, operational processes and revenue accounting are separated:

• Operational systems – such as SAP SD, SAP BRIM, service management, or non-SAP systems – manage orders, deliveries, and invoices.

• SAP RAR receives information from these systems and determines revenue according to the accounting rules.

• The general ledger receives revenue, contract asset, and contract liability postings from RAR.

This separation allows RAR to apply accounting logic independently of how the business invoices.

Step 1: Source Documents

Every revenue-relevant event starts in a source system:

• a sales order or contract (the commitment),

• a delivery, goods issue, or service confirmation (the fulfillment),

• an invoice or credit memo (the billing).

RAR does not create these events itself. Every change in revenue accounting needs a trigger from a source system.

Step 2: Revenue Accounting Items

Source documents are transferred to RAR as revenue accounting items (RAIs). There are different classes of RAIs, typically for:

• order items – what was agreed,

• fulfillment items – what was delivered or performed,

• invoice items – what was billed.

RAIs pass through processing stages: they are received, checked, enriched, and then processed. Errors at this stage – for example, missing data or failed checks – are a frequent source of issues and must be monitored. (We cover this in a separate article on RAI processing.)

Step 3: Revenue Accounting Contracts

When RAIs are processed, RAR creates or updates revenue accounting contracts. A key design decision is how source items are combined into contracts – for example, by sales order, by customer project, or by a reference such as a quote or master agreement.

Contract combination determines which items share an allocation and therefore directly affects the revenue result.

Step 4: Performance Obligations

Within each contract, RAR creates performance obligations. These are derived from the source items, but they can also be supplemented – for example, by additional performance obligations for service-type warranties included free of charge or material rights that do not appear on an invoice.

The behavior of each performance obligation is controlled by its type: deferral method, fulfillment type, and posting rules.

Step 5: Allocation

RAR determines a standalone selling price (SSP) for each performance obligation and allocates the transaction price of the contract based on relative SSPs. SSPs are typically determined through condition records or rule-based logic. If contract changes occur, the allocation is updated.

Step 6: Fulfillment and Revenue Schedule

Fulfillment events from source systems determine when revenue is recognized:

• event-based fulfillment for point-in-time obligations, such as goods issue,

• time-based fulfillment for obligations satisfied over time, such as service periods,

• percentage-of-completion for progress-based obligations.

RAR maintains a revenue schedule for each performance obligation.

Step 7: Period-End Processing and Postings

At period end, RAR calculates the revenue to be recognized and the resulting contract balances:

• revenue for the period,

• contract assets and contract liabilities at contract level,

• reclassifications between billing clearing accounts and revenue.

These postings are transferred to the general ledger. Reconciliation between RAR, the source systems, and the general ledger completes the process.

Integration Options

RAR can be integrated with:

• SAP SD for sales orders, deliveries, and billing,

• SAP BRIM for subscription and usage-based business,

• service and contract management in SAP S/4HANA,

• non-SAP systems through standard interfaces for revenue accounting items.

In SAP S/4HANA, revenue accounting is part of the core finance architecture.

What This Means for Projects

Understanding the architecture helps answer the key design questions early:

• Which source systems deliver which RAI classes?

• How are items combined into contracts?

• Which performance obligation types are needed?

• Where do SSPs come from?

• Which events trigger fulfillment?

• How are RAR, source systems, and the general ledger reconciled?

The Bottom Line

SAP RAR is not a reporting add-on. It is a revenue subledger that sits between operational processes and the general ledger. Projects that understand and design each step of this flow – from source documents to postings – avoid most of the issues that typically appear during testing and the first period-end closes.

Related terms: Revenue Accounting Item (RAI) · Contract Combination · SAP BRIM

Related articles: Revenue Accounting Items: Processing and Error Handling · SAP RAR vs. Legacy SD Revenue Recognition

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