SAP RAR
Reconciling SAP RAR with the General Ledger
How to reconcile SAP RAR with the GL and operational systems: reconciliation reports, typical differences, direct posting, and SOX-ready controls.
SAP Revenue Accounting and Reporting (RAR) is reconciled with the general ledger in three layers – operational systems to RAR, RAR's own processing, and RAR postings to the GL accounts – using the standard reconciliation reports at every period end. Most differences trace back to manual GL postings, unprocessed revenue accounting items, or incomplete posting runs.
RAR calculates revenue at the level of contracts and performance obligations. The general ledger shows the result in accounts. Between the two sit posting runs, account determination, and occasionally manual journal entries. If RAR and the GL do not agree, revenue, contract assets, and contract liabilities in the financial statements cannot be trusted.
This article explains how to reconcile RAR with the GL, and with the operational systems that feed it.
Three Layers to Reconcile
Reconciliation in RAR is best understood as three layers:
1. Operational systems to RAR. Do the contracts, POBs, invoices, and fulfillments in RAR match the sales orders, billing documents, and deliveries in the sender components?
2. RAR internal. Have all revenue accounting items been processed, and have all period-end steps completed?
3. RAR to the GL. Do the amounts RAR posted match the amounts in the revenue-related GL accounts?
A difference at layer one will show up later as a difference in revenue. A difference at layer three is usually caused by postings or account assignments.
How RAR Posts
To reconcile, it helps to know where the numbers come from. At period end, RAR typically runs three steps:
Transfer revenue calculates the revenue to be recognized, without posting.
Calculate contract liabilities and assets determines contract balances at POB level, posted at POB or contract level.
Revenue posting run transfers the postings to the general ledger and other ledgers, with a simulation mode before update.
In the standard posting mode, entries are first stored in the RAR posting table and then posted to the Universal Journal. With direct posting, available in recent SAP S/4HANA releases in combination with optimized contract management, entries go straight to the Universal Journal without the subledger table, and the separate posting run is not needed. Availability depends on release and configuration, so verify it for your system. This changes which comparisons make sense, so the reconciliation approach should match the posting mode.
Standard Reconciliation Reports
SAP provides reports for each layer.
Revenue accounting and the general ledger. One report compares, by period, the amounts revenue accounting posted to each account with the amounts actually posted in the GL, and flags differences with a red indicator. A second, more technical report compares the posting table with FI documents using account assignment, GL account, and amount, and shows mismatches or records without a counterpart.
FI documents and revenue accounting contracts. A drill-down report shows which contracts and POBs are included in each posting. It does not flag differences but helps trace a GL amount back to its contracts.
Logistics and revenue accounting. This report checks contract and POB quantities and amounts against operational documents, invoiced amounts against the operational system, and fulfillment quantities against fulfillment events. Without differences, it records a "last good time" as the starting point for the next run. SAP recommends running it as a background job at period end while incoming operational events are paused.
Reports run per company code, fiscal period, and accounting principle, so parallel accounting under US GAAP and IFRS requires reconciliation per principle.
Typical Causes of Differences
Manual GL postings to revenue, contract asset, or contract liability accounts. This is the typical cause of RAR-to-GL differences.
Unprocessed or erroneous revenue accounting items, so RAR does not yet reflect operational activity.
Incomplete period-end runs, for example a posting run that failed for part of the data.
Account determination changes during the period, leading to postings to unexpected accounts.
Timing differences between the operational cut-off and the RAR cut-off.
Foreign currency effects that are calculated in RAR but analyzed differently in the GL.
Corrective Actions
Depending on the cause, the options include reversing the previous posting job, correcting account assignments, reprocessing revenue accounting items, manually adjusting POBs, and rerunning the revenue posting. Manual GL postings should be the last resort, documented and approved, because they create the next reconciliation difference if not reflected in RAR.
Designing for Reconciliation
The best reconciliation is the one that is designed in:
Dedicated accounts. Reserve RAR-specific accounts for revenue adjustments, contract assets, and contract liabilities, and block them for manual posting where possible.
Clear account determination. Keep BRFplus account determination at POB type level where feasible, rather than at individual POB level, which can produce decision tables with thousands of entries.
Defined period-end sequence. Process items, check errors, run the period-end programs, then reconcile.
Evidence for SOX. Retain report outputs, sign-offs, and explanations for each difference as control evidence.
Same logic for leases. Lessor income under ASC 842 and IFRS 16 in RAR follows the same posting and reconciliation logic, without additional software.
The broader period-end checklist is covered in a separate article; reconciliation is its final and most visible step.
The Bottom Line
Reconciling RAR with the GL means checking three layers: operational systems to RAR, RAR's own processing, and RAR to the GL. SAP's standard reports cover each layer, and most differences trace back to manual postings, unprocessed items, or incomplete runs. Design accounts, rules, and period-end steps with reconciliation in mind, and keep the evidence auditors need. At Revident, we combine these checks with human-governed automation: the system finds and explains differences, and finance decides how to resolve them.
Related terms: Universal Journal · Contract Liability · Revenue Accounting Item (RAI)
Related articles: RAR Classic (Add-On) vs. RAR in SAP S/4HANA
Struggling to reconcile SAP RAR with the GL? Talk to our experts.
SAP RAR
Migrating Existing Contracts to SAP RAR
How to move in-flight contracts into SAP RAR: transfer date, migration status, operational load, initial load, validation, and switching to productive.
Read article →
SAP RAR
What Is SAP RAR? A Guide for US Finance Teams
What SAP Revenue Accounting and Reporting does, who needs it, what typically triggers adoption, and how it differs from spreadsheets and legacy SD revenue recognition.
Read article →
SAP RAR
SAP RAR Architecture: From Source Documents to Postings
How SAP Revenue Accounting and Reporting works end to end – from source documents and revenue accounting items to contracts, performance obligations and postings.
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.