Migration Guide for SD Revenue Recognition to

SAP Revenue Accounting and Reporting

1
TABLE OF CONTENTS
1 INTRODUCTION .......................................................................................................................... 4
1.1 Overview ..................................................................................................................................... 4
1.2 Timeline / End-to-End Process .................................................................................................. 5
2 RESTRICTIONS ........................................................................................................................... 5
2.1 Migration Prior to S/4HANA ....................................................................................................... 5
2.2 Out-of-Scope............................................................................................................................... 5
3 PREQUISITE ACTIVITIES............................................................................................................ 6
3.1 Consistency Check of SD Revenue Recognition Data .............................................................. 6
3.2 Update Sales documents with VF42 .......................................................................................... 8
3.3 Recognize Open Revenues with VF44 ....................................................................................... 8
3.4 Setup of SAP Revenue Accounting & Reporting ...................................................................... 9
3.4.1 Customizing ................................................................................................................................ 9
3.4.2 Migration Packages .................................................................................................................... 9
3.4.3 Transfer Date .............................................................................................................................10
3.4.4 Special SD Processes ...............................................................................................................10
3.4.5 Activation of Inflight Checks .....................................................................................................10
4 MIGRATION TOOLS ...................................................................................................................11
4.1 Operational Load .......................................................................................................................11
4.1.1 General Functionality ................................................................................................................11
4.1.2 Prerequisites..............................................................................................................................11
4.1.3 Selection ....................................................................................................................................11
4.1.4 Processing Parameters .............................................................................................................11
4.1.5 Expert Mode ...............................................................................................................................12
4.2 Revenue Correction Report ......................................................................................................13
4.2.1 Correction of Revenues ............................................................................................................14
4.2.2 Correction of Billing Documents ..............................................................................................14
4.3 Checks .......................................................................................................................................15
4.3.1 Revenue Accounting Data Validation .......................................................................................15
4.3.2 Two-Step Reconciliation ...........................................................................................................15
4.3.2.1 Comparison SD data with Revenue Accounting Items ..................................................................16
4.3.2.2 Comparison Revenue Accounting Items with RAR Contract Data.................................................16
5 MIGRATION OF THE REVENUE RECOGNITION PROCESSES ................................................17
5.1 Sales Order or Contracts with Category A ...............................................................................17
5.2 Sales Order with Category B .....................................................................................................17
5.3 Contract + Call-off Orders with Category B..............................................................................18
5.4 Sales Order or Contract with Category D .................................................................................18
5.5 Credit/Debit Memo Request with Category A or B ...................................................................19
5.6 Credit/Debit Memo Request with Category D ...........................................................................19
5.7 Credit/Debit Memo Request with Category F ...........................................................................19
5.8 Credit/Debit Memo w/o request with Category A or B .............................................................19
5.9 Return Order with Reference to a Sales Order with Category B .............................................20
5.10 Return Order with Reference to a Contract/Call-off Order with Category B ...........................20
6 SPECIAL PROCESSES ..............................................................................................................21
6.1 Invoice Cancellation (VF11) ......................................................................................................21

2
6.2 Sales Document Items with Rejection Code ............................................................................21
6.3 Revenue Recognition Cancellation (VF46) ...............................................................................21
6.4 Cost of Sales..............................................................................................................................21
6.4.1 Statistical Cost Condition Type in SD RR.................................................................................21
6.4.2 Stock-in-Transit (SIT) Functionality ..........................................................................................22
6.4.3 No Cost Recognition in SD RR .................................................................................................23
6.5 Profitability Analysis (CO-PA) ...................................................................................................23
6.5.1 Condition Types ........................................................................................................................23
6.5.2 Cost Elements............................................................................................................................23
6.5.3 Migration Aspects......................................................................................................................24
6.6 Foreign Currency Handling .......................................................................................................24
6.6.1 Fixed Exchange Rate Method (FX1) ..........................................................................................24
6.6.2 Actual Exchange Rate Method (FX2) ........................................................................................24
6.6.3 Example .....................................................................................................................................25
6.7 Price Change in SD....................................................................................................................26
7 VALUABLE OSS NOTES............................................................................................................28

3
1 INTRODUCTION

1.1 Overview

The SD Revenue Recognition (SD RR) functionality has been available in SAP ECC since 2005. It was
developed to cover the requirement whereby you defer revenues and recognize them as either event or time-
based. This was driven mainly by US GAAP regulations and since 2005 has become a proven and stable
component that is used by thousands of SAP customers.

As soon as the new regulations from IFRS15 were visible, discussions began on whether SD RR could be
used beyond its original scope to cover the new requirements. As SD RR does not offer sufficient
functionality, the decision was made to develop SAP Revenue Accounting and Reporting (SAP RAR) as a
new solution. The aim for SAP RAR is to handle the new IFRS15 regulations announced on May 28, 2014
with an effective date of January 1, 2018 in countries that adhere to both US GAAP and IFRS.

SAP RAR is available as an add-on and can be implemented in SAP ECC (minimum prerequisite is release
6.0 with enhancement package 5) or SAP S/4HANA. For integration with Sales and Distribution, you will also
require software component SAP Sales Integration with SAP Revenue Accounting and Reporting 1.0 (SAP
SALES INTEGR SAP RAR 1.0).

For more information on supported software stacks, please refer to the Release Strategy Note: 2386978 -
Release strategy for the ABAP add-on REVREC 130.

From S/4HANA 1809 onwards, the former SAP Revenue Accounting and Reporting add-on became an
integral part of SAP S/4HANA. This relates to product version SAP REVENUE ACCOUNTING and includes
software component version REVREC. The software component SAP Sales Integration with SAP Revenue
Accounting and Reporting 1.0 (SAP SALES INTEGR SAP RAR 1.0) has also been added to the SAP
S/4HANA 1809 stack.

For more information on S/4HANA 1809 please refer to the following Note: 2675360 - Revenue Accounting
and Reporting with SAP S/4HANA 1809: Release Information Note.

When SAP S/4HANA was developed, the decision was made to only proceed with one solution that defers
and recognizes revenues in the on-premise stack. This solution is SAP RAR. Therefore, it is clearly stated in
all versions of the Simplification List for SAP S/4HANA that the SD RR functionality will no longer be
available in S/4HANA. SAP RAR must be used instead.

That means that all customers using SD RR and planning to convert to S/4HANA (brown field approach) or
implementing S/4HANA in a new system (greenfield approach), must migrate all SD RR relevant sales
orders and contracts to SAP RAR prior to the S/4HANA conversion or implementation.

It is not possible to migrate SD RR to SAP RAR after the Go-live with S/4HANA.

As migration cannot be fully automated and you need to setup SAP RAR before you start the migration, this
process should be considered a separate project and should not be combined with the S/4HANA
implementation. The project must be planned carefully with sufficient time and resources so that migration is
finished before the S/4HANA project starts.

The purpose of this migration guide is to provide guidance on all processes and steps that must be executed
during the migration process.

4
1.2 Timeline / End-to-End Process

The following graph outlines a common project setup:

For general information about migration approaches to SAP Revenue Accounting and Reporting please view
SAP’s Online Help here.

2 RESTRICTIONS

2.1 Migration Prior to S/4HANA

As SD RR functionality is no longer available in S/4HANA, migration from SD RR to SAP RAR is necessary

prior to the implementation of S/4HANA.

In preparation for the S/4HANA conversion, the SIC Framework (Simplification Item Check) can be used to
identify those simplification items that are relevant for the customer and to determine the steps to be
performed in the system to start and maintain consistent conversion. It is expected soon that an additional
check is added in order to detect if SD RR was active in the previous system landscape.

This check works as following:

1. Checks if entries in table VBREVK exist. If no entries exist, conversion can proceed.
2. If yes, checks if entries in table VBREVE with VBREVE-REVFIX = ‘M’ exist, meaning that the sales
documents are already migrated. If no entries exist, it is assumed that there are SD RR relevant
sales documents to be migrated and therefore the S/4HANA conversion is blocked.
3. If entries exist, it means that migration has been already (maybe partially) performed. In this case, a
check occurs to determine whether there are remaining open sales documents that are still SD RR
relevant. Technically, the check sees whether there are entries in VBKD with VBKD-RRREL that are
not blank and that corresponding entries in table VBUP with VBUP-RRSTA are not equal to ‘C’. If the
check is positive, the S/4HANA conversion is blocked.

If there are open SD documents that cannot be or must not be migrated, there is an option for the SIC check
to skip the above described checks in order not to block the S/4HANA conversion.

In the unlikely scenario where a customer might use SD RR in a system with a release lower than 6.05, the
system must first be upgraded to a release higher than or equal to 6.05. RAR can then be implemented, and
migration from SD RR will then be performed. Conversion to S/4HANA is then finally made possible.

2.2 Out-of-Scope

The following restrictions must be considered:

5
 • All SD RR processes (categories) that are described in the SD Revenue Recognition Best Practices
document can be migrated to SAP RAR. There is only one exception; if customer-specific events
were implemented in SD RR, the related sales documents cannot be migrated adequately.
• IS-Media specific processes (revenue recognition category M) cannot be migrated at all.
• Industry solutions that influence the standard Sales & Distribution processes (e.g. IS-OIL, IS-ADEC-
BCQ) were not validated or released. Therefore, these solutions are also not supported in the
integration component respectively in the migration process.
• In 2004 there was a change to the standard SD RR that implemented a new link between the posted
revenue lines in table VBREVE and the corresponding FI documents (please refer to OSS notes
508305, 940784 and 940997). During the operational load it is necessary to select the FI documents
for all VBREVE lines that were already posted. This selection only works for documents that use the
new reference logic. Hence, SD documents created before the change cannot be migrated.
• Depending on the support stack of SAP RAR 1.3 that is used, other restrictions may apply. Please
carefully read OSS Note 2591055.
• If SD RR relevant sales documents which are completed and therefor were not migrated to SAP
RAR are changed or referred to after the migration, they will not follow the old SD RR behaviour.

3 PREQUISITE ACTIVITIES

3.1 Consistency Check of SD Revenue Recognition Data

As with other data migration scenarios, it is recommended that you ensure all source data is correct and
consistent prior to being transferred to the new environment by the migration process.

Transaction VF47 in SD RR (Revenue Recognition: Inconsistency Check in Revenue Tables) can be used
for checking source data. VF47 is a very powerful tool that enables you to identify many different
inconsistency types within SD RR data.

More information about VF47 and the potential error codes can be found in OSS Note 399777.

Not all potential error codes have an impact on migration to SAP RAR. The relevant error patterns that are
detected by VF47 are checked by the operational load program (see chapter 4.1).

Out of all specified error patterns (E01 to E26) the following are checked by the operational load:

Error Code Short Text

E05 Missing Revenue Account in Revenue Lines: SAKRV ( ).
E10 Differences in Total Accrual/Deferral Amnt: ACC_VALUE.
E17 No Reference Lines Available for Billing Document in Table VBREVR.
E18 Total Amount Difference for Control Lines and Sales Document Item:
E19 Currency Differs in Control Lines and Revenue Lines.
E20 Currency Differs in Control Lines and Reference Lines.
E22 Currency Differs in Accounting Document and Control Lines.
E24 Total amount difference for control lines and billing item:

The E11 error code is only considered in one specific scenario that may lead to incorrect legacy data from
the operational load: If there are revenue lines in table VBREVE with status ‘C’ but no content in the field
VBREVE-SAMMG, an error is raised too. This scenario could occur in the past when customers tried to fix
documents with an E16 error on their own by using the update feature of transaction VF47.

During operational load, VF47 is called for every sales document item with the following parameters first:

6
A second check is performed using the Read Revenue Lines in FI flag instead of Read Revenue Lines in SD.

Note: The Read Revenue Lines in FI option does not provide reliable results if FI summarization is active for
postings from SD RR (IMG: Financial Accounting resp. Financial Accounting (New) → Periodic Processing
→ Integration → Sales and Distribution → Perform Document Summarization for Sales and Distribution).

The same restriction applies if the relevant FI documents from SD RR have already been archived.

As soon as error patterns are detected, either via the operational load or using VF47 in advance, Customer
Incidents can be raised accordingly. It is not recommended to use the update functionality of VF47 to fix
certain inconsistencies, unless it is approved by an SAP RR expert.

Please refer also to OSS Note 2755553.

7
3.2 Update Sales documents with VF42

Before you proceed with the migration process, you should make sure that all revenue lines in the table
VBREVE (Revenue Recognition: Revenue Recognition Lines) have their final values.

This can be achieved by running the transaction VF42 (Revenue Recognition: Update SD Documents). This
transaction checks if there are remaining entries in the table VBREVC (Revenue Recognition: Worklist of
Changed Sales Documents) and executes an update of the sales documents.

The minimum requirement is to run the transaction with the flag “According to Automatic Worklist” selected. If
the total number of SD documents to be migrated is not too big, it may be better to run VF42 for all relevant
sales documents. This ensures that all SD documents were updated and that potential adjustments in the SD
RR database were created.

You do not need to run the transaction VF42 if the sales documents are updated in real-time in SD RR (IMG:
Sales and Distribution → Basic Functions → Account Assignment/Costing → Activate SD Functions).
In this case, there must be no entries in the table VBREVC.

All sales documents, for which entries in VBREVC exist, are not picked up by the operational load.

3.3 Recognize Open Revenues with VF44

If the end date of the SD RR relevant sales document is in the past, all open revenue lines must be
recognized before migration starts. Otherwise, all follow-up processes in SAP RAR (such as re-scheduling)
may not work correctly.

Use transaction VF44 (Revenue Recognition: Post Revenue) to recognize all open revenue lines. Please
consider even revenue lines that are blocked manually. You can recognize blocked revenues by setting the
relevant flag on the VF 44 selection screen.

In all other cases, it is recommended that you recognize all revenues up to the transfer date, even from a
business perspective.

8
3.4 Setup of SAP Revenue Accounting & Reporting

3.4.1 Customizing

To prepare for the migration itself, the future revenue accounting and reporting processes must all be set up
first.
The majority of the customizing settings can be found under: IMG: Financial Accounting resp. Financial
Accounting (New) → Revenue Accounting. Alternatively, transaction FARR_IMG can be used to view the
revenue accounting customizing.
The main processes include:
• Activation of the required Revenue Accounting Item classes and generation of the interfaces
• Setup the accounting principles and maintain the company code related settings
• Creation of contract categories and POB (Performance Obligation) types, including the related
number ranges
• Maintenance of the BRF+ application for the SAP RAR processes (access is also possible using
transaction BRF+)
• Create the accounts, then setup account determination for RAR-specific P&L and balance sheet
accounts

3.4.2 Migration Packages

The creation and use of migration packages is not mandatory for SD RR migration. Migration packages are
only required if the migration should be performed in multiple waves. This means that after the migration of
the first wave, revenue accounting is already productive. In this case, the migration package is required for
the next wave to start again, as the next migration package has the status set to Migration.
Example:
Two different SD RR processes should be migrated in company code 1000; one is represented by item
category ZRRA and the other by ZRRB.
In the first wave, all sales document items with ZRRA should be migrated.
• Setup of IMG: Sales and Distribution → Revenue Accounting and Reporting → Maintain Revenue
Accounting Item Settings: The appropriate revenue accounting type is assigned to the combination
of sales organization, order type, and item category ZRRA, but has no package ID assigned.
• Setup of IMG: Financial Accounting resp. Financial Accounting (New) → Revenue Accounting →
Revenue Accounting Contracts → Assign Company Codes to Accounting Principles: One line is
maintained per combination of company code 1000/accounting principle, and the status is set to
Migration. No further lines are required on the second level of this customizing view.

When you start the operational load, the Migration Package ID field should be empty. After the first migration
wave is finished, the status is set to Productive. One month later, the second wave should follow for sales
document items with item category ZRRB.
• Setup of IMG: Sales and Distribution → Revenue Accounting and Reporting → Maintain Revenue
Accounting Item Settings: The appropriate revenue accounting type assigned to the combination of
sales organization, order type, and item category ZRRB. Now you need to assign a package ID
(M001 for example), which also needs to have been created previously.
• Setup of IMG: Financial Accounting resp. Financial Accounting (New) → Revenue Accounting →
Revenue Accounting Contracts → Assign Company Codes to Accounting Principles: Create an
additional line with Package ID M001 on the second level related to the existing line for company
code 1000 and then set the status to Migration.

When you now start the operational load, the migration Package ID M001 must be entered on the selection
screen.

9
3.4.3 Transfer Date

On the first level in the customizing transaction IMG: Financial Accounting resp. Financial Accounting (New)
→ Revenue Accounting → Revenue Accounting Contracts: Assign Company Codes to Accounting Principles
and if required, maintain a transfer date on the second level. The transfer date must be always the last day of
a period and cannot be a future date.
This date identifies the point-in-time on which SD RR stops for a corresponding set of SD Documents and
SAP RAR continues with the migrated documents. It means that for SD RR migration, the operational load
only selects the posted revenue lines that are assigned to periods lower than or equal to the period of the
transfer date. Legacy data for SAP RAR is also created.

3.4.4 Special SD Processes

If in SD RR, special event types such as proof of delivery (PoD) or incoming invoice are used, the
corresponding entries must be maintained in IMG: Sales and Distribution → Revenue Accounting and
Reporting → Activate Functions to Integrate with Revenue Accounting.

3.4.5 Activation of Inflight Checks

Inflight checks were introduced with SAP RAR Release 1.3. These checks are executed when you process
the RAIs to create or change RAR contracts and POBs. The aim is to detect inconsistencies as early as
possible, before any contracts or POBs are stored in the database.
Please make sure that the checks provided by BAdI FARR_EXTENDED_CHECK are not de-activated or
manipulated. More information about the BAdI can be found in OSS Note 2476987, and more information
about inflight checks can be found in OSS Note 2567106.

10
4 MIGRATION TOOLS

4.1 Operational Load

4.1.1 General Functionality

Then main tool that is used to migrate SD RR data to SAP RAR is the operational load program. Transaction
FARRIC_OL or customizing menu IMG: Sales and Distribution → Revenue Accounting and Reporting →
Execute Operational Load is used to start the migration process.

This program creates fulfillment RAIs and invoice RAIs based on the selected sales documents order Items.
In addition, it refers to the already recognized revenues (entries in table VBREVE with status C up to the
transfer date) legacy data that was created. Both, RAIs and legacy data are then processed by the RAI
monitor (Transaction FARR_RAI_MON).

As soon as the SD data is transformed into RAIs and legacy data, the revenue recognition category is
removed from the sales document item and all revenue lines (both those already posted and those that are
open) are set to Inactive (field VBREVE-REVFIX is set to M). This means that nothing can be processed by
referring to the migrated documents using VF44/VF46 after the operational load has been executed.

Additionally, all table entries from SD RR remain available for reporting or audit purposes.

4.1.2 Prerequisites

The operational load only works as expected if:

• SD item categories that are initially assigned to a SD RR revenue recognition category are set up in
the SD Integration Component as relevant for SAR RAR (IMG: Sales and Distribution → Revenue
Accounting and Reporting → Maintain Revenue Accounting Item Settings)
• Integration Component for Revenue Accounting is activated (IMG: Sales and Distribution →
Revenue Accounting and Reporting → Integrate with Revenue Accounting and Reporting)
• the affected company code is customized for initial load, meaning that the status Migration must be
assigned to the relevant company codes (IMG: Financial Accounting New → Revenue Accounting →
Revenue Accounting Contracts → Assign Company Codes to Accounting Principles).

4.1.3 Selection

Based on the entered selection parameters; company code, sales organization, distribution channel, sales
document type, sales document, creation date and migration package ID; for all selected documents, the
root documents are selected.

The root document is the document that is found on the highest level of the document flow. Afterwards, for
each root document, all follow-up documents down to the lowest level are determined (including sales
documents, delivery documents, and billing documents).

For SD RR-relevant sales documents, the item status in table VBUP is checked. The document is skipped if
the revenue determination status (VBUP-RRSTA) is C (Completed).

Another important selection criterion is the document date of the sales document. Only if the document date
is older than or equal to the migration transfer date, the documents are selected by the operational load.

4.1.4 Processing Parameters

External Run ID
For every execution of the operational load, there is a unique ID to identify the run. This ID is generated
automatically. If required, an explicit unique external key can be entered. This can be useful as the content of
this field is displayed in the application log (Transaction SLG1) and can be used to identify different runs.

11
Processing Type

Apart of the type Load that creates the RAIs and the legacy data, the program can also be executed using
the Reset type. If an operational load (or any further processing in Revenue Accounting) was not successful
and the operational load must be performed again, the previously loaded documents must be reset first.
Otherwise, the operational load cannot select them again. Reset means that the Revenue Accounting
relevance is removed from the corresponding item and the revenue lines in the table VBREVE are activated
again. Therefore, the program recovers the state in SD that existed before the last operational load, but only
if the same selection criteria is applied.

Note: RAIs created by the operational load are not deleted by using the Reset option. If this is required, the
transaction FARR_IL_CLEANUP (Initial Load: Cleanup Report) must be applied.

Synchronous Online Processing

By default, when you execute the program, the system creates jobs automatically in the background.
Normally one job works on one package (see below) and the next one is created automatically once the first
job is finished. To get automatic parallelization, there is an additional option to maintain the number of jobs
that should be started automatically in parallel.

4.1.5 Expert Mode

If the selected options of the transaction FARRIC_OL are not sufficient, the extended version can be used
with transaction FARRIC_OL_EXPERT. This provides some additional flags that can be used to control the
behavior of the operational load in more detail. However, these flags are provided to cover all of the different
migration scenarios. For some flags, it does not make sense to change the default setup for migration from
SD RR to SAP RAR.

The following section describes the purpose of the additional options:

Process Fulfillment Documents

If this checkbox is selected, the fulfillment documents of the selected sales orders are processed too. In most
cases, this flag must not be deleted. Only if custom specific event types were implemented in SD RR it
should be part of a custom-made solution.

Process Billing Documents

If this checkbox is selected, the billing documents in the document flow of the selected sales documents are
processed too. It should never be deselected for SD RR migration.

Create Legacy Data

If this checkbox is selected, legacy data creation is performed. The realized revenue is obtained from SD RR
(from the posted revenue lines in table VBREVE) if a sales document item is relevant for SD RR (meaning
that VBKD-RRREL is not blank) and the integration component for SAP RAR is active (IMG: Sales and
Distribution → Revenue Accounting and Reporting → Integrate with Revenue Accounting and Reporting).
For SD RR migration to SAP RAR, this flag should not be deselected.

Search for Root Documents

If this checkbox is selected, the selection of the involved documents is performed as described in chapter
4.1.3. This flag should be selected only if it is requested that the selection of the documents should start with
the numbers entered on the selection screen, as successor documents only determined downwards from
there (to the lowest level of the document flow).

Read from Archive

If this checkbox is selected, SD billing documents and FI documents that are archived, are read from the
archive if they are required as a basis for the migration RAIs and legacy data. If this option is deselected and
a document is archived, an error message is raised.

12
Skip completed Sales Documents (default setting)

If this checkbox is selected (Default setting), the set of documents that are determined by the entered
selection is reduced by the already completed documents. The completion is identified in table VBUK. Only
documents without status C are considered for the overall processing status of document (VBUK-GBSTK) or
documents that have status C (completed) in VBUK-GBSTK and the revenue determination status (VBUK-
RRSTA) is A (Not yet processed) or B (Partially processed).

Transfer Revenue Schedule

Without selecting this checkbox (default setting), SAP RAR distributes the migrated transaction price per
POB to the periods according to the rules maintained in BRF+ and then saves the result into the revenue
schedule. Only if a special distribution was implemented in SD RR (BTE event 00503105) and this
distribution should be transferred to SAP RAR, this flag must be selected. This flag is only relevant for SD
documents with revenue recognition category A (Time-related revenue recognition) or D (Billing-related,
time-related revenue recognition). Even if the flag is selected and there are open revenue lines before the
transfer date, the open amount is accumulated into the first period after the transfer date.

Incl Rev status cmpl items

By default, the operational load would not consider sales document items that are already completed from an
SD RR perspective, meaning those that have a revenue determination status of C (Completed) in table
VBUP. If it is required that such document items are considered by the operational load because a customer
expects future activities on these items, this flag must be selected.

Create FX Diff. Conditions

If the FASB52 functionality was activated in SD RR and in SAP RAR, the actual exchange rate method is
used. Additional lines are added to the legacy data with the operational load that represent the cumulated
value of legacy exchange rate gains or losses caused by the SD RR postings. To enable this functionality,
this flag must be selected.
If FASB52 was not in use in SD RR, it is strongly recommended to deselect this flag to improve the
performance of the operational load.

Run Consistency Check

It is possible that sales order items in SD RR have inconsistent data that could result in inconsistent RAR
contracts after the migration process is complete. To avoid this, it is recommended that you execute the
consistency check for error patterns relevant for migration to RAR. If inconsistencies exist, the report will not
load the affected sales orders. The error patterns need to be fixed before the sales order can be migrated.
Details can be found in OSS Note 2755553.

4.2 Revenue Correction Report

This report is necessary if in SD RR, between the transfer date and the date of the operational load, VF44
postings and/or SD RR relevant billing documents were created. You can use either the transaction
FARRIC_RR_CORR or for expert mode, transaction FARRIC_RR_CORR_EXP (report
FARRIC_SD_REV_CORRECT). Expert mode allows you to deactivate the correction functionality for billing
documents, which is not possible in basic mode.

Corrections can only be done if the report is performed while the corresponding combination of company
code/migration package has the status Migration.

It is recommended to execute the revenue correction report as the last step of migration once the RAI
consistency in inbound processing has already been verified. Operational load reset should never be
executed after the revenue correction report has been executed.

The latest updates for this correction report are provided with OSS Note 2715378. If this note is
implemented, the table FARRIC_MIGRATED can be checked to see which SD documents require revenue

13
correction. For all SD documents that display values X (Correction needed), I (Invoice corrected), or R
(Revenue corrected) in the field INV_CORR, the correction program must be performed.

To ensure that SD RR revenue lines are not incorrectly deleted during operational load in reset mode, you
must make sure that OSS Note 2702035 is implemented in the system.

The current RESET logic does not reverse the posted invoice-correction in FI. Consequently, if the item is
reset, loaded again, and then corrected again, it will post duplicate invoice-corrections. To avoid this, the
following workaround is recommended:

I.) Reverse the invoice correction line in VF46 after the manual RESET
II.) Run the document manually through VF42
III.) Load the document again in FARRIC_OL
IV.) Run FARRIC_RR_CORR again

4.2.1 Correction of Revenues

To explain this functionality, the following example is used:

An SD document item with SD RR category A exists with start date 01.01.2018, end date 31.12.2018, and a
net value of 1.200 EUR.

Lines in table VBREVE were created and are already recognized with transaction VF44 for the periods
January to April (in total 400 EUR). The corresponding billing document was posted too in period 1/2018. For
migration, the transfer date is set to 31.03.2018.
The operational load in April would create an order RAI (this creates one POB with a transaction price of
1.200 EUR), an invoice RAI with the same amount (both with initial load flag), and legacy data with an
accumulated amount of 300 EUR.

Although 400 EUR are already recognized in SD RR, the legacy amount is 300 EUR as revenues are only
considered if they were posted prior to the transfer date.

Within the revenue schedule of the created SAP RAR contract, 100 EUR is then assigned to each period;
even to period 4, which is the first period after the transfer date. If the posting is executed in SAP RAR,
revenues would be created for period 4 again. In this case, the revenues in period 4 would be doubled in FI
(100 EUR realized by VF44 and 100 realized by the SAP RAR posting run).

The transaction FARRIC_RR_CORR can now be used to reverse the revenues already posted in SD RR.
The reversal works exactly as expected from transaction VF46. An additional revenue line in VBREVE for
period 4 with reversed signs is created and immediately posted. A second line is created for period 4 again
with status A and fixed revenue line indicator M.

4.2.2 Correction of Billing Documents

To explain this functionality, the following example is used:

A SD document item with SD RR category A exists with start date 01.01.2018, end date 31.12.2018, and a
net value of 1,200 EUR.

Lines in table VBREVE were created and already recognized with transaction VF44 for the periods January
to March (in total 300 EUR).

The billing document is created in period 4/2018. For migration, the transfer date is set to 31.03.2018.

The operational load in April would create an order RAI with an initial load flag (this creates one POB with a
transaction price of 1.200 EUR), an invoice RAI with the same amount without an initial load flag, and legacy
data with an accumulated amount of 300 EUR.

After Go-live, the processing of the invoice RAI would create invoice correction lines in the SAP RAR sub-
ledger because SAP RAR assumes that revenues caused by a billing document must be reversed. However,

14
the billing document in SD RR has not been posted to revenues, but to a balance sheet account instead.
Therefore, reposting is now necessary from the balance sheet account to revenues. This re-posting
document is created by the transaction FARRIC_RR_CORR. Changes in the SD RR tables are not
necessary.

4.3 Checks

4.3.1 Revenue Accounting Data Validation

To ensure quality and consistency for SAP RAR contracts and POBs created by the migration process, the
transactions FARR_CONTR_CHECK and FARR_CONTR_MON can be used.

Note: The standard version of this check helps determine technical inconsistencies within the SAP RAR
contract management database. It does not reconcile the RAR contract data against the corresponding
documents in the sender component.

To enhance the program functionality so that the basic SD values are also compared with the transaction
price of the resulting POBs, the BAdI FARR_BADI_CONS_REPORT can be implemented. SAP provides
sample coding that can be inserted into the BAdI Implementation. More information on this process is
provided in OSS Note 2714781.

How to use both transactions and how the error codes can be interpreted is explained in the document SAP
Revenue Accounting Data Validation.pdf which is attached to OSS Note 2567106.

4.3.2 Two-Step Reconciliation

The following two transactions were developed to focus separately on the two steps SD → RAI and RAI →
RAR Contract/POB unlike the consistency check described above.

The reports are useful in the test phase of the migration project, where single test cases must be checked. It
is not proven that a high volume of documents/RAIs can be analyzed without performance issues.

15
4.3.2.1 Comparison SD data with Revenue Accounting Items

Transaction FARR_CHECK_CONS was developed to ensure that the source data has been transferred
correctly to the inbound layer of SAP RAR.

For SD RR migration, it must be ensured that the created RAIs based on the SD documents are correct.

In general, the report expects processed RAIs. Therefore, an error message is created if processable RAIs
are selected. That would mean in the case of SD RR migration, that a large volume of error messages would
be raised if the check is performed right after the creation of the processable RAIs by the operational load.

To avoid this, the messages can be deactivated by using a special customizing setting (IMG: Financial
Accounting (New) → Revenue Accounting → Revenue Accounting Contracts → Change message control).
Insert a new line for message number 507 and disable the message for online and/or batch mode.

4.3.2.2 Comparison Revenue Accounting Items with RAR Contract Data

Use transaction FARR_RAI_RECON to reconcile the amounts and quantities from the processed revenue
accounting items with the resulting POB values.

16
5 MIGRATION OF THE REVENUE RECOGNITION PROCESSES

Every process type of SD RR is explained in this chapter in terms of how it should be processed to get it into
the new SAP RAR environment.

Each section starts with an overview of the main settings in the source (SD RR) and the target (SAP RAR)
environment.

As already mentioned in chapter 0, the settings for SAP RAR must be maintained before migration starts.
The column Revenue Accounting Type refers to the customizing setting where the revenue accounting type
is assigned to sales organization, order type, and item category (IMG: Sales and Distribution → Revenue
Accounting and Reporting → Maintain Revenue Accounting Item Settings).

For most of the migration cases there are no settings in the BRF+ ruleset Process POB that are necessary.
When order RAI’s created by the operational load are processed it is hard-coded in the specific program
which fulfillment type, which event type, and which start date type (if necessary) are assigned to the resulting
POB’s. There is only one exception to this rule: see chapter 5.3.

5.1 Sales Order or Contracts with Category A

Revenue Recognition Category A = Time-related revenue recognition

SD Revenue Recognition SAP Revenue Accounting and Reporting

SD Document Revenue Revenue Revenue Fulfillment Event Start
Recognition Event Accounting Type Type Date
Category Type Type Type
Sales Order/Contract A N/A X T N/A 1

5.2 Sales Order with Category B

Revenue Recognition Category B = Service-related revenue recognition

Revenue Event Type N = Not POD-Relevant
Revenue Event Type A = Incoming Invoice
Revenue Event Type B = Acceptance Date
RAR Event type GI = Goods Issue
RAR Event type PD = Proof of Delivery
RAR Event type PI = Purchase Invoice (Drop Shipment)

SD Revenue Recognition SAP Revenue Accounting and Reporting

SD Document Revenue Revenue Revenue Fulfillment Event Start
Recognition Event Accounting Type Type Date
Category Type Type Type
Sales Order B N/A X E GI N/A
Sales Order with PoD B N/A X E PD N/A
Sales Order with PoD B N X E GI N/A
Sales Order B A X E PI N/A
Sales Order B B X E AD N/A

Short General Process Description:

Apart of sales order items with the normal SD RR category B (goods issue as a relevant event for revenue
recognition) there are several variants with special revenue event types (see chapter 4.2 of the SD RR Best
Practices Document). In addition, the process with Proof-of-Delivery (PoD) relevant sales orders could be
implemented with or without the stock-in-transit functionality (provided by the business function
LOG_MM_SIT).

This stock-in-transit functionality was the only option in SD RR to achieve a kind of cost recognition using
standard means. The effect of this feature is that the goods-issue related to a delivery does not post CoGS,

17
but instead creates a pure material management document that moves the goods simply from unrestricted to
a special part of the stock, called stock in transit (movement type 687). The real cost posting is not done until
proof-of-delivery is confirmed (movement type 601). Since it is in parallel, the PoD confirmation is the trigger
for the revenue recognition too. The effect is that revenues and CoGS are posted at least in the same period
(which is the goal of the cost recognition feature in SAP RAR as well).

Migration of Sales Documents with Category B

There is nothing special to be considered for the migration of all different types of sales documents using SD
RR category B.

5.3 Contract + Call-off Orders with Category B

Revenue Recognition Category B = Service-related revenue recognition

RAR Event type RO = Contract Release Order (= Call-off Order)
RAR Event type GI = Goods Issue

SD Revenue Recognition SAP Revenue Accounting and Reporting

SD Document Revenue Revenue Revenue Fulfillment Event Start
Recognition Event Accounting Type Type Date
Category Type Type Type
Contract with delivery B N/A X E GI N/A
relevant call-off’s
Contract with service B N/A X E RO N/A
call-off’s
Call-off Order with B N/A C N/A N/A N/A
delivery or service
material

Short General Process Description:

When a SD contract is saved, and the revenue accounting type X is assigned to the item category, order
RAI’s are created. Dependent on the type of the order item (is it a delivery relevant item or an item with a
non-stock service material) event type GI (in case of delivery) or RO (in case of service material) must be
derived in BRF+. For the call-off order items, revenue accounting type C must be determined in the SD
customizing. In BRF+ no separate settings are required since no order RAI’s are created for call-off orders at
all.

Migration of Contracts plus Call-off Orders

Unlike the migration of other revenue recognition categories, in this case it is necessary to maintain entries
within the BRF+ ruleset Process POB. This is to set up the created POB’s in such a way that they either
expect a delivery (related to a call-off order) plus goods issue as a fulfillment event (event type GI) or the
call-off order itself as the fulfillment event (event type RO). If the call-off order works as a fulfillment event,
the document date from the header data of the call-off order is taken over as the event date.

5.4 Sales Order or Contract with Category D

Revenue Recognition Category D = Billing-related, time-related revenue recognition

SD Revenue Recognition SAP Revenue Accounting and Reporting

SD Document Revenue Revenue Revenue Fulfillment Event Start
Recognition Event Accounting Type Type Date
Category Type Type Type
Sales Order/Contract D N/A G T N/A 1

The core functionality of this process is that for each billing document, one performance obligation (POB) in
SAP RAR is created. This is valid for migrated documents as well as for documents initially created in SAP
RAR. However, there is a difference in the behavior regarding the creation of successor documents such as

18
credit/debit memo requests or billing cancellations. If in SD RR e.g. billing cancellations were posted, the
operational load would create two POB’s, one for the original billing document and another for the billing
cancellation. The same scenario created directly in SAP RAR would use only one POB and a cancellation of
the billing document would simply adjust the value of the existing POB. This would be the behavior as well if
successor debit/credit memo requests would use the revenue accounting type ‘M’. Only if type ‘G’ or type ‘X’
would be used for credit/debit memo requests, separate POB’s for these follow-up documents would still be
created.

Please refer to OSS Note 2719185 too.

5.5 Credit/Debit Memo Request with Category A or B

Revenue Recognition Category A = Time-related revenue recognition

Revenue Recognition Category B = Service-related revenue recognition

SD Revenue Recognition SAP Revenue Accounting and Reporting

SD Document Revenue Revenue Revenue Fulfillment Event Start
Recognition Event Accounting Type Type Date
Category Type Type Type
Stand-alone Credit/ A N/A X T N/A 1
Debit Memo Request
Stand-alone Credit/ B* N/A X E ??? N/A
Debit Memo Request
* Solution evaluated, but not yet available

5.6 Credit/Debit Memo Request with Category D

Revenue Recognition Category D = Billing-related, time-related revenue recognition

SD Revenue Recognition SAP Revenue Accounting and Reporting

SD Document Revenue Revenue Revenue Fulfillment Event Start
Recognition Event Accounting Type Type Date
Category Type Type Type
Credit/Debit Memo D N/A G T N/A 1
Request

5.7 Credit/Debit Memo Request with Category F

Revenue Recognition Category F = Credit/Debit Memos with reference to predecessor

SD Revenue Recognition SAP Revenue Accounting and Reporting

SD Document Revenue Revenue Revenue Fulfillment Event Start
Recognition Event Accounting Type Type Date
Category Type Type Type
Credit/Debit Memo F N/A M N/A
Request

In this case, in SAP RAR there are no necessary separate settings for the fulfillment type, event type, and
start date type as the SD credit/debit memo request does not create order RAIs. It only triggers the creation
of invoice RAIs based on the credit/debit memo that belongs to the credit/debit memo request with revenue
recognition category F.

5.8 Credit/Debit Memo w/o request with Category A or B

19
If credit/debit memos should be migrated that were created with a reference to a revenue recognition
relevant billing document, no separate settings in SAP RAR are necessary. Only invoice RAIs are generated
with a reference to the number of the basic SD RR-relevant sales document.

The settings for the correct migration of the initial sales document must be done according to the sections
described above.

5.9 Return Order with Reference to a Sales Order with Category B

SD Revenue Recognition SAP Revenue Accounting and Reporting

SD Document Revenue Revenue Revenue Fulfillment Event Start
Recognition Event Accounting Type Type Date
Category Type Type Type
Return Order B N/A X E GI N/A

5.10 Return Order with Reference to a Contract/Call-off Order with Category B

SD Revenue Recognition SAP Revenue Accounting and Reporting

SD Document Revenue Revenue Revenue Fulfillment Event Start
Recognition Event Accounting Type Type Date
Category Type Type Type
Return Call-off Order* B N/A C E GI N/A
* Solution evaluated, but not yet available

20
6 SPECIAL PROCESSES

6.1 Invoice Cancellation (VF11)

If in SD for a SD RR relevant sales document, a billing document and a cancellation of the billing document
were created (both with posting dates prior to the transfer date), nothing in addition must be considered from
a migration perspective. These billing documents are skipped by the operational load as they completely
offset each other; their documents even remain in SD RR in table VBRP (Billing document items).

If these types of documents are treated with the operational load, the resulting RAIs appear as if there was
no billing document posted at all, meaning that no invoice RAIs are created.

If the posting date of the billing cancellation is after the transfer date, then the operational load considers
both the original billing document (RAI with initial load flag) and the billing cancellation (without the initial load
flag). Nevertheless, the correction program described in chapter 4.2.2 must be applied.

A special behavior was designed for sales documents with revenue recognition category D. These billing
document items are only excluded from the operational load if both the cancelled document and its
cancellation, are fully realized in transaction VF44. If either of these processes still has open revenue lines,
then the two documents do not cancel each other out completely. Their exact legacy amounts must be
accumulated and transferred into two separate RAR contracts so that the open revenue is scheduled
accordingly in SAP RAR.

6.2 Sales Document Items with Rejection Code

SD document items with a rejection code assigned are treated by the operational load in the same way as
normal document items. For example, in the operational process, the rejection code in SD triggers the
population of the field Finalization Date in the order RAI. This tells the RAR contract respectively, that the
performance obligation must be completed.

For migration, the operational load fills the last change date from the table VBAK (header data of a sales
document) into the finalization date of the created order RAI.

6.3 Revenue Recognition Cancellation (VF46)

If within the periods that should be migrated, revenues were reversed in SD RR with transaction VF46,
nothing extra must be considered for the SD RR migration. The cancelled lines are correctly handled when
the legacy data is calculated; the legacy amount is reduced by the revenue amount of the period that was
reversed.

Note: The reversal line and the reversed line do not get M (Migrates to Revenue Accounting) in field
VBREVE-REVFIX (like all other posted VBREVE lines) but keep A (reversed line) and B (reversal line)
instead. These lines are completely skipped when the cumulated revenue amount is calculated for the legacy
data transfer.

6.4 Cost of Sales

6.4.1 Statistical Cost Condition Type in SD RR

As there was no explicit functionality available in SD RR for cost recognition, at least an option was offered to
show the cost-of-sales amounts that correspond to the revenues recognized by VF44 in the same period
rather than the revenues. This option was applicable only for customers using costing-based CO-PA
(Profitability Analysis in Controlling).

The pricing of an SD RR relevant sales document item can contain a special statistical condition type with
condition category ‘G’ that represents the standard price of the sold material (in most cases it is condition
type VPRS). If this is the case, SD RR creates entries in table VBREVE not only for the recognized revenues
but also lines with the VPRS amount to represent the cost-of-sales. The cost-of-sales amounts correspond
always to the revenue amounts. That means, even in a time-based process, the costs are distributed to

21
several periods according to the distribution of the total revenue amount. However, when VF44 prepares the
accounting documents based on the lines in VBREVE, the VPRS lines are considered statistical and their
amounts are transferred exclusively to the line item of the costing-based CO-PA, if the assignment of
condition types to value fields was set up accordingly (Transaction KE4I). To be clear: there is no cost
deferral or final cost recognition in financial accounting.

Now we come to the migration. Since in SAP RAR there is a real cost recognition functionality available it is
not possible to continue the old feature with the statistical cost condition type. That means, if it is requested
to still get the cost-of-sales amounts together with the revenues into CO-PA, the cost recognition functionality
must be switched on in SAP RAR (IMG → Financial Accounting resp. Financial Accounting (New) →
Revenue Accounting → Revenue Accounting Contracts → Configure Accounting Principle-specific Settings).
The migration of SD RR relevant sales documents using the statistical cost condition is supported exclusively
for event-based processes in SD RR that use goods issue as a trigger for revenue recognition. Only in those
cases it is possible to populate the legacy data with cost amounts during the migration with the amounts
used in the goods issue posting in FI.

To make it clear again: there is no migration of (statistical) costs from a sales document with a time-based
revenue recognition category. As there is no solution available for cost handling in time-based SAP RAR
contracts, it is recommended that you set the flag “No Cost Recognition” for the relevant performance
obligation types (IMG → Financial Accounting resp. Financial Accounting (New) → Revenue Accounting →
Revenue Accounting Contracts → Define Performance Obligation Types):

If cost recognition is not active in SAP RAR in general, statistical cost-of-sales will be posted to costing-
based CO-PA by the billing documents created after the migration. There is no cost posting to CO-PA via the
SAP RAR posting run. But this might lead to the result that costs are shown in the wrong period.

In S/4HANA it is recommended that you use account-based CO-PA. That means, if a switch from costing-
based to account-based CO-PA is intended, then only the activation of the cost recognition in SAP RAR
guarantees that cost-of-sales are visible in CO-PA after the migration.

6.4.2 Stock-in-Transit (SIT) Functionality

There is a special functionality that can be enabled by activating the business function LOG_MM_SIT. This
changes the delivery and goods issue process so that when a goods issue referring to a delivery is posted,
there is simply a reposting from unrestricted stock to a stock in transfer. This is a pure MM posting and
nothing happens in FI. At a certain point-in-time the proof of delivery must be confirmed. This confirmation
triggers the real goods issue posting (debit cost of sales - credit inventory).

Since SD RR offers an event type proof-of-delivery as well for an event based revenue recognition process,
the combination of the stock-in-transit functionality and the SD RR process leads results in revenues as well
as cost of sales that are triggered by the same event (SD proof of delivery confirmation) and therefore both
P&L lines are posted in the same period (according to the matching principle requested by several
accounting principles).

If sales documents using the SIT process are migrated in SAP RAR, cost recognition is not necessary as the
deferral and recognition of the cost of sales is done by the SIT process. Furthermore, since the FI documents
for deferral and cost recognition are now posted in the correct period, these cost-of-sales amounts would be
visible in CO-PA too, but only if account-based CO-PA is used. If costing-based CO-PA should be applied

22
further, the cost recognition in SAP RAR must be activated. Otherwise the cost-of-sales value field would not
be filled by the RAR posting run.

6.4.3 No Cost Recognition in SD RR

If in the SD RR process, cost-of-sales are not considered at all, neither statistically via condition type VPRS
nor via SIT with real cost postings, it can be decided based on the requirement of the business whether cost
recognition in SAP RAR should be activated or not. If not, SAP RAR only takes care of deferring and
recognizing revenues. Costs are not considered at all. If yes, costs are deferred and recognized in SAP RAR
as of the transfer date after the migration.

6.5 Profitability Analysis (CO-PA)

CO-PA is the component which is used by the majority of the processes in SD RR as account assignment
object for the revenue postings from VF44. This is most likely the case also for the future FI RAR postings,
although all other account assignment objects like internal orders, WBS elements or accounting relevant
sales order items can be used as well.

Most customers have implemented the costing-based CO-PA (using characteristics and value fields). Even
though with S/4HANA, the account-based CO-PA will become increasingly important, the focus of this
migration guide is on the migration from SD RR to SAP RAR using costing-based CO-PA.

6.5.1 Condition Types

In general, the prerequisite for the use of costing-based CO-PA is that all used condition types (revenues
and costs) are assigned to certain value fields (IMG → Controlling → Profitability Analysis → Flows of Actual
Values → Transfer of Billing Documents → Assign Value Fields → Maintain Assignment of SD Conditions to
CO-PA Value Fields). Please note that for all revenue conditions (revenue and revenue deduction) the flag
‘Transfer +/-‘ must be selected, and for the cost condition, the flag has to be empty:

6.5.2 Cost Elements

All P&L lines that should be transferred to costing-based CO-PA from SAP RAR should use cost elements
either with type 11 (Revenues) or type 12 (Sales deduction). This is valid even for cost elements that are
used for recognized cost in RAR account determination. As sales deductions are normally debit postings
such as cost, the cost element type 12 is recommended for cost recognition accounts.

23
6.5.3 Migration Aspects

Even though there is a change in the posting paradigms between SD RR (the billing document posts directly
to an accrual account) and SAP RAR (billing document posts to revenues account and the RAR posting run
reverses the revenues with an accrual as offset account), the costing-based CO-PA gets the revenues
properly before and after the migration as long as the prerequisites described above are followed. Only one
issue occurs if in SAP RAR, more than one accounting principle is used. Either you decide to populate CO-
PA only with amounts from one accounting principle. In this case you must use the other accounting
principles P&L accounts without any cost element at all. Or you want to see the amounts of all accounting
principle in CO-PA. Then you must setup a user-exit in CO-PA that transfers the amounts from one condition
type into different value fields, according to the use accounting principle in SAP RAR.

Regarding the cost postings, the cut between SD RR and SAP RAR is more substantial. In SD RR there was
no real cost recognition functionality available like there is now in SAP RAR. In SD RR, costs are only treated
in SD RR in order to feed the costing-based CO-PA with statistical cost amounts together with the revenue
recognition postings via transaction VF44. No cost postings in FI were performed at all.

Since the cost recognition feature is activated in SAP RAR (see recommendation in chapter 6.4.1), after the
migration, the cost postings to CO-PA are created by the SAP RAR posting run. These value field amounts
are no longer statistical but reflect the real cost posting even in FI.

Please note: It is not possible to continue the statistical cost postings to CO-PA with the SAP RAR posting
run for a time-based contract like it was done in SD RR via VF44 (see chapter 6.4.1 too).

6.6 Foreign Currency Handling

In SD RR, a feature is available to avoid remaining balances in a local currency on the accrual accounts if
the transaction currency of the basic sales document is not equal to the local currency of the corresponding
company code. It can be found under the key word FASB52. This can be activated within the view
V_160MVA with the variable message V4 314 (see also OSS Note 786266) or within IMG: Sales and
Distribution → Revenue Accounting and Reporting → Activate Functions to Integrate with Revenue
Accounting. The first posting related to a sales document item, fixes the used exchange rate (date of the
exchange rate) and all follow-up postings use the fixed rate to calculate the values in the local currency. In
addition, the differences are posted to an exchange rate difference account.

In SAP RAR, there are two different methods for converting contract values in a foreign currency to the local
currency(ies): the fixed exchange rate method (FX1) and the actual exchange rate method (FX2). More
information on both methods can be found here.

The required method must be assigned to the used accounting principles (IMG: Financial Accounting resp.
Financial Accounting (New) → Revenue Accounting → Revenue Accounting Contracts → Configure
Accounting Principle-specific Settings).

To prepare for exchange rate differences that can be updated in the table FARR_D_POSTING, one special
condition type must be defined and assigned in the following customizing view: IMG: Financial Accounting
resp. Financial Accounting (New) → Revenue Accounting → Revenue Accounting Contracts → Condition
Types → Define Reserved Condition Types.

The system behavior of the migration process differs depending on which conversion method is chosen.

6.6.1 Fixed Exchange Rate Method (FX1)

If the FASB52 functionality was used in SD RR, a fixed exchange rate is transferred by the operational load
to the legacy data (table FARR_D_LEGACY). However, the exchange rate differences that were already
posted are not handed over to SAP RAR. When the RAIs and the legacy data that were created by the
operational load are processed, SAP RAR calculates currency differences ex post based on the transferred
fixed exchange rate and saves it directly in the table FARR_D_POSTING with posting category ED.

6.6.2 Actual Exchange Rate Method (FX2)

24
If the FASB52 functionality was activated in SD RR and in SAP RAR the actual exchange rate method is
used, the operational load creates (in addition to the legacy data = already recognized amounts) entries in
the table FARR_D_LEGACYC that represent the accumulated value of the already posted exchange rate
differences in FI.

Based on these special legacy table entries, an additional table is filled during the processing of the RAIs:
table FARR_D_INV_FX_ED.

Finally, out of this table, program FARR_CONTRACT_LIABILITY creates lines in table FARR_D_POSTING
with posting category ED that represent the already posted exchange rate gain/loss postings up to the
transfer date.

Note: If the exchange rate differences are already determined by the operational load and handed over to
SAP RAR via the legacy data, the report FARR_MIGRATION_ED_CALC must not be started after the
processing of the migrated RAIs.

If FASB52 functionality was not used in SD RR, no exchange rate difference data is transferred to SAP RAR
at all. Exchange rate differences are calculated in SAP RAR as of the transfer date according to the rules of
FX2.

In some cases, in SD RR it was requested that even with activated FASB52 functionality, revenues in foreign
currency should be converted with the fixed exchange rate but should not create exchange rate difference
lines. This can be achieved by using BTE 00503115. However, the operational load does not consider this
BTE and creates exchange rate differences lines in the legacy data regardless of whether the actual
exchange rate method is used in SAP RAR. To adjust these automatically created exchange rate difference
lines in the legacy data table, a custom-made solution is required.

6.6.3 Example

For a better understanding of the migration of documents with foreign document currency, the following
example was created:

Original Document
• SD contract item with revenue recognition category D
• Document Currency CHF, Local Currency EUR
• Item net value 1920 CHF
• Start date 01.05.2018, End date 30.04.2019
• FASB52 functionality activated

Exchange Rates CHF → EUR

• 01.05.2018: 0,666667
• 31.05.2018: 0,625000
• 30.06.2018: 0,588235

Postings Before Migration

Posting Amount in Doc. Amount in Local

Date Account Doc. Curr. Curr. local Curr. Curr.
Billing document 01.05.2018 Deferred Revenues -1.920,00 CHF -1.280,00 EUR
Revenue 31.05.2018 Revenues -160,00 CHF -100,00 EUR
Recognition Deferred Revenues 160,00 CHF 106,67 EUR
Exch. Rate Differences -6,67 EUR
Revenue 30.06.2018 Revenues -160,00 CHF -94,12 EUR
Recognition Deferred Revenues 160,00 CHF 106,67 EUR
Exch. Rate Differences -12,55 EUR

25
The exchange rate that was used for the billing document was fixed (respectively the date 01.05.2018 was
fixed in table field VBREVK-BASE_DAT). This rate was subsequently used to convert the amounts on the
deferred revenues account even for the revenue recognition postings. To finally get the FI document to a
balance of zero, additional lines with the exchange rate difference account were created.

Revenue Accounting Settings

• Transfer Date 30.06.2018
• Two accounting principles (GAAP with method FX1 and IFRS with method FX2)

Operational Load

The fixed exchange rate date from VBREVK-BASE_DAT is taken over to the field Translation Date of the
created invoice RAI, that is visible in the RAI Monitor (Transaction FARR_RAI_MON).

The fixed exchange rate itself can be seen in the created legacy main items, which also visible in the RAI
Monitor.

For accounting principle GAAP, only one line for the legacy condition items was created as the handling of
the exchange rate differences is done later in the SAP RAR process:

Amount in Doc. Amount in Local

Condition Type Doc. Curr. Curr. local Curr. Curr.
PR00 320,00 CHF 194,12 EUR

For accounting principle IFRS, there are two legacy condition items created:

Amount in Doc. Amount in Local

Condition Type Doc. Curr. Curr. local Curr. Curr.
PR00 320,00 CHF 194,12 EUR
EXRR 19,22 EUR

The total of the already posted exchange rate differences is taken over into a separate line.

RAI Processing

During the RAI processing, specific lines are created in the posting table FARR_D_POSTING, but only for
the contract with accounting principle GAAP, with fixed exchange rate method FX1.

Amount in Doc. Amount in Local

Posting Category Doc. Curr. Curr. local Curr. Curr.
ED 0,00 CHF -19,21 EUR
RA 0,00 CHF 19,21 EUR

The amount of 19,21 was calculated ex post: 213,33 EUR (total postings to deferred revenues account using
fixed exchange rate) minus 194,12 EUR (total amount virtually posted to deferred revenues account using
the actual exchange rate).

For the contract with accounting principle IFRS and actual exchange rate method FX2, the exchange rate
lines in the table FARR_D_POSTING are not calculated again but are instead taken over from the legacy
data when program B (Contract Liabilities and Assets) is performed the first time.

6.7 Price Change in SD

There is one situation in SD RR that cannot be handled adequately by the SAR RAR standard coding.
Therefore, additional measures are required to migrate these documents. The issue occurs when the total
amount of calculated legacy data per SD sales document item exceeds the current net value of the item.

26
Example:

Initial SD sales document item with RR category A, net value of 1200 EUR, start date 01.01.2018, and end
date 31.12.2018. Revenue Lines are created with 100 EUR per period.

Transfer date should be 31.10.2018 and 1,000 EUR revenues are already recognized until period 10 by
VF44. Before migration starts, the net value of the sales document item is changed to 960 EUR. This
generates an adjustment line in table VBREVE for period 11, with a 120 EUR revenue reversal and a regular
line in period 12 with 80 EUR.

The operational load creates an order RAI with a contractual price of 960 EUR and legacy data of 1,000
EUR. This would create an inconsistency within the revenue schedule of the RAR contract.

To mitigate this situation, SAP provides the correction report ZFARR_CALC_REV_AMT via OSS Note
2630340.

27
7 VALUABLE OSS NOTES

It is recommended that you are always on the latest support package/feature package level in order not to
miss out on the most important OSS notes respectively and to avoid additional effort during implementation
of the OSS notes.

Some of the most important Notes are outlined below:

Note Description
Number
2569950 FAQ: Migration & Operational Load in the SD Integration Component
2719185 The redesigned SD Revenue Recognition type "D" migration is now available
2702194 Validation for Proof of Delivery
2691932 "Proof of Delivery" creates Fulfillment Event
2711655 Call-Off Order creates Fulfillment Event
2567106 Documentation of data validation checks in revenue accounting and reporting
2580924 RAR GoLive preparation - additional checks
2725702 Operational load: FASB 52 migration redesign
2708516 RA FARR_INITIAL_LOAD_STATUS_API enhancement
2715378 Operational load: SD Revenue Recognition correction report redesign
2702035 Operational load: Correction revenue line deleted during RESET
2653276 Operational load: Open revenue lines are getting lost from the revenue
schedule
2677479 Operational load: LOAD and RESET of SD Revenue Recognition documents
deactivated in S4CORE systems
2703761 SD Integration Component: Important core changes not included in Add-On
REVRECSD
2591055 Functional limitations in the SD Integration Component
2766906 Operational load: SD RR migration check for completed revenue lines without
FI documents
2686351 Change message FARR_CONTRACT_MAIN 865 to customizable message

28
www.sap.com/contactsap

© 2018 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company .

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and serv ices are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this docume nt or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from e xpectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trade marks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/copyright for additional trademark information and notices.