Migrating Existing Contracts to SAP RAR

Existing contracts are migrated to SAP Revenue Accounting and Reporting (RAR) by setting a transfer date, loading the open contracts in migration status, validating and reconciling the results, and only then switching to productive. Revenue already recognized up to the transfer date stays in the legacy process; RAR takes over from there.

Going live with RAR rarely starts with a clean slate. Most companies have open contracts: orders partially delivered, subscriptions mid-term, revenue partially recognized. These in-flight contracts have to be brought into RAR so that revenue continues correctly from the cut-over date onward.

This article explains the concepts and steps of migrating existing contracts, with a focus on the common case of moving from SD revenue recognition (SD-RR) to RAR.

Key Concepts

Transfer date. The transfer date marks the cut-over between the legacy process and RAR. It is maintained per company code and accounting principle and must be the last day of a period. Revenue recognized up to the transfer date is considered legacy; everything after it is handled by RAR.

Migration status. Before loading contracts, the company code is set to the status Migration for the relevant accounting principle. Only after successful migration and validation is it changed to Productive. That change is not meant to be undone, so it should be a formal, approved step.

Migration package. RAR uses migration packages in its setup. Whether they are required depends on the migration scenario and release, but the setup must be complete before migration tasks start.

Legacy data. Migrated contracts carry information about revenue already recognized and amounts already invoiced up to the transfer date, so RAR can calculate the remaining revenue and contract balances correctly.

Preparing the Source Data

The quality of the migration depends on the quality of the source. For SD-RR, the usual preparation steps include:

• Checking SD-RR consistency with the standard analysis tools and resolving inconsistencies with care. Mass correction functions should only be used with expert approval.

• Bringing revenue lines to their final values and recognizing open revenue lines up to the transfer date in SD-RR, because the operational load does not pick up lines that are still pending.

• Maintaining special SD processes, such as proof of delivery or incoming invoice, in Customizing if they are used.

• Keeping inflight checks active so inconsistencies are caught before contracts and POBs are saved.

For non-SD sources, the principle is the same: the operational data and the revenue already recognized must reconcile before anything is loaded.

The Migration Steps

A typical sequence for SD-based contracts:

1. Operational load. The operational load program creates revenue accounting items for the selected sales document items, including fulfillment and invoice items that reference revenue already recognized up to the transfer date. Migrated SD documents are flagged so that legacy revenue recognition no longer processes them. Each run is logged and can be reset with the same selection if needed.

2. Initial load. Processing the loaded items creates revenue contracts and performance obligations in RAR, applying your BRFplus rules for POB derivation, SSP, and account determination.

3. Period-end processing. The RAR period-end programs are run for the migration period so that contract balances and revenue are calculated on the new basis.

4. Validation. Standard checks validate contracts and POBs and compare revenue accounting items with the source data. Reconciliation reports compare RAR with operational documents and the general ledger.

5. Revenue correction. If legacy postings or billing documents were created between the transfer date and the actual load date, a revenue correction step aligns them.

6. Go productive. After sign-off, the status is switched from Migration to Productive.

If results are not acceptable, a clean-up and reset of the operational load allows the migration to be repeated before the status is set to productive.

Design Decisions That Matter

• Choice of transfer date. Align it with a period close that finance can fully reconcile and that auditors are comfortable with.

• Scope of contracts. Decide which open contracts are migrated and which are allowed to run out in the legacy process, if that is an option.

• Rules first. BRFplus rules and POB types must be final before migration. Changing rules after loading leads to rework.

• Cumulative effects. If RAR's allocation produces different results than the legacy process, the difference must be understood and agreed with accounting before posting.

• Classic or optimized. For S/4HANA, decide whether to use classic or optimized contract management before migrating, as this affects the procedure and later enhancements.

Controls and Audit

A revenue migration is a significant change to ICFR. For SOX-relevant companies, the following typically need documented evidence:

• Reconciliation of source data before migration

• Completeness of migrated contracts and POBs

• Reconciliation of migrated balances, revenue to date, and contract assets and liabilities to the GL

• Approval of the status change to productive

Plan these steps with the auditors ahead of time, not after go-live.

Common Pitfalls

• Dirty source data. Inconsistencies in SD-RR or other sources surface during the load and delay the cut-over.

• Missed timing. Postings between transfer date and load date are easy to overlook.

• Testing only happy paths. Partially delivered, partially invoiced, and modified contracts are where migrations fail.

• Ignoring leases. Lessor contracts under ASC 842 and IFRS 16 can also be migrated into RAR, without additional software, but require their own validation.

The Bottom Line

Migrating existing contracts into SAP RAR is a controlled sequence: set a transfer date, prepare clean source data, run the operational and initial loads, validate and reconcile, and only then switch to productive. The technical steps are well defined; the risk lies in data quality, timing, and reconciliation. At Revident, we approach migrations with human-governed automation, using automated checks for completeness and consistency while finance signs off every key decision.

Related terms: SAP SD · BRF+ · Revenue Accounting Item (RAI)

Related articles: From Sales Order to Revenue Contract: How SD Feeds SAP RAR

Planning to migrate existing contracts into SAP RAR? Talk to our experts.