100% found this document useful (1 vote)

101 views165 pages

SAP FI-RA Revenue Accounting Guide

The document is a practical guide to implementing SAP's Revenue Accounting and Reporting (FI-RA) system, specifically in relation to the ASC 606 accounting standard for revenue recognition. It outlines the legal basis, technical preparation, customization, and implementation processes necessary for effective revenue accounting within SAP. The book aims to provide a structured approach to understanding and applying the new regulations while highlighting the complexities involved in the transition to the new standard.

Uploaded by

rhzarate

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (1 vote)

101 views165 pages

SAP FI-RA Revenue Accounting Guide

Uploaded by

rhzarate

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

M.

Larry McKinney
Reinhard Müller
Frank Rothhaas

Practical Guide to SAP® FI-RA—Revenue

Accounting and Reporting
ISBN: 978-3-96012-674-4 (ePUB)
Translation Tracey Duffy
Cover Design: Philip Esch
Proofreading Lisa Jackson
Cover Photo: fotolia # 84034226 | Yabresse
Interior Design: Johann-Christian Hanke

All rights reserved

1st Edition 2017, Gleichen
© 2017 Espresso Tutorials GmbH
URL: [Link]
All rights reserved. Neither this publication nor any part of it may be copied or reproduced in
any form or by any means or translated into another language without the prior consent of
Espresso Tutorials GmbH, Zum Gelenberg 11, 37130 Gleichen, Germany.
Espresso Tutorials makes no warranties or representations with respect to the content hereof
and expressly disclaims any implied warranties of merchantability or fitness for any particular
purpose. Espresso Tutorials assumes no responsibility for any errors that may appear in this
publication
Feedback:
We greatly appreciate any kind of feedback you have concerning this book. Please mail us at
info@[Link].
Table of Contents
Cover
Title
Copyright / Imprint
Introduction
Motivation for this book
What the book cannot do
Our intention
1 Basic principles
1.1 Legal basis of ASC 606
1.2 Example of a contract with multiple components
2 Process and data flow
2.1 Impact of the standard on relevant SD business processes and applications
2.2 Impact of the standard on relevant PS business processes and applications
2.3 Data flow in the context of revenue accounting
3 Technical preparation
3.1 Installation
3.2 FI-RA versions
3.3 Basic customizing
3.4 Roles and authorizations
3.5 Development and data structures
4 Customizing in detail
4.1 Activation in the SD module
4.2 Revenue accounting contracts
4.3 Performance obligations
4.4 Fulfillment event types
4.5 Results Analysis
4.6 Postings
4.7 Further options for process control
4.8 Further control tables
5 Business Rules Framework (BRFplus)
5.1 Overview
5.2 Decision tables
5.3 Basic functions and navigation
5.4 BRFplus in the context of Revenue Accounting (FI-RA)
5.5 Other references
6 Example representation of business processes in the system
6.1 Service contract with retrospective invoicing
6.2 Bundle order with price allocation and right of return
7 Data consistency and reporting
7.1 Requirements and tools
7.2 Logistics and Revenue Accounting
7.3 Revenue Accounting and General Ledger
7.4 Revenue reports
8 Migration
8.1 Overview
8.2 Configuration settings
8.3 Operational load
8.4 Initial load
8.5 Items to consider
9 Transition
9.1 Transition process
9.2 Transition method
9.3 Transition execution
10 Implementation in practice
10.1 Timing
10.2 Challenges
10.3 Project content and structure
A Terminology explanations
B The authors
C Disclaimer
Thank you for purchasing this book from Espresso Tutorials!
Like a cup of espresso coffee, Espresso Tutorials SAP books are concise and effective. We
know that your time is valuable and we deliver information in a succinct and straightforward
manner. It only takes our readers a short amount of time to consume SAP concepts. Our books
are well recognized in the industry for leveraging tutorial-style instruction and videos to show
you step by step how to successfully work with SAP.

Check out our YouTube channel to watch our videos at

[Link]

If you are interested in SAP Finance and Controlling, join us at [Link]

[Link]/forum2/ to get your SAP questions answered and contribute to discussions.

For the subsequent implementation in SAP, we decided to present a strict chronological

sequence which begins with the installation and runs through the basic settings in customizing,
leading up to the details of individual application components and functions.

Using this knowledge as a basis, in the next step we use specific application examples to
illustrate the functionalities of the add-on along with the results that arise from the system
settings defined. We then round off by taking a look at aspects of data consistency and
presenting the relevant reporting. A final chapter then summarizes the findings and leads into an
outlook with the specific challenges, measures, and recommendations worthy of consideration
in realization projects.

This strict chronological sequence means that—particularly in Chapters 2 to 5—at some points
we refer to objects and processes and only address the details of these objects and processes
at a later point in the book. We chose this method deliberately to ensure that this tutorial can be
used as a technical guideline for specific implementation projects which, ultimately, follow the
same sequence.

In this context, we draw your attention to a further principle that we have based the
explanations in this book on: “A picture says more than a thousand words.” Therefore, the book
contains a number of images and SAP screenshots which should help you to prepare and
execute any future realization projects for implementing ASC 606.
What the book cannot do
This book should not be understood as a general compendium which covers all potential cases
that could occur in the light of ASC 606. Furthermore, it does not contain a complete and final
presentation of all functions and possibilities provided by the SAP Revenue Accounting and
Reporting add-on.

The book does not therefore replace the deep, specialist and/or technical training measures
and consultancy required. At this point, we again draw your attention explicitly to the fact that
the following topics—which, from a content perspective, are also connected to the new set of
rules stemming from the Financial Accounting Standards Board (FASB), and from a technical
perspective are connected to the SAP add-on—are either not presented or referred to in this
book or are only done so at a very superficial level:

Contract assets/contract liabilities

Deferral of costs
Down payments
Grouping of contracts
Compound performance obligations
Linking performance obligations
Fulfillment via percentage of completion
Our intention
Our aim is to present SAP’s basic realization concept for implementing the requirements from
ASC 606 to expert readers by means of an introductory overview based on the technical
implementation. We also use examples to illustrate our explanations. The book will enable users
to better assess the scope, the structure, and the resources required for a potential project for
implementing Revenue Accounting (FI-RA).

We have added a few icons to highlight important information. These include:

Tip

Tips highlight information concerning more details about the subject being
described and/or additional background information.

Example

Examples help illustrate a topic better by relating it to real world scenarios.

Warning

Warnings draw attention to information that you should be aware of when you
go through the examples from this book on your own.

Finally, a note concerning the copyright: All screenshots printed in this book are the copyright of
SAP SE. All rights are reserved by SAP SE. Copyright pertains to all SAP images in this
publication. For simplification, we will not mention this specifically underneath every screenshot.
1 Basic principles
Which basic legal principles will determine the reporting of revenues in the balance
sheet and profit and loss statement in the future and what are the resulting technical
challenges which arise for which industries, companies, and customer contracts?
1.1 Legal basis of ASC 606

1.1.1 History
With Revenue Accounting and Reporting (FI-RA), SAP is offering its customers an add-on in the
form of a dedicated subledger for revenue accounting. This subledger will allow customers to
map the requirements that come from the Financial Accounting Standards Board (FASB) as
Accounting Standards Codification topic 606 or ASC 606 – Revenue from Contracts with
Customers. This standard is a fundamental new regulation which addresses when and in what
amounts revenues and related expenses from customer contracts must be reported in the profit
and loss statement and, via appropriate deferral items, in the balance sheet.

The FASB published the standard in May 2014. It was developed—together with the
International Accounting Standards Board (IASB)—over a number of years and is intended to
replace some of the existing rules for revenue recognition. These include the previous
standards and interpretations on revenue recording (ASC 605 – Revenue Recognition) as well
as some FASB guidance and interpretations of special problems.

The aim of this process was to bring together various provisions on revenue recognition which
were previously regulated only in part and in diverse applicable regulations so that in the future,
there is only one extensive standard that is valid across all industries. As part of this process,
the intention was to standardize the previous rules from both standardization bodies and to
eliminate any inconsistencies that existed.

For companies with a capital market focus that produce financial statements according to US
GAAP, for the first time, the standard is binding for financial statements for fiscal years
beginning on or after January 1, 2018, whereby earlier application is permitted but must be
noted accordingly in the financial statements.

Figure 1.1 shows the main milestones in the development process for this regulation.
Figure 1.1: Milestones in the creation of ASC 606

1.1.2 Basic principle

ASC 606 is based on a five-level framework model. According to this model, a company must
record revenues in the amount for which consideration can be expected for the performance
obligations agreed with the customer and regulated in a contract.

In particular, the model states that a company must report sales revenue in the financial
statements at the time of the transfer of control over goods or services from the company to
the customer in an amount which reflects the consideration to which the company expects to be
entitled. This is determined in five steps:

1. Identify the contract with the customer

2. Identify the separate performance obligations in the contract
3. Determine the transaction price
4. Allocate the transaction price to the separate performance obligations in the contract
5. Recognize revenue when (or as) a performance obligation is fulfilled

Each of the steps stated briefly here (see Figure 1.2) is described in precise detail in this book
to clearly distinguish the scope of validity and application of the standard and to prevent
misunderstandings with regard to the regulations they contain.
Figure 1.2: Five-level evaluation model according to ASC 606

According to this model, a customer contract (1) exists under the following conditions: when all
relevant parties agree to a contract; the rights of each party in relation to the goods or services
which form the object of the contract and the related payment terms can be identified; the
contract has commercial substance; and it is probable that the agreed consideration can be
collected.

Within the meaning of ASC 606, a contract can in principle contain multiple performance
obligations. At the start of the contract, a company must assess the goods or services that
have been promised to the customer precisely and identify distinct, separate performance
obligations (2). This is done based on clearly distinguishable goods or services (or bundles of
goods or services) or a series of distinct goods or services that are substantially the same and
that have the same pattern in terms of the transfer to the customer (e.g., service agreements
with monthly recurring service packages).

For example, the sale of an analysis device and corresponding general control software
involves distinct performance obligations. The additional installation of the software detailed
individually in the customer contract, however, cannot be considered separate and would be
bundled with the software.
To determine the transaction price (3), reference is made to the consideration (i.e., the sales
price) defined in the contract which can be expected and legally claimed from the customer for
the transfer of goods or the provision of services.

If a contract covers multiple performance obligations, when the revenue is recorded, the
transaction price (4)—including any discounts granted—must be allocated to the individually
distinguished performance obligations in the ratio of the standalone selling prices. If standalone
selling prices cannot be determined, they must be estimated.

With regard to revenue recognition (5), the basis is the point in time at or the period in which
ownership of the asset passes to the customer and the customer can draw the benefit or
determine the further use of the asset.

1.1.3 Revenue recognition in SAP

The topic of ‘revenue recognition’ and along with it, the requirement for period-specific revenue
reporting, is (also) not new in SAP and was already covered in various areas before the current
regulation provided by ASC 606.

Companies that report according to US GAAP have already had to separate revenues based
on specific periods and thus recognize them in the posting period in which the service was
performed. In contrast, in German commercial law set down in the German Commercial Code
(HGB), for example, revenues and any associated expenses must be reported in the period in
which the invoice is issued.

This means that—using the revenue recognition functionality embedded in the application
components Sales and Distribution (SD), Financial Accounting (FI), and Controlling (CO) in SAP
—revenues are already separated and reported according to defined rules in order to separate
revenue recognition from the invoicing process in accordance with various methods common in
industry. This function allows revenues to be recognized in periods before, during, or after
invoicing based on criteria defined for the respective contracts or customer order items in SD.

Here, too, there are two alternatives:

Time-based revenue recognition: revenues are recognized in the same proportions

between certain dates
Performance-based revenue recognition: revenues are recognized based on events—for
example, a delivery or a percentage of completion

To enable period-based profit reporting, costs are posted based on periods together with the
revenue posting.

For the purpose of deferrals for the financial statements and to monitor billed and billable
revenues, two additional general ledger accounts are available. Receivables that have not been
billed (revenue has been recognized but not yet billed) and deferred revenues (revenue has
been billed but not yet recognized) are posted to these accounts.

For long-term production orders or customer projects, the SAP system also offers the partial
recognition of profit function based on the degree of progress of production or performance.
This revenue recognition according to the percentage of completion method calculates the
revenue per period from the ratio of actual to planned costs (= percentage of completion)
multiplied by the planned revenue. If the actual revenue (billed) is smaller than the calculated
revenue, a revenue in excess of billing is created which is then reported in the balance sheet as
an asset item. In contrast, if the (billed) actual revenue is greater than the calculated revenue, a
revenue surplus is capitalized in the balance sheet as a liability.

While the solutions currently offered by SAP are subject to a relatively rigid set of rules, the
Revenue Accounting and Reporting (FI-RA) add-on provides a tool which ensures that revenue
recognition is completely separated from the order entry and settlement systems.

The following factors make this possible:

The import of data in the form of orders, invoices, and events

A free categorization and conversion of the relevant data into performance obligations
Event handling according to own checks and rules
Transfer of the revenue-relevant postings into Financial Accounting (FI) via settlement
The unrestricted synchronization with the SAP modules (SD, FI, and CO)

In contrast to previous solutions, this toolbox for revenue accounting has an adapter framework
and thus offers the option of transferring and processing data from multiple SAP and non-SAP
systems.

The number of simulation options and reports for synchronization and the monitoring of revenue
recognition in interaction with the sales and distribution and general ledger processes also go
way beyond the previously available tools and applications. This is clearly shown in the
following introductory example.
1.2 Example of a contract with multiple components
To better illustrate the points discussed above, we will now outline the evaluation model
previously presented and the resulting requirements using a business transaction from the
telecommunications services industry—a sector in which most contracts are multicomponent
contracts. Offers usually contain certain telecommunications services, such as the provision of
telephone, data, or added value services paired with the sale or the provision of end devices in
the form of cell phones, network routers, or other transmission units. These devices are
generally heavily discounted in order to tie customers in and also to achieve competitive
advantages in a market that is at the mercy of the laws of the network economy.

Cell phone contract with an end device

In our extremely simplified example, when taking out a cell phone contract for a
term of two years and a monthly fee of $20.00, a customer is offered a high-
quality end device at a one-time price of $20.00. This is far below the
standalone selling price of the device, which, without a contract, would be
$200.00.

According to current accounting standards, the accounting representation of this contract is

relatively simple: the sales price of $20.00 for the end device is recorded as revenue
immediately, whereas the monthly fee of $20.00 over a term of two years must be documented
in the profit and loss statement as sales revenue at monthly intervals.

According to the ASC 606 evaluation approach, in the future, the first step must be to
separate the different performance obligations in the contracts. For our example, this means
that the performance obligations of firstly the telecommunications services and secondly the
end device must be separated and evaluated at the respective standalone selling prices.

The next step is to determine the contractual consideration (the transaction price). This is the
total of the (discounted) end device price and the recurring monthly fee.

This transaction price must now be distributed over the different performance obligations based
on the ratio of the standalone selling prices.

This results in the following representation:

1. The total transaction price of the contract of $500.00 ($20.00 for the end device plus 24
months x $20.00) is distributed to the individual contract performance obligations in the ratio of
the relative standalone selling prices.
2. The ratio in which the two performance obligations are included in the total price depends
on the ratio between the standalone selling prices (SSP). In the example, we assume that the
service performance would be offered over 24 months (without a device) at an amount of
$400.00 (see Figure 1.3).

Figure 1.3: Allocation of the transaction price

This means that $180.56 is recognized directly in the month that the contract is concluded:
$166.67 ($500.00 x 33%) for the end device plus $13.89 for the service fee in the first month.

The remaining $319.45 is recorded over the following 23 periods, at $13.89 per month
($500.00 x 66% divided by 24 periods).

The allocated revenue in the ratio of the SSP of the end device (in our example, $166.67) is
recognized immediately even though at this point in time, the company has received only a
payment of $20.00. Due to the low relative standalone selling price of the basic fee for the term
of the contract (in our example 24 months), for the monthly payments of the basic fee of
$20.00, sales revenue of only $13.89 is recognized each month, although the company actually
receives $20.00 per month during this time.

The example outlined here can be represented in an SAP system using the FI-RA add-on as
follows (see Figure 1.4):

Figure 1.4: Cell phone contract in SD

At the beginning, there is a customer order in the SD module with two items. This order is to be
realized over a period of 24 months and contains a service to be performed (with a total value
of $480.00) and an end device to be provided (at a contract price of $20.00).

Figure 1.5: Cell phone contract in Revenue Accounting (FI-RA)

By transferring the data to the FI-RA module, a revenue accounting contract (RAC) (see Figure
1.5) with two performance obligations is generated from this sales document (see Figure 1.6).
Figure 1.6: Performance obligations from the contract

In the ALLOCATED AMOUNT column, the performance obligations already show the previously
described calculated allocation of the transaction price based on the standalone selling prices.

The first performance obligation (the enabling of telephone calls by the provider) is fulfilled by
the progress of time and, based on the last day of the current month, is already deemed to be
recognized. Therefore, the RECOGNIZED AMOUNT column shows the amount of $27.78. (The
summarized value of two periods is shown because the revenue schedule was calculated in the
second period of the contract term when the screenshot was taken).

The second performance obligation is fulfilled by the Post goods issue event for the end
device (see outbound delivery 00800000055 in Figure 1.7).

Figure 1.7: Goods issue for the cell phone device

Once the goods issue has been posted and transferred (fulfilment), the RECOGNIZED AMOUNT
column shows $166.67 for the second performance obligation (see Figure 1.8).

Figure 1.8: Recognized revenues from fulfillment

The transfer of the postings that now have to be undertaken in FI takes place in Revenue
Accounting (FI-RA) by means of a settlement run. Figure 1.9 shows the list of posting items
exported from FI-RA which arise in the first period for our example.
Figure 1.9: Posting document for recognized revenues

For a better overview, Figure 1.10 provides an account-based representation of the facts.

Figure 1.10: Accounting representation

Account 140090 is the offsetting account for all individual items that result from the
settlement of a contract and the account shows a balance of zero.
The two performance items fulfilled are now posted to account 800090 as recognized
revenue with the respective transaction price from the sales document. The allocation
effect that arises here is posted to account 800095 (separately for each item).
In the profit and loss statement, a balance of $180.56 is displayed as revenue (sales
revenue).
As the service and the device have not been billed yet in the example, the offsetting item
for the recognized revenue is capitalized in the balance sheet in account 159510/Unbilled
Receivables.

This example clearly shows that for multicomponent contracts, according to ASC 606,
recognized revenues must be separated from the actual payments and, where applicable,
brought forward. This is referred to as “separating the operational sales process from the
revenue recognition.”
Once we have first laid the basis for a technical understanding of the add-on in the next
chapters, in Chapter 6, we will look at two further examples in detail in the system. These
examples will cover a service contract with a delayed invoice and the sale of a bundle with the
right of return.
2 Process and data flow
In this chapter, we outline the general process flow for revenue recognition according to
ASC 606. We look at the data flow for creating and processing revenue accounting
contracts and performance obligations in detail and place the postings in context with
the recognized revenues in the SAP modules SD, PS, FI-RA, and FI-GL.
2.1 Impact of the standard on relevant SD business processes and applications
From the initial considerations so far, we could easily come to the conclusion that ASC 606 is a
pure accounting topic. However, the regulations of the standard have far greater effects on
contract management, on activities in the core of the sales and distribution processes, on
supporting processes with regard to the correct timing and content for balancing accounts, as
well as on further business key figures and the associated systems and applications (see
Figure 2.1).

Figure 2.1: Business processes

To get a complete view of the potential implications, we have to look at the following questions:

How strongly is the company’s business model affected by ASC 606?

How relevant is the standard to existing contracts with customers and what adjustments
have to be made to these contracts?
What is the impact on the business activity of the company with regard to the future offer
portfolio (bundles, multicomponent contracts, delivery and service agreements, as well as
payment agreements with customers)?
Which sales processes are affected by the impact and how much adjustment is necessary
(returns processing, warranties, buy-back agreements, financing components, customer
payments)?
Which support processes—especially with regard to company and group reporting—are
affected by the changes (in particular, financial statements, sales key figures, and
budgeting)?
How much adjustment is necessary for applications and systems that support the
processes affected?
To what extent are personnel processes and agreements affected (check for any required
contract adjustments with regard to existing and future profit-based bonus agreements)?

At this point, it becomes particularly clear that contract, sales, and distribution processes
(including the underlying systems and applications) have to be analyzed and, where applicable,
redefined in terms of the extensive separation of operational activities from accounting and
revenue recognition.

At the same time, when implementing the requirements, it is essential to make sure that in the
future, more detailed information from these processes will be made accessible to the
accounting process and the creation of the financial statements. What we can conclude from
this is explained at the end of the book in Section 10.2.
2.2 Impact of the standard on relevant PS business processes and applications
Just as we have discussed the standard SD business process flow, the PS-based process
flows are also potentially impacted. In a typical scenario, for example Milestone Billing, we
would now need to make sure that those are captured and allocated against other items
associated with the project. One option would be to link the WBS to an SD sales order line
item. Notwithstanding the execution, the underlying revenue requirement is there.

There are also scenarios around resource-related billing and how it would flow through to
Revenue Accounting (FI-RA). There is the option, through configuration, to create an RA
contract from the invoice generated from resource-related billing. There are also options to
create a custom RAI class referencing WBS elements.

Regardless of the technical solution, the point that should be emphasized is how does the new
revenue standard impact my current business processes? In analyzing that question, you will
need to consider what business process changes are required to meet the new standard and
how they can be implemented in the most efficient and expedient way.
2.3 Data flow in the context of revenue accounting
To begin our look at the technical treatment of data for this topic, we will use the following
example of the data flow for a standard order (or customer contract) in SD, and in particular, in
combination with the creation and processing of revenue accounting contracts (see Figure 2.2).
The symbols used in the illustration each represent the objects and results from the relevant
modules SD, FI-RA, and FI-GL.

We will address details with regard to the installation and the process control settings, as well
as further examples from practice, with reference to a system in the following chapters.

Figure 2.2: Data flow (contract and delivery)

When Revenue Accounting (FI-RA) is activated, depending on the type of order and the
types of items used in the SD document, initially a transfer area for the required data is filled:
this is the adapter reuse layer (ARL). In this transfer area, order and contract items, as well as
fulfillment and invoice items are separated into categories which, from a technical perspective,
are kept in separate classes. Therefore, the standard order created is first put into the class
for order items. The revenue accounting items themselves have different statuses depending on
the degree of processing (Raw, Processable, Processed).
The data from the transfer area is processed further using transfer programs which are
integrated in dialog or in periodically executable batch processing cycles.

As a result of the data processing, a separate revenue accounting contract with

corresponding performance obligations is created in the system.
The detailed characteristics of the contract and performance obligations, which at a later point
become separate postings, are first determined from the customizing settings or are derived
using rules defined from the BRFplus application via decision tables. The procedure and control
parameters used here are described in detail in Section 5.4.

A complete integration of Revenue Accounting (FI-RA) with the SD module is guaranteed by the
fact that, within the process described, changes (e.g., prices, deadlines, and extensions) made
in an SD document after a successful transfer each lead to the revenue accounting contract
created being updated.

As mentioned before, a performance obligation in a revenue accounting contract reflects a

service previously agreed with the customer and recorded in an SD document taking revenue
aspects into account. A revenue posting is subsequently triggered based on the parameters
defined in the performance obligation. Various types of fulfillment can trigger this posting, such
as the delivery or the goods issue for a contract. In principle, the following triggering events are
differentiated in the system:

Time-based
Event-based
Progress-based (percentage of completion)

In SD itself, the delivery (an event) triggers the creation of a goods issue, which in FI, leads to
a stock change posting.

This event is also updated directly in the class for fulfillment items in Revenue Accounting
(FI-RA) as information with the descriptive parameters. The related performance obligation is
also updated in the revenue accounting contract the next time the periodic transfer programs
are executed. A corresponding indicator shows the service agreed with the customer has been
fulfilled and that, in accordance with US GAAP, recognized revenue must be reported.
A settlement transaction is then used to create the corresponding posting documents in FI.
Because the goods issue for the contract takes place before the invoice is issued, the
recognized revenue has to be deferred (capitalized) in FI for the balance sheet in an account
“Unbilled Receivables”. The additional account assignments derived from the original SD
document, such as the profit center or the defined profitability analysis characteristics, are also
adopted in the accounting document.
Situations in which the invoice is issued before the actual performance is delivered (e.g., within
the scope of a service contract for which invoices are issued quarterly at the beginning of the
performance period) are treated in the same way. In these cases, according to ASC 606, the
revenue already reported in the profit and loss statement must be reversed and the
corresponding revenue surplus shown as a liability in the balance sheet. This information is also
derived periodically (monthly) from the performance obligation parameters and posted to FI via
settlement.

In our example, as soon as the outgoing invoice is created in SD (see Figure 2.3), the
invoice transfer to accounting triggers the posting of the customer receivable against sales
revenue in the profit and loss statement.
When the relevant data is transferred to Revenue Accounting (FI-RA), the performance
obligation is updated accordingly via the class of the invoice items: the performance obligation
is no longer simply fulfilled, but has also been invoiced (via the SD module).

Figure 2.3: Data flow (billing document)

At this point, the revenue is reported twice in accounting: once via the SD billing document and
once via the posting of the recognized revenue from the settlement of the revenue accounting
contract in a prior period.

A posting which reverses the recognized revenue from a prior period in the current
settlement period is not created until the next periodic settlement takes place according to the
invoiced status of the performance obligation.
3 Technical preparation
In this chapter, you become familiar with the basic steps and activities required to
implement the Revenue Accounting and Reporting (FI-RA) business add-on in an SAP
ERP 6.0 system so that it can be technically executed.
3.1 Installation
The SAP module Revenue Accounting and Reporting (FI-RA) supplements the standard ERP
system as an add-on with the following two software packages:

REVREC 100: contains the functional part of Revenue Accounting (FI-RA)

REVRECSD 100: contains the integration of documents from the SAP module SD into
Revenue Accounting (FI-RA)

The basic installation of the enhancement (which can be acquired via the download area in SAP
Service Marketplace) is as Release 1.2 with Service Package 01.

You can then install both parts of the software with transaction SAINT (Figure 3.1).

Figure 3.1: Transaction SAINT

Before you perform the actual installation, SAP recommends that you check certain
prerequisites and, where necessary, import the SAP Notes listed below:

SAP Note 1960535: SD Core Changes for the Integration with Revenue Accounting and
Reporting
SAP Note 2025378: Profitability Object Number Missing for Order Item
SAP Note 1992006: CO-PA Activation for Add-On “Revenue Accounting and Reporting”

SAP composite note for Revenue Accounting (FI-RA)

SAP Note 1987012 contains a very useful summary of the prerequisites,

procedures, and release strategy for the Revenue Accounting and Reporting
(FI-RA) module.

Several support packages have already been released since the add-on was published:

SAP Revenue Accounting 1.0:

SP01 09/2014
SP02 10/2014
SP03 03/2015
SP04 06/2015
SP05 09/2015
SP06 12/2015
SP07 03/2016
SP08 06/2016
SP09 09/2016
SP10 12/2016
SP11 03/2017

SAP Revenue Accounting 1.1:

SP01 11/2015
SP02 12/2015
SP03 03/2016
SP04 06/2016
SP05 09/2016
SP06 12/2016
SP07 03/2017

SAP Revenue Accounting 1.2:

SP01 09/2016
SP02 11/2016
SP03 03/2017

SAP Revenue Accounting 1.3:

SP01 03/2017

Regenerating the classes after an update

After you have installed a support package, it is possible that no further data is
transferred to Revenue Accounting (FI-RA) from the SD module.
This is because the class for transferring the order items (see Section 3.3) is incorrectly
labeled as “inconsistent”.
Once you regenerate the class, the transfer will run again without any errors.
3.2 FI-RA versions
For the purpose of completeness, we will take a brief look at the version of RAR and the next
planned releases of the add-on with a (non-exhaustive) list of some enhancements.

Version 1.0 was made generally available in Q2/2015 and included the following:

Multiple element arrangement (MEA)

The ability to support multiple element arrangements (for example, the combination of a
cell phone and a wireless plan)
Multiple accounting principles
The ability to run revenue recogniton for multiple accounting principles. For example:
1. ASC 606 and IFRS 15 in the same system
2. ASC 605 and ASC 606 in the same system
3. ASC 605, ASC 606, and IFRS 15 in the same system
This allows for reporting in multiple accounting principles as well as parallel reporting for
financial statements.
SD order integration
Business Rules Framework Plus (BRFplus) was used for a rules-based engine to support
the creation of performance obligations (POBs)
Support for the creation of contract assets and contract liabilities per the new revenue
recognition guidance

Version 1.1 was made generally available in Q1/2016 and it includes the following:

Account determination
Account determination is also possible without reference accounts transferred from the SD
document.
Settlement run
The revenue is now posted in three completely separate and independent steps:
1. Calculation of the time-based revenues
2. Calculation of the contract liabilities and assets
3. Execution of the posting in a simulation or update run
The settlement run can now be executed as an update run for each customer contract or
as a simulation.
Migration
The complete company code does not have to be migrated; parts can be grouped in
migration packages.
Processing of return orders
Accounting of contract modifications for prospective changes
Archiving functionality was added
BRIM integration, including basic requirements for usage-based revenue recognition

Version 1.2 was made generally available in Q4/2016 and it includes the following:

Enhancement of the options for posting revenue to further CO objects (WBS element, SD
order)
Retrospective combination and grouping of revenue accounting contracts
Retrospective change in the fulfillment parameters with a posting correction
Direct closing of performance obligations in Revenue Accounting (FI-RA)
Enhancement of the options in the worklist for processing contracts
Integration of project-based revenue recognition using Project Systems (PS)
Calculation of the contract liabilities and assets not only at contract level but also at
performance obligation level
Option, in addition to posting recognized revenues, of also processing the related
(recognized) costs based on the fulfilled performance obligation
Customizing allows different levels of aggregation for the posting data in revenue
accounting documents

Version 1.3 is available in ramp-up from Q4/2016 with the following (non-exhaustive) list of
functional enhancements:

Foreign currency exchange processing based on IAS 21 and ASC 830

Various system performance optimizations
Transfer of future billing data based on milestone billing plans
Simplifications for high-volume invoice processing
End-to-end consistency checks
Enhancements around the inclusion of contract acquisitions costs
Improved supportability for inbound processing
Efficiency improvements for the migration process and around data migration activities

Version 1.4 is under development with the following (non-exhaustive) list of functional
enhancements:

Additional SD process support for:

1. Proof of delivery (POD)
2. Drop shipping
3. Stock in-transit
4. Customer acceptance date
Further support for disclosures
3.3 Basic customizing
In this section, we look at the technical data settings required to run Revenue Accounting (FI-
RA). You can find the details of the customizing for the process itself in Chapter 4.

You call up the path for the Revenue Accounting component (FI-RA) in customizing using
transaction FARR_IMG (Figure 3.2).

Figure 3.2: Customizing: revenue accounting items

The activity DEFINE INTERFACE COMPONENTS contains the reference to the program components
and the data structures required to transfer the data from the SD module (or external systems)
to Revenue Accounting (FI-RA).

In the transfer area (ARL) between Sales and Distribution (SD) and Revenue Accounting (FI-
RA), various items are categorized and reserved in separate classes from a program
perspective. When data is transferred from the SD module, no changes or additions are
necessary because SAP delivers a completely preconfigured interface area which you can use
directly to create classes. Figure 3.3 shows that we differentiate between three types of
classes.

Order item
Fulfillment item
Invoice item

You can assign names of your choice to the classes.

Figure 3.3: Classes: revenue accounting items

These classes describe and evaluate the data to be transferred to Revenue Accounting (FI-
RA).
For each type of class, you have to assign the interface components (delivered by SAP) which
specify the scope and content of the data to be transferred.

In Figure 3.4, this is shown for the Order Item class type by way of example.

Figure 3.4: Classes: interface components

The interface components that have to be activated depend on your specific system
environment. If, for example, you do not use Profitability Analysis (CO-PA) in your company,
you do not have to assign and activate the corresponding interface component.

For all objects in the SAP Data Dictionary, once you have defined them, you have to generate
them (Figure 3.5).

Figure 3.5: Classes: generation

Three data record statuses are possible when transferring data from SD (or external systems)
into the ARL:

Raw
Processable
Processed
Figure 3.6: Classes: upload rules

For each class, via the customizing entry ASSIGN UPLOAD RULES TO REVENUE ACCOUNTING ITEM
CLASSES, you define which status the new items receive on creation (see Figure 3.6).

Data can actually only be transferred to Revenue Accounting (FI-RA) (creation of or change to
revenue accounting contracts) for records with the status Processable.

Entries that still have the status Raw must therefore first be converted to the status
Processable. You can implement and define the supplied BAdI definitions below to perform
additional consistency checks, validations, and add data:

FARR_BADI_RAI0
FARR_BADI_RAI2

Figure 3.7 lists the database tables created during the generation of the classes dependent on
the class names, item types, and item statuses.

Figure 3.7: Classes: database tables

The table name always begins with the number 0 followed by the name of the class (e.g.,
SD01). The next number in the name differentiates between the statuses listed above: Raw (0),
Processable (2), and Processed (4). The differentiation CO and MI indicates whether it is
conditions or main items that are being transferred.
The activity DEFINE MODIFIABLE FIELDS FOR REVENUE ACCOUNTING ITEMS gives you the ability to
change the way RAI fields behave within the RAI Monitor. As the default, no fields are included
and thus no fields are modifiable. Through this activity, you have the option to make a field
modifiable, display only, or hide the field all together.

From the customizing area REVENUE ACCOUNTING ITEM MANAGEMENT (Figure 3.8), the screenshots
below show the assignment of the source systems for the data for revenue accounting
contracts as well as the menu item for differentiation and assignment of the different types of
source items from the source system.

Figure 3.8: Revenue accounting item management

The source item types shown in Figure 3.9 are already predefined in the basic delivery of the
add-on and aligned with the integration with the SD module.

Figure 3.9: Source item types

These types are also assigned to the defined class types. The type of the source item
(SRCITM T YPE field) is thus uniquely assigned to the files of the generated classes of the transfer
area.

Figure 3.10 shows the connection to the source system defined in the general customizing area
from which the SD data is transferred.

Figure 3.10: Logical system

While Figure 3.11 shows the necessary assignment of the logical system to the sender
component SD, Figure 3.12 shows the possible source item types from this source.
Figure 3.11: Assignment of the logical systems

Figure 3.12: Assignment of the source item types

By defining these settings, you create the basic technical prerequisites for transferring your
data from the source component SD to Revenue Accounting (FI-RA). For data to actually be
transferred to the adapter framework of the adapter reuse layer (ARL) (discussed in Section
2.3), you have to activate the transfer in customizing for the SD module (see Section 4.1).
3.4 Roles and authorizations
Roles are also delivered with the add-on (see Figure 3.13). These roles can be added to the
corresponding user accounts to effect clean coordination and strict division of labor within the
scope of revenue accounting.

The roles delivered include:

SAP_SR_FARR_REV_ACCOUNTANT
SAP_SR_FARR_REV_ADMIN
SAP_SR_FARR_REV_AUDITOR
SAP_SR_FARR_REV_MANAGER
SAP_SR_FARR_REV_RFCUSER

They are each formed either with only the relevant menu items or with the authorizations
required for the role function.

Figure 3.13: Roles in Revenue Accounting (FI-RA)

The roles are designed for use with the NetWeaver Business Client (NWBC), but can also be
used with the standard SAP GUI.

Figure 3.14 shows the authorization objects of the administrator role delivered by way of
example.

Figure 3.14: Revenue accounting authorization objects

As shown in Figure 3.15 and Figure 3.16, there are two authorization objects for adding and
changing items (F_RRRAI and F_RRRAIADM).
Figure 3.15: Authorization object for adding items

Figure 3.16: Authorization object for changing items

Note also the details of the authorizations for executing the settlement and the accrual run
(Figure 3.17) and for processing the revenue accounting contract (Figure 3.18).

Figure 3.17: Authorization object for settlement

For the settlement, you can select the company code and the accounting principle and the
activities display (03), simulate (10), and post (48) to restrict the selection.

Figure 3.18: Authorization object for the contract

You can restrict the contract itself to the company code and the sales organization. You can
also add, display, or change the status of contracts.

Prerequisite for customizing

Before you start the basic customizing, you must first assign the role
SAP_SR_FARR_REV_ADMIN to the processor responsible for this step as
otherwise this person will have no authorization for maintaining classes for the
data transfer.
3.5 Development and data structures
The development of the add-on for the complete integration of all business transactions relevant
for ASC 606 by SAP is no way near complete. For example, down payments and down
payment requests defined from a sales document which have to be reported as a contract
liability when due have not yet been incorporated.

Furthermore, in practice, there are a number of other company-specific processes and factors
that have not been taken into account due to the complexity of ASC 606. We can foresee that
these will probably result in a certain need for customer-specific enhancements. To enable you
to find the starting points for any necessary adjustments quickly, we include a short section as
an initial introduction to analyzing the technical implementation.

The development of the add-on is bundled in the package FARR. The integration between the
SD module and Revenue Accounting (FI-RA) which was originally contained in this package has
now been outsourced to package FARRIC_SD.

Transaction SE80 gives a good overview of the objects contained in the respective package
(and the subpackages).

Figure 3.19: Subpackages of the development package FARR

Figure 3.19 shows that corresponding subpackages are defined for the different structures and
flows within the entire module and the development is encapsulated in these subpackages.
Figure 3.20: Database tables for managing revenue accounting contracts

Figure 3.20 shows the database tables where the parameters of customizing for the revenue
accounting contracts and the contracts themselves and their definitions and characteristics are
stored.
Figure 3.21: Development package FARRIC_SD

The class CL_IMPL_FARR_SD_ORDER highlighted in Figure 3.21 (the class comes from the
development package FARRIC_SD, SD integration component) represents the program call
during processing of a sales order which initiates the transfer of the data to the transfer area
for Revenue Accounting (FI-RA).

You can enhance the existing functionality by adjusting the data structures (field enhancements)
and/or with additional logic in the processing steps.

Additional fields may be required for the following purposes:

Processing revenue accounting items

Use in revenue accounting contracts
(at performance obligation level)
Use for report requirements

The development of the module FI-RA is integrated in the SAP Easy Enhancement Workbench
(EEW) concept and therefore, you can integrate the enhancements for data elements quickly
and easily using extension include structures. The following structures are provided as
standard:

INCL_EEW_FARR_ARL
INCL_EEW_FARR_CONTRACT
INCL_EEW_FARR_POB
INCL_EEW_FARR_POSTING
INCL_EEW_FARR_REP
INCL_EEW_FARR_TRANSITION
INCL_EEW_FARRIC_SD01CO
INCL_EEW_FARRIC_SD01MI
INCL_EEW_FARRIC_SD02CO
INCL_EEW_FARRIC_SD02MI
INCL_EEW_FARRIC_SD03CO
INCL_EEW_FARRIC_SD03MI

These structures are already integrated in all affected tables and structures used internally,
meaning that any additional field added is automatically available in all relevant components.

For the adjustment options for the processing flows within Revenue Accounting (FI-RA), Figure
3.22 through Figure 3.25 list the enhancement spots and BAdI elements available in the
following process sections:
Integration of SD in the ARL
Enhancement spot: FARRIC_SD
Validation, transfer, and processing of the items
Enhancement spot: FARR_ARL (Figure 3.23)
Validation, definition of the contracts
Enhancement spots: (Figure 3.24)
Accrual posting run
Enhancement spot: FARR_ES_POSTING

Figure 3.22: Enhancement spots for SD integration

Figure 3.23: Enhancement spots for ARL

Figure 3.24: Enhancement spots for revenue accounting contracts

Figure 3.25: Enhancement spots for accrual postings

In this context, we refer to Figure 3.7 again, where the database tables of the ARL classes are
listed.

Table 7.1 also shows an overview of the corresponding tables in the ARL and in FI-RA.
4 Customizing in detail
By presenting various parameters in the customizing of the module FI-RA, we now want
to discuss important elements for activating Revenue Accounting and controlling the
processes within the module, with special attention given to the Business Rule
Framework Plus (BRFplus).

In addition to defining the customizing for creating, costing, and processing revenue accounting
contracts, you must first activate the transfer of the data from the sales area.
4.1 Activation in the SD module
When you install the SD integration component of the add-on, in customizing for Sales and
Distribution (SD), a new entry called REVENUE ACCOUNTING AND REPORTING appears (see Figure
4.1). You use this entry to activate and define further settings for the transfer of the SD data.

Figure 4.1: Customizing in SD

Setting the indicator REVENUE ACCOUNTING (see Figure 4.2) in the customizing activity INTEGRATE
WITH REVENUE ACCOUNTING establishes the connection between the technical SD processes and
the transfer of the data to the subledger FI-RA.

Figure 4.2: Activating Revenue Accounting (FI-RA) in SD

When you create or change sales documents (customer orders, outline agreements, deliveries,
etc.), the system runs through the revenue accounting algorithms and, based on the customizing
settings defined there, leads to the generation and modification of data objects.

You only have to enter a value in the DESTINATION field if you operate SD and Revenue
Accounting (FI-RA) on different SAP instances.

You define whether the item of an SD or outline agreement is to be deferred via a revenue
accounting contract in the customizing activity MAINTAIN REVENUE ACCOUNTING ITEM SETTINGS
dependent on the sales organization (SORG. column), sales document type (SAT Y column), and
item category (ITCA column). See Figure 4.3.

Figure 4.3: Activating item types in SD

A 1:1 relationship between the items of a sales document and the items reflected in a revenue
accounting contract is not necessary. The item type of certain items from the sales document
can be labeled as Not relevant.

Under certain circumstances—for example, using an external billing system—a billing document
is created without reference to an SD order. In this case, you can create a performance
obligation from the SD billing document using the customizing activity CREATE PERFORMANCE
OBLIGATION FOR SD BILLING ITEM . This customizing activity requires the sales organization (SORG.
column), billing type (BILLT column), item category (ITCA column), and set the revenue
accounting type (REVACC T YPE column). See Figure 4.4.

Figure 4.4: Create performance obligation for SD billing item

The customizing task INITIATE DATA CONSISTENCY CHECK provides a report which determines
whether errors or incomplete transfers have occurred during the asynchronous transfer of data
from SD to Revenue Accounting (FI-RA) within an order interval to be determined or from a
defined time (see Section 7.2.1).

You can call up the result of the report as an application log via transaction SLG1 using the
subobject CHECK_IC_DATA (see Figure 4.5).
Figure 4.5: Calling up the application log

Via the menu item EXECUTE OPERATIONAL LOAD (see Figure 4.1), you can start a program for the
initial transfer of existing sales documents to the adapter reuse layer which is presented in
detail in Section 8.1.
4.2 Revenue accounting contracts
Before we explain the details of the revenue accounting contracts, we first have to edit a couple
of settings for the integration with the FI module.

Figure 4.6 shows the corresponding path in customizing for all the activities to be performed.

Figure 4.6: Customizing for revenue accounting contracts

The first step is to execute the customizing task CONFIGURE ACCOUNTING PRINCIPLE-SPECIFIC
SETTINGS which defines how an accounting principle will behave (see Figure 4.7). For a given
accounting principle (ACCP column), you must determine how to post liability (POST LIAB. column)
either choosing Unbilled Receivables/Deferred Revenue, Contract
Liability/Contract Asset, or None. The contract modification (CONT. MOD. column) is
either checked to allow contract modifications or blank to not allow contract modification. The
cost recognition (COST RECOG column) is either checked to allow cost recognition within
Revenue Accounting (FI-RA) or blank to not allow cost recognition within Revenue Accounting
(FI-RA). There are certain costs that are handled by Results Analysis and not Revenue
Accounting (FI-RA) by design and will be presented in detail in Section 4.5. The post level (POST
LEVEL column) is used to determine at which level the aggregation is performed when updating
the posting table. The options are Post in Contract level or Post in POB level.
This setting can be changed, but only applies to contracts and performance obligations created
after the change occurred.

Figure 4.7: Customizing for Accounting Principles

Customizing task DEFINE MIGRATION PACKAGES gives you the ability to define a set of revenue
accounting data for a specific company code which can be migrated into revenue accounting
together. Migration packages allow you to migrate data in a more granular way.

In addition to the base accounting principle, you can define further rules and use them in
Revenue Accounting (FI-RA). For some reference transactions (e.g., account determination),
you can also add a general reference to the settings for the base accounting principle. Using
the assignments defined there, you can then find the corresponding entries.

The value area for the assignable rules results from the basic settings for Financial Accounting
(FI). Here, you define the different accounting principles (see Figure 4.8) and assign them to
the corresponding ledger groups of the New General Ledger (see Figure 4.9).

Figure 4.8: Accounting principles

Figure 4.9: Assigning the accounting principle to the ledger group

This means that different evaluations are possible within Revenue Accounting (FI-RA), as well
as parallel posting in different ledger groups. The ledger concept of the New General Ledger
for mapping parallel accounting is consistently taken into account here.

Figure 4.10 shows the method or basis used in the accounting principle for calculation. Figure
4.11 illustrates that the method can be activated separately for each company code.

Figure 4.10: Accounting principle calculation method

Figure 4.11: Activating the company code and transfer date

To obtain different categories of revenue accounting contracts, you can define contract
categories manually with separate number ranges (see Figure 4.12 and Figure 4.13).

Figure 4.12: Customizing: contract category

Figure 4.13: Defining a number range

You assign the contract category when you create it via decision table
DT_PROCESS_HEADER. In addition to the sales organization as shown in Figure 4.14, you
can also use all further attributes of the SD document as input parameters to differentiate
between contract categories. This allows you to use different contract categories as input
parameters for control purposes in the subsequent process flow (e.g., for account
determination).

Figure 4.14: Table DT_PROCESS_HEADER

4.3 Performance obligations
By differentiating between performance obligations using performance obligation types (POB
T YPE column) in customizing, you can standardize recurring transactions in advance by
assigning fulfillment and allocation data to them (see Figure 4.15). You can evaluate the
performance obligation types using this field in standard reports.

Figure 4.15: Performance obligation type description

When you create performance obligations manually in a revenue accounting contract, you refer
to the parameters defined in customizing, whereby you can adopt these as proposed values in
the items and then adjust them.

Customizing vs. decision table

If you transfer the raw data for a performance obligation using the program for
monitoring revenue accounting items (transaction FARR_RAI_MON) (see the
description in Section 6.1), all parameters for classifying the performance
obligation are derived from decision table DT_PROCESS_POB and not from
the customizing of the performance obligation type.

The FULFILLMENT DATA and ALLOCATION DATA areas (see Figure 4.16) contain the main attribute
groups for a performance obligation. Together with the predefined values, these parameters
are also available as target figures in decision table DT_PROCESS_POB.
Figure 4.16: Fulfillment and allocation data

From a content perspective, the fulfillment data determines the conditions under which a
performance obligation is deemed to be fulfilled and the revenue must thus be reported as
recognized.

The different types of fulfillment are:

Time-based
Event-based
Percentage of completion

Event-based types of fulfillment for a performance obligation require the definition of an event
type as a further mandatory characteristic. The following options are predefined:

Customer invoice
Delivery
Goods issue
Manual fulfillment
Proof of delivery

You can also define the following:

Type of start date

Duration
Deferral method

The fields for these values are only ready for input for time-based fulfillment. For details of the
values of the individual characteristics, see the context help for the respective field, which is
very informative.

In the ALLOCATION DATA area, you can exclude the allocation effect of the standalone selling price
on the transaction price for revenue recognition for the performance obligation (EXCL. FROM
ALLOC. field).

If you select this field, the allocated price for the performance obligation is taken from the
condition specified in the corresponding operational item and not adjusted.

If you want to define a fixed standalone selling price for the performance obligation type in
customizing, you can note this in the SSP field. Alternatively, the application in BRFplus provides
the decision table DT_PROCESS_SSP, which you can use to specify the standalone selling
price from different factors of the process that influence sales.

Furthermore, in this area of the screen, you can define percentage and absolute threshold
values for the deviation between the transaction price and standalone selling price. When these
values are adhered to, the allocation effect for revenue recognition is neither determined nor
reported.

Section 6.2 (Figure 6.34) contains an example of the determination of the allocation effect.

Allocating the standalone selling price

In addition to the two options presented for allocating the standalone selling
price, as a further variant, you have the option to transfer this price from the
SD order item or SD contract item via a separate condition type.

To do this, you include this condition type in the calculation procedure for the SD order and
evaluate it when the SD document is processed.

In customizing for Revenue Accounting (REVENUE ACCOUNTING • INBOUND PROCESSING • REVENUE

ACCOUNTING ITEM MANAGEMENT • DEFINE CONDITION T YPES FOR STANDALONE SELLING PRICE AND
RIGHT OF RETURN), you define the condition type as the source for the standalone selling
price and this is then adopted accordingly when you create the revenue accounting
contract.
4.4 Fulfillment event types
One way in which performance obligations are fulfilled is through the occurrence of a specific
event, such as a goods issue, proof of delivery, or receipt of an invoice.

You determine whether an event triggers fulfillment and which event type transmitted actually
causes a performance obligation to be deemed fulfilled and labeled as such when you create
the obligation, either via decision tables or manually by changing the contract.

You define this in customizing via REVENUE ACCOUNTING CONTRACTS • DEFINE FULFILLMENT EVENT
T YPES.

In this activity, you create or extend a list of all event types that the back-end logistics system
can send to Revenue Accounting (FI-RA) via the adapter reuse layer for fulfillment processing.

The following event types are already defined:

CI Customer invoice
DE Delivery
GI Goods issue
MA Manual fulfillment
PD Proof of delivery

These types are used when you transfer documents and process results from the SD module.

However, you can also define further event fulfillment types, such as the event type ZM
Milestone, shown in Figure 4.17, which you can then assign to a performance obligation as a
criterion.

Figure 4.17: Table of fulfillment event types

Triggered by a previously defined and (documented) achieved status in a logistics or CRM

system independent of SD, a fulfillment item with this type of fulfillment can be generated (e.g.,
using an IDoc) via the adapter reuse layer. This item then triggers the recognition of the
obligation with the corresponding accounting consequences during the transfer to Revenue
Accounting (FI-RA).
4.5 Results Analysis
Revenue Accounting (FI-RA) is integrated with Cost Object Controlling using Results Analysis
(RA). With this integration, you can transfer revenue that is calculated in Revenue Accounting
(FI-RA) for controlling objects which are then processed in Results Analysis. You can also
transfer the percentage of completion (PoC) to Revenue Accounting during Results Analysis.

The CO objects are account assignments in a sales order item. They are assigned to a results
analysis key and can be one of the following:

Work breakdown structure (WBS)

Sales order (SO) (make-to-order)
Internal order (IO)

Results analysis selects the actual and planned costs, as well as the revenues, which have
been posted on the controlling object and calculates the valuated revenues, the work in
progress, and the cost of sales, among other categories. The calculations depend on the
customizing of the valuation method in the results analysis. Settlement then settles these
calculated values, not the actual costs and revenues. Revenue Accounting (FI-RA) manages
revenues while Cost Object Controlling manages costs. It is not possible to do cost recognition
within revenue accounting in this scenario. Also, some revenues (for example revenues in
excess of billings or revenue surplus) will not be posted by Results Analysis in this integration
scenario.

The configuration steps for integrating Cost Object Controlling are listed in Figure 4.18.

Figure 4.18: Integration with Cost Object Controlling

When you perform the customizing activity ASSIGN RA VERSION AND CURRENCY T YPE TO COMPANY
CODE AND ACCT. PRINCIPLE, you maintain view V_TKKA_RR_AC using transaction SM30. There
are a few things you must keep in mind:

You cannot assign the same version to multiple accounting principles.

If you use an accounts approach, the revenue adjustment account of only one accounting
principle (which is the leading accounting principle) can be defined as the cost element
(except when business function FIN-CO-COGM is active).
If you use a ledger approach, only the revenue postings to the leading ledger update the
controlling object version 000 and the related Results Analysis version (except when
business function FIN-CO-COGM is active).
As results analysis will be updated during the Revenue Accounting posting run, you have to
assign the corresponding cost elements of the revenue corrections to line IDs using
category ‘R’. The activity prevents revenue corrections from being posted by the Results
Analysis.

When you perform the customizing activity SPECIFY RA KEYS AND RA VERSIONS THAT WILL INTEGRATE
WITH REVENUE ACCT., you maintain view V_TKKA_RR_ME using transaction SM30. There are a
few things you must keep in mind:

You can assign results analysis keys to a sales order item, an internal order, or to a work
breakdown structure element.
The performance obligation has two new attributes relating to the integration: the
integration method and the controlling object number.
In a work breakdown structure hierarchy, the results analysis key can be on an upper
element; the system searches the work breakdown structure hierarchy upwards until the
first results analysis key is found (the system checks whether it includes lower-level work
breakdown structure elements).
The special posting logic, according to project structure indicator ‘B’ (delta method) in the
valuation method of results analysis, is not supported.
4.6 Postings
Under the customizing node REVENUE ACCOUNTING POSTINGS (see Figure 4.19), you can predefine
various parameters for controlling the posting documents via posting run.

Figure 4.19: Customizing for revenue accounting postings

You use the posting specifications (see Figure 4.20) to assign the document type and posting
key on a company code-specific basis. Here, you can also specify standard account
assignment objects such as the segment, the profit center, and the functional area.

Figure 4.20: Document type and G/L account for settlement

If the maximum permitted number of line items (999) is exceeded when a settlement document
is created, the document is split. The respective offsetting items are posted to the G/L account
specified in this setting to ensure that the individual documents balance to zero.

Definition of the document type for document splitting

If you use the document splitting function of the New General Ledger in your
system, we recommend that you define a dedicated document splitting rule for
the selected document type. This ensures that the items of the additional
receivables accounts (e.g., unbilled receivables), which are defined as normal
balance sheet accounts (and not as a reconciliation account for customer receivables), are
split correctly.

The illustrations in Figure 4.21 and Figure 4.22 show a rule defined for the document type
SE via the business transaction and the variant. This rule allocates the line items of G/L
accounts with item category 01000 (balance sheet account) to separate line items from
account types 20000 (expense) and 30000 (revenue) in accordance with the account
assignment characteristics.

Figure 4.21: Splitting rule for the document type

Figure 4.22: Details of the splitting rule

The assignment of a tax code for non-taxable transactions is familiar from other areas of
Financial Accounting (FI). The postings created from Revenue Accounting (FI-RA) are not
relevant for sales tax. To ensure that postings with the required tax code are still possible to
accounts, however, you have to define a special code with a zero tax rate which is entered in
the line item in these cases.

The customizing entry for account determination (see Figure 4.23) groups all decision tables for
the determination of G/L accounts for the different categories of a settlement posting in an
overview. You can select and edit the individual tables (e.g., the reserved or recognized costs)
directly from the respective tab—meaning that you then do not have to call them up via the
BRFplus workbench.

Figure 4.23: Account determination

We will discuss the individual BRFplus tables for account determination in Section 5.4.

Defining new accounts

If you need new G/L accounts for the profit and loss statement as part of the
account determination, you have to define them as cost element type ‘revenue’
in CO because otherwise, the data will not be posted through to CO-PA. It is
particularly important to do this because when the posting is processed, no
information or error message is issued if, for example, the cost element type is wrong.
4.7 Further options for process control
We will look at two further interesting topics for process control:

Status and review reasons

Revenue accounting periods

In customizing, under REVENUE ACCOUNTING CONTRACTS, you will find the item DEFINE REVIEW
REASONS.

By defining a review reason (REVIEWREAS), you specify whether the performance obligation for a
contract should be reviewed (by a processor) (SET REVIEW) before further consideration and
whether the consideration for the determination and posting of the recognized revenues should
be suspended until the completion of the review (SUSREVPSTG) (see Figure 4.24).

Figure 4.24: Defining review reasons

The setting of the review reason with the aforementioned consequences is controlled via
decision table FARR_DT_POB_STATUS, which belongs to the BRFplus application named POB
Status Decision Table (see Figure 4.25).

Figure 4.25: Decision table FARR_DT_POB_STATUS

Using an editor, here you can define formulas and formulate conditions for the decision table of
the BRFplus application. When a condition is true, a corresponding status and one of the
previously defined review reasons are set.
Figure 4.26 shows an example of a formula which evaluates the transaction price. If the price is
changed or a threshold value of $10,000 is exceeded, the formula returns the Boolean value
True, which is queried in the conditions in the decision table.

Figure 4.26: Formula for a condition in the status management

The following statuses can be set:

R Pending review
I In progress
C Completed

On the detail screen for the performance obligation from a revenue accounting contract, the
pending review or the date of any review performed is displayed (see Figure 4.27).

Figure 4.27: Status data

To call up and process contracts labeled for review, you can use a separate WebDynpro
transaction via the menu for the Revenue Manager role (Figure 4.28).

Figure 4.28: Contracts with a pending review

In addition to the general posting periods used in SAP Financial Accounting (FI), there is a
separate control for opening and closing the revenue accounting periods in this subledger
accounting (see Figure 4.29).
Figure 4.29: Opening revenue accounting periods

Note that the initial period must be open in Financial Accounting (FI). Using the message control
settings, however, you can control whether a violation of this requirement leads to an error or
whether only a warning message is issued.

Transferring data from a legacy system

When transferring data from a legacy system, make sure that the revenue
accounting periods to be opened or closed are not chronologically before the
migration period. You should choose a period corresponding to the transfer
date of the migration data.

The reconciliation key for prior revenue accounting periods must be closed and all contract
liabilities and asset values must be calculated and posted.

The reconciliation key is created with every posting run for the settlement of revenue accounting
contracts and has a separate status which is only set to Closed when the postings have been
processed completely, that is, any errors that have occurred during the execution of a
settlement that has been started have been cleared. During the posting, the reconciliation key is
transferred to the header of the FI document from the settlement.
4.8 Further control tables
We have already referred to the following control and decision tables in the previous sections
and chapters:

Account determination
Header
Performance obligation attributes
Status management
Standalone selling price

At this point, we refer to further tables which are important for designing the revenue
accounting processes but which we address only briefly here:

DT_PROCESS_COMPOUND
Grouping materials for standardized use.
You can use this decision table to formulate conditions under which items from the sales
documents can be grouped hierarchically in Revenue Accounting (FI-RA) as a compound
performance obligation. The performance obligations bundled under this node are non-
distinct obligations. The higher-level (compound) obligation is only deemed fulfilled and the
assigned revenue recognized when all non-distinct lower-level obligations are fulfilled.
DT_PROCESS_DEFERRAL
Deferral parameters are dependent on the performance obligation name.
You can use these conditions to adjust parameters for controlling the different deferral
methods (e.g., reference basis for linear distribution). This table also controls the
conditions for determining and evaluating the right of return.
DT_PROCESS_POB_ADD
Linking performance obligations.
In Revenue Accounting (FI-RA), you can also create performance obligations which have
no reference to operational documents. You can assign these objects to a leading
performance obligation with a real equivalent in a sales document via table
DT_PROCESS_POB_ADD.
5 Business Rules Framework (BRFplus)
In Revenue Accounting (FI-RA), significant parts of the control are executed via applications
which are encapsulated in the BRFplus module. Therefore, we provide a brief introduction to
this area below.
5.1 Overview
The BRFplus application provides a standardized modeling and runtime environment for rules
for controlling the business processes from a business view. Thanks to a complete integration
in the system architecture of the web-based platform SAP NetWeaver, there is full access to all
objects in the SAP Data Dictionary (e.g., customer, material, invoice, etc.). This direct access
allows you to consider and model rules consistently from a business perspective rather than
from a technical perspective.

As part of this modeling, you can define data objects (elements, structures, tables) and
functions that relate to these objects. Via corresponding expressions, formulas, and sets of
rules, you can define and output results values based on input parameters to be transferred.
5.2 Decision tables
Decision tables are a significant element in BRFplus applications. They evaluate variable input
parameters of the process context (e.g., G/L accounts or other attributes of the contracts and
performance obligations) and then return derived results to the processing. These tables are
integrated in the customizing area and have to be defined for control purposes.

All of the named BRFplus elements are grouped in separate applications and you can enhance
and adjust them flexibly within this group. An encapsulated program code is created based on a
consistent definition and activation of the objects.

Via different methods, for example, enhancements, you can then integrate the complete
application or parts thereof in the programs which control a business process.

The basic design of a BRFplus application and integrating it in a processing process can be
seen as typical development tasks, whereas the maintenance (and enhancement) of the
application—and in particular, the definition of the set of rules—can also be performed by
technically skilled professional users.

SAP already provides some templates for Revenue Accounting (FI-RA) and you can integrate
and define them directly. However, during the implementation of the solution, you can also
develop and assign customer-specific additions and enhancements, taking naming conventions
into account.
5.3 Basic functions and navigation
You can call up the workbench for maintaining applications for the business rules with
transaction BRF+, which starts the web browser.

Figure 5.1: BRFplus workbench

In Figure 5.1, the navigation area of the workbench is shown on the left-hand side . There,
the applications are listed in hierarchical order with their objects and the where-used list. The
right-hand side of the screen shows the details for the object selected—here with the
example of decision table DT_PROCESS_POB.

You can change the structures or conditions of an object directly in the workbench once you
have switched the object to editing mode .

Activation necessary

You can save the objects once you have changed them, but the desired control effect in the
process only comes into force once you have activated the objects.

By switching to editing mode, you have access to the usual options for editing
table content: insert, delete, edit, copy, and change the order (see the
corresponding icons in Figure 5.2).
Figure 5.2: Editing options for table entries

Because the entries in the decision tables are processed in sequence and the value assignment
ends as soon as a valid condition combination is found, you have to enter the specific conditions
at the beginning of the table and the general conditions at the end of the list.

Figure 5.3: Row editor for defining the table fields

Highlighting and selecting a table row for editing calls up the ROW EDITOR shown in Figure 5.3.
You can use this editor to edit all condition (if) and result (then) fields. Because all the objects
are defined and anchored in the SAP Data Dictionary, any value assignments are checked
when you enter them and you can determine them via the input help.

The next section looks at some functions, decision tables, and rules for controlling processes in
Revenue Accounting (FI-RA) in detail. Corresponding screenshots give you a deeper insight into
working with the workbench and the BRFplus objects.
5.4 BRFplus in the context of Revenue Accounting (FI-RA)

Process control
In the first step in customizing for Revenue Accounting (FI-RA), you select and assign the
BRFplus applications for controlling and maintaining the transfer structure (see Figure 5.4).

Figure 5.4: Customizing for the BRFplus revenue accounting items

If you use SD as the feeder system for all classes, SAP recommends that you use the BRFplus
application FARR_AP_SD_PROCESS_TEMPLATE (see Figure 5.5).

Figure 5.5: Assigning the BRFplus application to the class

The following functions are grouped in this application; some of the functions are presented in
detail in the following sections:

FC_PROCESS_HEADER
(attributes for the contract header data)
FC_PROCESS_POB
(attributes for performance obligations)
FC_PROCESS_POB_ADD
(assign linked performance obligations)
FC_PROCESS_SSP
(assign standalone selling price)
FC_PROCESS_COMPOUND
(label nondistinct performance obligations)
FC_PROCESS_BOM
(distinct/nondistinct performance obligations from bills of materials)
FC_PROCESS_DEFERRAL
(special attributes for performance obligations)
FC_PROCESS_AGGR
(performance obligations from a billing plan)

You also have to define a data structure for the transfer of the data from SD to revenue
accounting (FI-RA). This structure defines which data is available for controlling the process in
BRFplus.

For this task, SAP provides the structure FARR_S_SD01_BRF, which you can use for all
classes and therefore in the entire process flow of a customer relationship for all transfers.
However, because you can also define the assignment of the structure for each class, you can
also provide different parameters via different structures of the BRFplus application (see Figure
5.6).

Figure 5.6: Assigning the BRFplus transfer structure to the class

This structure contains all of the elements listed below, which you can use later during modeling
and formulation of the conditions in the decision table:

Sender component source item

Logical system of the source item
Type of source document item
ID of the source item
Customer number
Business partner number
Company code
Business area
Profit center
Segment for segment reporting
Number for profitability segments (CO-PA)
Function area
Start date
End date
Accounting principle
Sales organization
Currency key
Revenue accounting item was changed
Begin date
Distribution channel
Division
Sales document item type
Material number
Plant
Sales document type
Sales document category
Material group
Storage location
Customer group

As well as assigning applications and structures in the import and transfer process, in
customizing, you also have to define the corresponding applications in the actual processing
process of the contracts and performance obligations in Revenue Accounting (FI-RA).

You define these settings in customizing under the following path: FINANCIAL ACCOUNTING (NEW) •
REVENUE ACCOUNTING • REVENUE ACCOUNTING CONTRACTS • ASSIGN BRFPLUS APPLICATIONS TO REVENUE
ACCOUNTING PROCESSES.

Using transaction FARR_IMG, you can also call up this node in customizing directly.

The two applications contained in the standard delivery for the account determination and the
status management for the contracts are:

FARR_ACC_DETERMINE_TEMPLATE
FARR_POB_STATUS_TEMPLATE

You can assign these to the rule categories (see Figure 5.7) accordingly.

Figure 5.7: BRFplus applications in the process

Account determination
The application FARR_ACC_DETERMINE_TEMPLATE encapsulates the following functions
which, depending on the company code and accounting principle, return the corresponding G/L
accounts which are subsequently posted to with the settlement run in the different process
steps:

FARR_PROCESS_DF_REV
Account Determination: Deferred Revenue
FARR_PROCESS_RC_REV
Account Determination: Recognized Revenue
FARR_PROCESS_CORR
Account Determination: Revenue Adjustment for Allocation Effect
FARR_PROCESS_CORR_A
Account Determination:
Revenue Adjustment for Linked Performance Obligations
FARR_PROCESS_CT_AST
Account Determination: Contract Assets
FARR_PROCESS_CT_LIB
Account Determination: Contract Liabilities
FARR_PROCESS_DCOGS
Account Determination: Deferred Costs
FARR_PROCESS_RADJ
Account Determination: Receivables Adjustments
FARR_PROCESS_RC_CST
Account Determination: Recognized Costs
FARR_PROCESS_ROR
Account Determination: Right of Return
FARR_PROCESS_UB_REC
Unbilled Receivables

Within the functions, the system runs through a logic which—based on the data available in the
transfer structure—uses a decision table to return a result.

For example, in function FARR_PROCESS_RC_REV, the set of rules

FARR_RULESET_RC_REV is defined (see Figure 5.8).
Figure 5.8: BRFplus function FARR_PROCESS_RC_REV

After processing the decision table Recognized Revenue (Figure 5.9), this set of rules
makes an entry in the G/L ACCOUNT field in the processing structure.

Figure 5.9: BRFplus set of rules FARR_RULESET_RC_REV

The decision table contains condition (if) and result (then) columns. In Figure 5.10, based on the
IAS accounting principle and the company code, as well as independently from the revenue
account from the account determination for the SD billing document, a G/L account 800090 is
found to which the recognized revenues are posted.
Figure 5.10: BRFplus decision table for recognized revenue

Depending on the transfer structure used and after changing to editing mode via the settings for
the decision table, you can add and remove further condition columns (see Figure 5.11).
Figure 5.11: BRFplus table settings for recognized revenue
5.5 Other references
A thorough and extensive description of the entire BRFplus concept would go far beyond the
aims of this tutorial. Therefore, two references to more detailed information are given below.

BRFplus documentation

The following path refers to the SAP online documentation for BRFplus, via
which you can call up more extensive presentations on the topic:

ENTERPRISE MANAGEMENT • SAP ERP • 6.0 EHP6 • DESIGNING THE BUSINESS

FUNCTIONS.

BFRplus tutorial

For instructions on how to develop simple applications in BRFplus quickly and

independently so that you can familiarize yourself with the concept and its use,
see:

[Link]
6 Example representation of business
processes in the system
In this chapter, we present two complete examples of a process flow for processing
customer contracts, with special consideration of the valuation bases and postings
arising in FI and CO.
6.1 Service contract with retrospective invoicing
In this section, we will look at a service contract in Revenue Accounting (FI-RA) and, by way of
example, assume membership of a forum subject to charges, whereby the membership
contribution or the service fee is billed from the SD module retrospectively.

To do this, in SD we create a contract to which a billing plan is linked (see Figure 6.1 and
Figure 6.2). The relevant performance period extends over six months (07/01/2016 to
12/31/2016). The services provided in a period are billed at the end of the following month
(initial billing 08/31/2016). The monthly payment for the service (membership contribution) is
$25.00. In total, the contract value is $150.00.

Figure 6.1: Service contract in SD

Figure 6.2: Billing plan in SD contract

In customizing, the SD document type and item type of the sales contract are marked as
relevant for Revenue Accounting (FI-RA) (for details, see Figure 4.3)—we explained this in
Section 4.1. When you save the document in SD, the details are provided for the transfer to
Revenue Accounting (FI-RA).

Using transaction FARR_RAI_MON, call up the monitor for revenue accounting items, which
displays the data (including the status) to be transferred (see Figure 6.3).

Figure 6.3: Monitor for revenue accounting items

By selecting and processing the items, you transfer the data to a revenue accounting contract
with corresponding performance obligations. Figure 6.4 shows the corresponding log.
Figure 6.4: Processing of the revenue accounting items

You can call up the selection screen for displaying the contracts (see Figure 6.7) as a
WebDynpro application via the user menu for the revenue manager role (see Figure 6.5).

Figure 6.5: Contract management

Start the transaction to access the selection screen for the contract search shown in Figure
6.6. There you can search for the contract created using various criteria, including the ID of the
operational SD document. When you execute the search, the contract created by the system in
Revenue Accounting (FI-RA) is listed in the results list for further display or processing.
Figure 6.6: Contract selection screen

Figure 6.7: Contract results list

Click the number of the revenue accounting contract to display the details of the performance
obligation.

When you transfer the data, you can assign a separate name to the performance obligation (via
BRFplus decision table). In the GENERAL DATA area, you save details of the source and the
organizational assignments (see Figure 6.8).
Figure 6.8: Revenue accounting contract, general data

In the ALLOCATION DATA area, you save detailed information about the performance obligation
type. In our example, we do not have to consider any further descriptions. However, the screen
shows that you can assign further control characteristics to the obligation, such as an exclusion
of the price allocation or the value adjustment to the obligation based on a standalone selling
price to be considered (see Figure 6.9).

The values in the fields in this area of the screen can be set either via transfer of the data using
the set of rules from BRFplus or manually by adjusting the performance obligation in change
mode.

Figure 6.9: Revenue accounting contract, allocation data

The FULFILLMENT DATA area (Figure 6.10) contains the control information for the value-based
and time-based calculation of the subsequent deferral postings.

We have adopted this data from the contract (see Figure 6.1) but you can also adjust it
manually or using BRFplus rules.
Figure 6.10: Revenue accounting contract, fulfillment data

All of the account assignment destinations—derived from the objects in the SD contract—used
in the ERP system are linked with the performance obligation when the data is transferred
(Figure 6.11).

When the revenue and/or deferral is/are posted, this account assignment information is also
transferred to the accounting document.

Figure 6.11: Revenue accounting contract, account assignment data

The STATUS DATA area provides information about the processing status of the obligation at any
point in time (see Figure 6.12). The illustration also shows that for performance obligations,
there are corresponding validations (manual or via BRFplus rules) which can lead to
performance obligations being flagged, resulting in the creation of the deferral postings being
suppressed for these items.

For our example, the illustration shows that this obligation is being processed without any
errors, but that apart from the transfer (including billing plan), no further processing steps have
taken place.
Figure 6.12: Revenue accounting contract, status data

For every contract created in Revenue Accounting (FI-RA), the system also creates a revenue
schedule. Based on the current date, this plan lists the chronological sequence of any postings
already executed or still to be executed.

In our example, we called up the revenue schedule at the end of August 2016 (see Figure
6.13). At this point in time (and according to the underlying contract in SD), the agreed services
for the months of July and August had already been provided and the revenue of $50.00 thus
recognized. However, this revenue has not yet been posted in FI-RA, as you can see on the
right in the SUMMARY area.

Figure 6.13: Revenue accounting: revenue schedule overview

In the subsequent summary list display of the revenue plan, the individual periods are displayed
in the ACCOUNTING PERIOD column and the statuses of the periodic actual and target postings are
presented in total.

Contract processing
As part of the processing of a contract in Revenue Accounting (FI-RA), the
application includes options for executing account determination and for
contract processing itself.

For example, if the transfer leads to an incorrect or undesired assignment of

attributes to the revenue accounting contract, after changing the settings in the BRFplus
decision tables, you can derive the values again.

You post the recognized revenues via a revenue posting run, which you can also start from the
menu for the revenue manager role.

Figure 6.14: Revenue posting run

There, you can select various applications in the REVENUE POSTING RUN folder (see Figure 6.14).
In the following, we will use the transactions Post One Time and Posting Jobs Monitor.

In the results list that appears after you execute your selection for the one-time posting (Figure
6.15), the values and accounts to be posted are displayed in a simulation before the actual
posting. Note that the posting must be period-based, hence, for our example, the first run will
only simulate and subsequently post the outstanding posting for period 07. You also have to
enter the desired accounting principle. You can restrict the simulation to one or more contracts
or performance obligations.
Figure 6.15: Revenue posting simulation

The results list for the simulation shows a balance of a credit posting in the profit and loss
statement in account 800090 (which reflects the recognized revenues), and in the balance
sheet, account 159510 shows a debit item for an unbilled receivable because the actual billing
to the customer has not yet taken place.

The representation via accounts in Figure 6.16 gives a better overview.

Figure 6.16: Posting recognized revenue in the service contract

The offsetting item for the credit posting of $25.00 to the “Recognized revenue” account is
in the “Rec. adjustments” account.
Because billing has not taken place yet, an unbilled receivable is posted (also via the
adjustment account).
When you execute the settlement in posting mode, you cannot restrict by contract or obligation
(see Figure 6.17). The program always creates a summary document for all contracts which, in
this period, contain recognized revenues that have not yet been processed or changes that are
relevant for deferrals.

Figure 6.17: Revenue posting job

The postings to individual deferral accounts are also grouped and summarized for each
additional account assignment (e.g., profitability segment, profit center, etc.) for the different
contracts.

Therefore, the document thus created in Financial Accounting (FI) does not show any direct
reference to the underlying contract(s). The connection between the processing of a contract in
Revenue Accounting (FI-RA) and the resulting FI documents is ensured by special reports
which we will discuss in Section 7.3.

Each settlement run in Revenue Accounting (FI-RA) receives an individual reconciliation key
which, on the one hand is assigned to the contracts in Revenue Accounting (FI-RA) settled in
the run, and on the other hand, is adopted in the document header of the FI document. This
connection ensures the assignment for reporting.
Revenue posting run per contract

From Release 1.1, you can also restrict a settlement run in posting mode to an
individual contract and a reconciliation key is linked to each contract.

The settlement and posting themselves take place in one job in background processing.
Therefore, on the selection screen, under JOB DESCRIPTION, you have to enter a combination of
the name of the job and the posting date for the postings to be created (last day of the month).

Figure 6.18: Revenue posting jobs monitor

The REVENUE POSTING JOBS MONITOR lists all jobs placed in the past with the status of the
execution (see Figure 6.18) and job details (Figure 6.19).

Figure 6.19: Job details, document display

Via the POSTED DOCUMENTS tab, you can navigate directly to the FI posting document created
from the settlement (see Figure 6.20).
Figure 6.20: Posting document for recognized revenues

The document shows the values of the example contract used in this section. Each value-based
assignment or posting (here: recognized revenues in account 800090 and unbilled receivables in
account 159510) has an offsetting entry in the general adjustment account (here 140090). All
accounts are found via the decision tables of the set of rules in BRFplus.

Figure 6.21: Revenue accounting contract: revenue plan after posting of the recognized revenue

The settlement updates the revenue schedule of the contract accordingly. In addition to
recognized revenues of $50.00 for the entire analysis period, the plan also shows the related
posting (for period 07) of $25.00 (see Figure 6.21).

The recognized revenues are posted based solely on the performance fulfillment, independently
of the billing documents created from the SD document, although they are related to these
billing documents. This is because when the outgoing SD invoice is transferred, in FI, revenue is
also posted and reported in the profit and loss statement. Therefore, once the billing document
has been posted, the original posting of the recognized revenue from Revenue Accounting (FI-
RA) must be neutralized again.

After creating the billing document with transaction VF01 (see Figure 6.22) and the transfer to
the FI module, we can display the document flow of the specific contract example (see Figure
6.23).

Figure 6.22: Creating the outgoing invoice in SD

Figure 6.23: Document flow in the SD contract

In the document flow, after selecting the accounting document, click DISPLAY DOCUMENT to go
directly to the FI document (Figure 6.24). You can see the corresponding line items for the
customer receivable, the tax, and the revenue posting (posted to G/L account 800000) from the
transfer of the billing document.
Figure 6.24: Posting document for billed revenues

In comparison, and analog to creating or changing the SD contract, the SD invoice document
has created a data record (here, the invoice item) for transfer to Revenue Accounting (FI-RA)
(see Figure 6.25). To display and process this record, use transaction FARR_RAI_MON.

Figure 6.25: Monitor for billing items

Automating processing

You can automate the transfer of the data from the ARL to Revenue
Accounting (FI-RA) in two ways: the preferred way is to execute the program
of transaction FARR_RAI_MON with a variant as a periodic job in background
processing.

Alternatively, you can set the entry FARR_RAI_TEST in the parameters. In this case, the
data records are processed immediately.

Once the billing item has been transferred, the display of the revenue schedule is updated to
show the billing document (Figure 6.26).
Figure 6.26: Revenue accounting contract: revenue schedule after posting of the billed revenue

Overlapping posting from FI-RA and SD

At this point in time, the revenue is recorded twice in the profit and loss
statement: once through the deferral posting from Revenue Accounting (FI-RA)
and once through the billing document created from SD.

This (temporarily) incorrect representation is corrected with the next periodic settlement of
the revenue accounting contracts.
Therefore, this settlement run must always be integrated at a suitable point in the entire
billing and month-end closing process.

Figure 6.27 shows the posting lines created from the settlement for the current period (for the
example we have selected month 08) for the contract in question in the simulation.

Figure 6.27: Revenue posting run for the period, settlement #2

In this representation, the grouping of line items for the creation of the posting document is
again clear. If we look more closely, the debit and credit items balance out on all G/L accounts.

At the end of period 08, the recognized revenue must be posted for this period (because the
contractual service has been fulfilled for this section). At the same time, the recognized revenue
from the prior period 07 must be reversed because in the meantime, this service item has been
billed and the billing document transferred. The balance on the G/L account for unbilled
receivables (in the example, 159510, see Figure 6.16) does not change, however, as the
service performed from period 08 only leads to an outgoing invoice in the next period, period
09.

Let us look at the account representation for this settlement (Figure 6.28).

Figure 6.28: Posting recognized revenue in the service contract, settlement #2

The billing document is posted in the SD module as a result of the processing,

independently of Revenue Accounting (FI-RA).
With the settlement run for Revenue Accounting (FI-RA) in the second period, the
recognized revenue posted in the first period is reversed (because billing has taken place in the
meantime) and the revenue to be posted for the current period is recorded according to
accounting principles.
Figure 6.29 shows the FI document created in detail.
Figure 6.29: Document for the posting of the settlement run, settlement #2

Figure 6.30: Revenue plan update after settlement

In the display of the updated revenue schedule (see Figure 6.30), the status of the two periods
07 and 08 is now shown as a green square (at the reporting date in period 08). The revenue
proportions recognized at this date are posted and the outgoing invoice in period 08 is also
taken into consideration.
6.2 Bundle order with price allocation and right of return
In this section, we will look at the example of an order in which two products, each with their
own separate standalone selling price (SSP), are sold as a bundle. In the bundle, there is an
implicit price discount on both products which is neutralized in the calculation of the recognized
revenues. For the accessory part, referred to here as the supplement, there is also a right of
return (with a time limitation).

However, we will not present the complete process flow, merely the special features of this
example which deviate from the previous chapter.

The bundle contract is made up of a main product at a price of $140.00 and a supplement part
at a price of $28.00 (see Figure 6.31).

Figure 6.31: Bundle contract

Via decision table DT_PROCESS_SSP in the BRFplus application (see Figure 6.32), a
standalone selling price of $150.00 is assigned to the main product and a standalone selling
price of $35.00 to the supplement.
Figure 6.32: Table DT_PROCESS_SSP

When the SD order data is transferred to Revenue Accounting (FI-RA), the performance
obligations from the contract are assigned the values accordingly (see Figure 6.33).

Figure 6.33: Standalone selling price of the bundle components

In the performance obligations, the allocation effect of $3.78 is also shown, that is, the
difference between the recognized revenue to be posted and the transaction price of the sales
order item.

When the performance obligation of the supplement is fulfilled, it is not the original contract
value of $28.00 that has to be posted as recognized revenue, but rather the corrected amount
of $31.78 which takes account of the allocation effect.

We can trace the calculation of the allocation effect in the values displayed in the table in Figure
6.34.

Figure 6.34: Calculation of the allocation effect

The difference between the total of the contract prices and the standalone selling prices is -
$17.00. This value must be split according to the ratio of the standalone selling prices (not the
contract prices). In our example, this ratio is 81.08% to 18.92%.

We have to apply the difference amount at the line-item level determined in this way (-$13.78
and -$3.22) to the respective standalone selling price and this leads to recognized revenue of
$136.22 and $31.78. The allocation effect is thus a result of the difference between the
contract price and the revenue to be recognized.

Via decision table DT_PROCESS_DEFERRAL (see extract in Figure 6.35), we have also
assigned a right of return to the supplement. In our example, this right is limited to two months
and is evaluated with an average value (or rather, with an average probability of a claim) of
10%.
Figure 6.35: Table DT_PROCESS_DEFERRAL

This evaluated right of return for the supplement in the amount of $3.18 (the 10% is not applied
to the original contract price, but rather to the contract price as corrected by the allocation
effect) is also adopted in the details of the corresponding performance obligation when the
revenue accounting contract is created (see Figure 6.36).

Figure 6.36: Right of return in the performance obligation

In comparison with the example from Section 6.1, the fulfillment of the performance obligation
for this contract is determined based not on time but rather on an event: the goods issue for the
supplement part (see Figure 6.37).
Figure 6.37: Goods issue for the supplement

Once the data has been transferred to Revenue Accounting (FI-RA), the recognized revenue
(which is still to be posted) of $31.78—caused by the event—is visible both on the detail screen
of the performance obligation and in the revenue schedule for the contract (see Figure 6.38 and
Figure 6.39).

Figure 6.38: Recognized amount for the supplement

Figure 6.39: Revenue schedule

The revenue schedule shows two lines for the performance obligation for the supplement: the
recognized revenue of $31.78 to be posted as a result of the goods issue is split into a time-
based posting of $3.18, which corresponds to the value of the two-month right of return, and
the remaining amount of $28.60, the actual recognized revenue at this point in time.

The simulation of the settlement of the contract in this situation also shows the same result (see
Figure 6.40), whereby in the display, the net result of the revenue of $28.60 results from the
balance of the G/L accounts 800090, 800095, and 800091. To give a better overview, the
respective corrections for the assignment and the right of return are recorded on separate G/L
accounts.

Figure 6.40: Simulation (with posting) of the settlement after delivery of the supplement

Figure 6.41 shows the related account representation.

Figure 6.41: Account representation for the posting after the goods issue for the supplement

The revenue recognized by the fulfillment (goods issue) is posted via adjustment account
140090.
The correction of the transaction price (allocation effect) is recorded via a separate
account, 800095.
The right of return reduces the recognized revenue and is also recorded via a separate
account, 800091. The offsetting item is a liability.
Because billing has not taken place yet, the balanced recognized revenue is posted and
displayed as an unbilled receivable in account 159510.
The settlement previously represented in simulation mode is posted in the FI module in the next
step, as shown in Figure 6.42, with document number 100000319.

Figure 6.42: Posting document for settlement #1

In our example, we then arrange for the goods issue for the main product.

The resulting settlement simulation of the revenue contract determines the recognized revenue
for the main product in the amount of $140.00 and cancels the allocation effect (via the debit
posting in G/L account 800095) (see Figure 6.43).

In G/L account 159510, this results in a total debit balance of $164.82. ($136.22 from the
delivery of the main product and $28.60 from the delivery of the supplement). This corresponds
to the contract price of $168.00, reduced by the evaluated right of return of $3.18.
Figure 6.43: Simulation (without posting) of the settlement after delivery of the main product

In the account view, this simulation is represented as shown in Figure 6.44.

Figure 6.44: Account representation for the simulation of the posting after the goods issue for the main product

The recognized revenue for the main product would be posted.

Because the contract has been completely fulfilled, the allocation effect of the transaction
price would be neutralized.
Because no billing has taken place, the transaction price of the main product (cleared of
the allocation effect) would be added to the unbilled receivable as a delta.
Once the second product has been delivered, an outgoing billing document is created for the
SD contract and transferred to Revenue Accounting (FI-RA), in addition to the standard posting
in FI-GL.

The overview in Figure 6.45 shows the simulation of the settlement of the contract again. In this
illustration, note that the changes relate only to the first settlement because the second,
simulated settlement after delivery of the main product has not been posted.
Figure 6.45: Simulation (with posting) for settlement #3

The first two lines show the recognized revenue from the delivery of the main product which has
not been posted yet. The two subsequent lines correct the allocation effect.

As both products are actually billed from SD and recorded in the profit and loss statement with
the total revenue from the contract in the amount of $168.00, the recognized revenues posted
to G/L account 800090 (in lines 5 to 8) are canceled.

Because the contract is now fulfilled and the full amount of $168.00 is reported as a receivable,
the value of the right of return which is still to be considered is shown as a liability via provision
account 99010 (line 9).

Via the posting shown in line 11, G/L account 159510 is balanced to zero as the contract has
now been fulfilled completely and billed.

The amount of $28.60 in our example results from the delivery of the supplement because the
settlement of the subsequent delivery of the main product—as already mentioned—is merely
simulated and was not posted.

For the account representation for this step, see Figure 6.46.
Figure 6.46: Account representation for the posting after the billing document

The billing document is posted to the standard accounts for revenue and receivables.
The recognized (but not yet recorded) revenue for the main product is posted and the
allocation effect is neutralized.
The revenues of both products posted as recognized are reversed because billing has
taken place.
The optional exercise of the right of return is deferred.
The posting of the unbilled receivable from the first settlement in this example is canceled.
For the purpose of completeness, Figure 6.47 shows the corresponding posting document in
FI.
Figure 6.47: Posting document for the settlement after billing of both deliveries

In the case shown, the duration of the right of return is limited to two months. Once this period
has expired, the corrections of the revenue by this evaluated right, including the deferral posted,
must be reversed.

Figure 6.48 shows the simulation of this cancellation through the settlement in the second
follow-on period.

Figure 6.48: Simulation (without posting) for settlement #4

The order is now fully completed: a receivable in the amount of $199.92 with opposing sales
revenues of $168.00 and a tax posting of $31.92 (split into two financial documents). See
Figure 6.49.
Figure 6.49: FI document for the invoice

All other G/L accounts affected as part of the settlement from Revenue Accounting (FI-RA)
from this business transaction now balance to zero, as we can see in the summary account
representation in Figure 6.50.

Figure 6.50: Account representation of the posting after expiry of the right of return

Once the deadline for exercising the right of return has expired, the revenue correction is
canceled.

The liability is also reversed.

7 Data consistency and reporting
It must be possible to reconcile data and processing activities in Revenue Accounting
(FI-RA) with the postings in General Ledger Accounting (FI-GL) and Profitability Analysis
(CO-PA) as well as the source data from the SD module. In this chapter, we show you
the instruments that FI-RA provides for reconciliation and for reporting the transactions,
status, and data of the revenue accounting contracts in Revenue Accounting (FI-RA).
7.1 Requirements and tools
As data and postings to and from Revenue Accounting (FI-RA) are recorded and processed
across multiple modules via transfer and settlement, consistency checks are required. These
checks ensure that the individual processing steps have been processed completely and
correctly and that the different areas are synchronized. These types of reconciliations and
reports should be firmly anchored in the period-end closing.

The following must be checked:

The sales documents (contracts and invoices) from SD, including the number and status of
the items present in the transfer area (adapter reuse layer)
The items processed from the transfer area with the revenue accounting contracts and the
assigned performance obligations
The postings from the settlement of the revenue accounting contracts with the postings in
General Ledger (FI-GL) and Profitability Analysis (CO-PA)

Messages that arise from the processing of data in Revenue Accounting (FI-RA) or from check
and reorganization reports are logged in the SAP application log as standard. You can call up
this log using transaction SLG1.

The object FARR has the following subobjects which are used to group the messages:

ACCRUAL
Messages from the revenue accounting settlement run
CHECK_IC_DATA
Messages from the consistency check integration
CLEANUP
Reorganization messages
CONTR_MGMT
Messages from the creation of or changes to contracts
DATA_MIGRATION
Messages from the initial transfer
RAI_CHANGE
Messages from changes to the revenue accounting items
RAI_CREATE
Messages from the creation of revenue accounting items
RAI_GEN
Messages from the generation of classes
RAI_LOAD
Messages from the initial creation of items
RAI_PROCESS
Messages from the processing of items
RAI_RECON
Messages from the reconciliation
RAI_TRANSFER
Messages from the transfer of raw items
RECON_RAI_ENGINE
Messages from the reconciliation of items with revenue accounting contracts
7.2 Logistics and Revenue Accounting

7.2.1 Reconciling the transfer area

You can use transaction FARRIC_CHECK to start the program which checks whether the sales
documents created in the SD module have been transferred to the transfer area for Revenue
Accounting (FI-RA) and processed.

You can check the document flow for each sales organization, starting after a specific date or
alternatively, by entering a document number interval (see Figure 7.1). You can enter the
document number interval after selecting the BY SALES DOCUMENT radio button (see also Figure
7.5).

Figure 7.1: Selection screen of transaction FARRIC_CHECK

The execution of the program itself does not return any results in dialog; instead, for each run, it
creates an application log as shown in the example in Figure 7.2.

Figure 7.2: Application log

In detail, the following facts are checked and logged:

The item was transferred by the sender (SD).

The item was completely processed by the recipient (RAR).
An error was determined for a performance obligation created in Revenue Accounting (FI-
RA).
The item values in SD and Revenue Accounting (FI-RA) are different.
The condition type values are different.

Using transaction SLG1, you can call up and analyze the log file created. On the selection
screen for this transaction, in the OBJECT and SUBOBJECT fields, you have to enter the values
FARR and CHECK_IC_DATA (see Figure 7.3).
Figure 7.3: Application log selection screen

The result of the check shows, for example, that for contract 40000035, not all of the items
(here, a billing plan) have been completely transferred from the SD module to the transfer area
(see Figure 7.4).

Figure 7.4: Data consistency check results

Errors and deviations must be corrected using the standard processes.

If you run the report by selecting a document number interval, you can use the CHECK
SUBSEQUENT DOCUMENTS indicator to integrate the reconciliation with the documents for fulfillment
and invoices (see Figure 7.5).
Figure 7.5: FARRIC_CHECK with subsequent documents

7.2.2 SD and Revenue Accounting

For revenue accounting contracts and the related performance obligations, you can use
transaction FARR_RAI_RECON to check whether changes to the SD documents, fulfillment
documents, and invoices have been processed correctly.

In detail, the following factors are compared between Revenue Accounting (FI-RA) and SD:

Quantity and price per condition

Fulfillment quantity
Value of the billing document per condition

Figure 7.6 shows the selection screen of the transaction. The screen also offers some technical
options for optimizing the runtime of the transaction.

Figure 7.6: Selection screen of transaction FARR_RECON_RAI2E

If any deviations are determined, the results of the reconciliation are output at the performance
obligation level. Figure 7.7 shows the display for a run with no deviations and no errors.
Figure 7.7: Results of the consistency checks for processed revenue accounting items

The following are not checked during the program run:

Quantity in billing plans

Quantity in billing documents
Time-based performance obligations
Manual fulfillments

If any deviations are determined, use transaction FARR_RAI_MON in the monitor for revenue
accounting items to check whether there are any unprocessed documents in the ARL in the
corresponding period.

Furthermore, for the contract, fulfillment, and invoice data, at table level you can compare the
corresponding tables at the level of the adapter reuse layer (ARL) with FI-RA (see Table 7.1).

ARL FI-RA
Contract /1RA/0SD014CO FARR_D_DEFITEM
/1RA/0SD014MI FARR_D_POB
Fulfillment /1RA/0SD024MI FARR_D_FULFILLMT
Invoice /1RA/0SD034CO FARR_D_INVOICE
/1RA/0SD034MI FARR_D_DEFITEM
Table 7.1: Corresponding tables in ARL and FI-RA
7.3 Revenue Accounting and General Ledger
The reconciliation between Revenue Accounting (FI-RA) and General Ledger Accounting (FI-
GL) can be performed at both document level and account level.

7.3.1 Reconciliation at document level

You can call up the WebDynpro application FARR_RECON_FI_USER (FI Documents and
Revenue Accounting Contracts) from the menu of the Revenue Manager role (see Figure 7.8).

Figure 7.8: Revenue Manager role menu

On the selection screen, as well as entering the company code, fiscal year, and accounting
principle, you can also differentiate according to further criteria from Revenue Accounting (FI-
RA) (contract) or General Ledger Accounting (FI-GL) (document) (see Figure 7.9).

Figure 7.9: Document reconciliation selection screen

For the postings for each document in FI-GL, the results list of this report shows the underlying
base items of the performance obligations from the corresponding revenue accounting
contracts settled with this posting (see Figure 7.10).
Figure 7.10: Document reconciliation results list

This WebDynpro application is also helpful for analyzing the postings made in FI-GL. No
assignment information for the contract or for the performance obligation is transferred from FI-
RA into the document lines when the FI document is created as part of the settlement of the
contracts. This means that you can use this transaction to determine the details for the origins
of the posting.

7.3.2 Reconciliation at G/L account level

You also call up the WebDynpro application FARR_RECON_ACCOUNT_RA_GL (Reconciliation
of Accounts between Revenue Accounting and General Ledger Accounting) from the role menu
for the Revenue Manager, and doing so displays the selection screen shown in Figure 7.11.

Figure 7.11: Account reconciliation selection screen

The results list for the transaction (Figure 7.12) shows the balances of the G/L accounts posted
in Revenue Accounting (FI-RA) and in General Ledger Accounting (FI-GL) in the selected
period along with any differences found.
Figure 7.12: Account reconciliation results list

The values can be displayed in the report in document currency as well as in all defined local
currencies.
7.4 Revenue reports
The most important reports available as standard in the module FI-RA include:

Posted amount by contract

Disaggregation of revenue by customer
Posted amount by POB type

The corresponding WebDynpro applications are:

FARR_POSTED_AMOUNT_CONTRACT
FARR_DISAGGR_REVENUE_CUSTOMER
FARR_POSTED_AMOUNT_POB_TYPE

The selection screen of the report “Posted Amount by Contract” allows a restriction by contract
and customer (see Figure 7.13).

Figure 7.13: Selection screen for the report “Posted Amount by Contract”

For individual contracts with no entry of a customer reference, or for a contract bundle for one
or more customers, the amounts posted periodically from Revenue Accounting (FI-RA) can be
displayed. The presentation of the results list is structured by contract as standard (see Figure
7.14).

Figure 7.14: Results list for the report “Posted Amount by Contract”

In addition to the contract prices from the SD document, here you can compare all relevant
value fields transferred from the sales document as well as the values determined and posted
from the contract and from the performance obligations.
Figure 7.15: Results list for the report “Posted Amount by Contract” (continuation)

In Figure 7.15, we can see the report for the bundle contract example from Section 6.2. In this
representation, the DEFERRED REVENUE IN CONTRACT CURRENCY column contains the temporary
revenue corrections activated (for periods 08/2016 and 09/2016) which result from the
evaluated right of return.

No selection across multiple periods

Unfortunately, the results list for the report “Posted Amount by Contract” can
only be called up for one posting period at a time. The entry of multiple periods
is not supported.

Figure 7.16 shows the selection screen and Figure 7.17 the results list for the report
“Disaggregation of Revenue by Customer.”

Figure 7.16: Selection screen for the report “Disaggregation of Revenue by Customer”

Figure 7.17: Results list for the report “Disaggregation of Revenue by Customer”

You can call up the report “Posted Amount by POB Type” in the same way as the above-
mentioned reports. This report returns the corresponding values, structured by type of
performance obligation.

7.4.1 Extractors
Installing the add-on gives you access to the data sources listed below; you can use them to
define and generate reports in the Business Warehouse:
0FARR_CONTR_ATTR

Contract master data

0FARR_CONTR_CAT_TEXT

Contract category text

0FARR_DEF_S_IND_TEXT

POB special indicator text

0FARR_DIST_TYP_TEXT

Distinct type text

0FARR_EVT_TYPE_TEXT

Event type text

0FARR_FULFILL_TYPE_TEXT

Fulfillment type text

0FARR_OBJNR_ATTR

Revenue object attribute

0FARR_POB_ATTR

Performance obligation master record

0FARR_POB_ROLE_TEXT

Performance obligation role text

0FARR_POB_STAT_TEXT

Performance obligation status text

0FARR_POB_STAT_TEXT

Performance obligation status text

0FARR_POB_TYPE_TEXT

Performance obligation type text

0FARR_POST_CAT_TEXT

Posting category text

0FARR_RA_10

Posting item
0FARR_RA_20

Allocated price change

0FARR_RA_30

Revenue forecast
0FARR_RECKEY_ATTR

Reconciliation key
0FARR_RECKEY_STAT_TEXT

Reconciliation key status

0FARR_REV_RSN_TEXT

Review reason text

0FARR_ST_DAT_TYP_TEXT

Start date type text

0FARR_VAL_RES_TEXT

Validation result text

Activating some data sources, for example, 0FARR_RA_10, is also a prerequisite for running
the reports from the previous two sections.

7.4.2 Integrating Profitability Analysis

In this section, we explain how you can quickly and easily evaluate the data posted from
Revenue Accounting (FI-RA) to Profitability Analysis (CO-PA) based on the profitability
segments.

In the customizing path for Profitability Analysis (CO-PA), under the item INFORMATION SYSTEM ,
you can create and generate virtual info providers automatically for CO-PA for evaluation in the
Data Warehouse. Alternatively, you can use transaction KEIP.

For the operating concern used in the system, when you run the transaction, you can structure,
create, and generate virtual info providers for the account-based and costing-based versions as
an option (Figure 7.18). The traffic light display for the status indicates whether any errors
occurred during generation and whether the provider can be used as a basis for the
evaluations.

To evaluate the results data created from Revenue Accounting (FI-RA), in the following example
we use the costing-based form because the representation should be via the filtered
assignment of value fields.
Figure 7.18: Generating info providers

From the generation transaction, we can go directly to the modeling in the workbench of the
Business Warehouse (Figure 7.19).

These virtual info providers created are based on an API (application programming interface).
This means that in the reporting, there is an (always up-to-date) direct access to the data
without having to define and execute any special loading operations.

Figure 7.19: Info providers in the business warehouse

In the Business Explorer (BEx) Query Designer (Figure 7.20), we can initially use the
characteristics defined in the operating concern for selection and filtering.

In the example shown, we have selected the row and column presentation based on a
contribution margin structure for evaluating the revenues, with a breakdown by material and
article.
Figure 7.20: Query Designer work area

The row presentation REVENUE EVALUATION in Figure 7.21 is defined as a fixed structure in the
query, whereby the individual items represent either formulas or value fields which are
restricted using further characteristics derived from the individual postings.

Figure 7.21: Row presentation in the query

For the postings transferred from Revenue Accounting (FI-RA) to CO-PA, we recommend that
you always define your own value fields and assign them in customizing. Alternatively, for
example, you can filter the posted, recognized revenue via the reference transaction and thus
present the REVENUES value field in different ways in different rows in the report (Figure 7.21).
Figure 7.22: Example report for presenting the results

When you execute the query (Figure 7.22), all planned, recognized, and invoiced revenue
postings are displayed, as well as their corrections and allocation effects.
8 Migration
In this chapter, we present the tools relevant for Revenue Accounting (FI-RA) and the
procedure for a data migration. Furthermore, we demonstrate the many challenges—
beyond the use of a new SAP application—which result from ASC 606 with respect to
designing and restructuring business processes.
8.1 Overview
During the migration, the data for the existing open contracts in SD is technically transferred to
the new Revenue Accounting system.

When you install the FI-RA add-on, you have access to a program for an initial load for the
migration of data from SD. To load data from another operational application, you have to
develop a separate program for transferring data into the adapter reuse layer so that you can
perform the data processing described in this chapter.

We present the main technical aids and steps briefly below. SAP Help provides a good and
detailed description of the process with the respective prerequisites, limits, and dependencies
of the measures; therefore, we will not address this in more depth here.

The design, preparation, and testing of the technical migration must be seen as one separate
subproject because the old contracts transferred (but not yet closed), including their fulfillment
and billing documents, have to be completely closed and reconciled before you can start the
transfer of the new documents and the settlement of old and new contracts based on a key
date.

The overview of the operation load is shown in Figure 8.1.

Figure 8.1: Overview of migration to revenue accounting (FI-RA)

8.2 Configuration settings
First, we will look at the purely technical steps for preparing and executing the migration, before
evaluating the results of a successful transfer by way of example.

Figure 8.2 shows the customizing path used to identify the operational units as “in migration”
dependent on the company code and accounting principle.

Figure 8.2: Preparing the migration in customizing

If you set the status to Migration, you also have to specify the transfer date (see Figure
8.3). The transfer program then selects all sales and follow-on documents before this date. All
subsequently executed programs check for this status and terminate processing if it is not set.

Figure 8.3: Identifying the company code for migration

Migration status excludes current data from processing

If a company code is currently in migration, no transfers created from new SD

documents created are processed in the regular process.

Once you have completed all the transfers and reconciled the data, you have to set the
company code to the status Productive (Figure 8.4).

Figure 8.4: Completing the migration in customizing

The actual migration takes place in two steps: first, the SD documents (orders and contracts)
to be transferred and any follow-on documents (deliveries, goods issues, invoices) are selected
and loaded to the ARL. In a second step, these data records are processed, at which point the
program creates the revenue accounting contracts with performance obligations and
fulfillments.

The essential prerequisites for the second step are that customizing has been completed in full
and the decision tables have been defined as they are also required for productive use.
8.3 Operational load
Executing transaction FARRIC_OL (Operational Load) transfers the legacy data to the ARL.
Figure 8.5 shows the selection screen for this program. You can restrict the documents to be
transferred with the usual organizational criteria from SD.

You have to run the transaction with processing type Load. The data transferred is labeled in
the source and cannot be transferred again.

Figure 8.5: Selection screen of transaction FARRIC_OL

If you select the SYNCHRONOUS ONLINE PROCESSING checkbox for the transaction, the results log is
output in dialog (see Figure 8.6).
Figure 8.6: Log for the execution of FARRIC_OL

For a detailed analysis of the log and the messages created during creation of the ARL items,
you can evaluate the application log with transaction SLG1 for the object FARRIC and the
subobject OL for each class (Figure 8.7)

Figure 8.7: Evaluation of the OL application log for SD01

Operational loading in expert mode

Transaction FARRIC_OL_EXPERT allows further differentiating settings for the

transfer of the data to be migrated to the ARL.

The transaction allows you to explicitly include or exclude fulfillment data or

invoices.
8.4 Initial load
You create the actual contracts and performance obligations (including the selected fulfillment
data and invoices) in Revenue Accounting (FI-RA) using transaction
FARRIC_RAI_PROC_LOAD, which you can call up from the INITIAL LOAD menu (Figure 8.8).

Figure 8.8: Calling up the initial load

The selection screen for this transaction requires you to specify the characteristics for the
revenue accounting objects and you can run the transaction in dialog or in background mode as
an alternative (Figure 8.9).

Figure 8.9: Selection screen for the initial load

If you run the program in background mode, you can also evaluate the results from the
application log (transaction SLG1, object FARR, subobject RAI_TRANSFER).

Resetting the migration data

To delete the data selected and processed for the migration, you can use
report RFARR_IL_CLEANUP to clean up the database. This cleans up both the
ARL and the database tables in Revenue Accounting (FI-RA).

Resetting the sales documents

When you transfer the sales data to be migrated to the ARL, the data
transferred is also labeled in SD. This labeling is not reset by program
RFARR_IL_CLEANUP.

Therefore, you must first run transaction FARRIC_OL with the original selection criteria but
using processing type Reset so that the labeling is reset and these sales documents can
also be loaded operationally again.

We will now look at a simple example in the system for a better understanding of the individual
migration steps.

Migration to Revenue Accounting (FI-RA)

Figure 8.10 shows a standard order from SD with three items in March 2016.
In the example, the company code for this order should have the status
Migration with the migration date 03/31/2016.

Figure 8.10: Migration order in SD

In the example order, a delivery with a goods issue posting has already been recorded for the
first item in April, as you can see from the document flow for the order in Figure 8.11.

Figure 8.11: Migration order document flow

After executing transactions FARRIC_OL and FARR_RAI_PROC_LOAD described in this

chapter, a contract with three performance obligations has been created in Revenue Accounting
(FI-RA). See Figure 8.12.

For the sake of simplicity, we will not determine the allocation effect in this example.

Figure 8.12: Revenue accounting contract from migration

In Figure 8.13, the revenue plan for this contract also shows the three performance obligations,
the first of which is already marked as fulfilled. The inverted triangle in the STATUS column
symbolizes that this item had already been fulfilled before the migration date and no further
actions are necessary within Revenue Accounting (FI-RA).
Figure 8.13: Migration contract revenue plan

From the remaining two items which have not been fulfilled yet, sales of $450.00 are expected.

To continue the presentation of this example, in customizing, the status of the company code
has now been changed from Migration to Productive (Figure 8.14).

Figure 8.14: Status of the company code is “Productive”

Then, in the first period after the migration, the goods issue (4900000112 / 1) for item 20 of the
example order (see Figure 8.10) was posted, as shown in the updated document flow for the
order in Figure 8.15.
Figure 8.15: Updated migration order document flow

After the transfer of the fulfillment item created by the goods issue to Revenue Accounting (FI-
RA) (the steps for this were described in Section 6.1), the revenue plan for the corresponding
item is updated there.

Figure 8.16: Updated migration order revenue plan

From Figure 8.16, you can see that the performance obligation for the main product is fulfilled
and a recognized revenue of $300.00 is due for posting, but has not been posted yet.

In the posting simulation for this migrated contract, there is also the expected revenue posting
to the adjustment account against the balance sheet account “Unbilled Receivables” (see Figure
8.17).
Figure 8.17: Migration order posting simulation
8.5 Items to consider
The migration is a complicated process with many moving parts. It is best to coordinate the
migration with a month-end close as the process of month-end close may change the data.

You may want to use a prepared sales order list to facilitate error handling related to revenue
accounting items (RAIs) or if you have different business scenarios for migration or fulfillment.
This will also help mitigate migration and fulfillment being different versus non-migrated sales
orders.

Consider a black-out period for orders, deliveries, and billings as company code cleanup may
remove productive documents. You can control the timing of when productive RAIs are created
using table FARR_IT_REVTYP. You may consider activating item categories at the same time
you start your operational load.

You use program FARR_IL_CLEANUP at a company code or order level if you encounter an
error (for example the legacy data are not consistent or no RAIs are created). The prerequisite
is that the migration package is in status “migration.” You may switch migration package’s
status back to migration even if the package is set to productive provided a posting run has not
occurred. To prevent this situation, you should validate your data using the posting simulation
until validation is finished. It is also important to plan enough time for validation.

Which data should be migrated to revenue accounting is dependent on your specific situation.
There are companies which migrate all contracts, part of their contracts, or even no contracts
at all. Another important factor is whether the contract is complete or not.

The deadline for complience is approaching and as such, another criteria for data migration is if
the project timeline allows for the migration of all processes to revenue accounting. Materiality
and data volume of these processes may also influence the decision to migrate.

As you evaluate the amount of legacy data you need to migrate, you should consider the timing
of fulfillment and invoicing. If your order, fulfilmment, and invoice is within the same period, you
don‘t have to migrate the data to Revenue Accounting (FI-RA).

If you want to report the disclosures such as the liability for a contract from revenue accounting,
you would need to migrate all data. If, for part of the contracts, the disclosures can be reported
from different sources, you may choose to migrate just part of the contracts. An example of this
would be if there is no allocation effect for your performance obligations. Also, if reporting for
open contracts can be done outside revenue accounting or if open contracts will be completed
soon after the transition date, you could consider skipping the migration of any legacy contracts
and only use Revenue Accounting (FI-RA) for new contracts going forward.
9 Transition
In this chapter, we will look at the issues associated with transition and how it impacts
Revenue Accounting (FI-RA).
9.1 Transition process
The transition process within revenue accounting (FI-RA) involves switching from the old
revenue recognition standard (ASC 605) to the new revenue recognition standard (ASC 606).
This process has three main steps:

Creating a new accounting principle in SAP

Adjusting contracts according to the new accounting principle
Calculating the cumulative catch-up between the old revenue recognition standard and the
new revenue recognition standard

The first step in creating a new accounting principle was covered in Section 4.2. You can have
multiple accounting principles at the same time and Revenue Accounting (FI-RA) supports
multiple accounting principles.

Once the new accounting principle is created, the second step is to adjust contracts according
to the new accounting principle. The items that must be considered during this step include:

Contract combinations
Linked performance obligations (POBs)
Additional performance obligations
Historical standalone selling price (SSP)
Changing the fulfillment event type from Invoice to Goods Issue

The last item is to calculate the cumulative catch-up. The cumulative effect of a new accounting
standard for revenue recognition is the difference between cumulated, historically-recognized
revenue at a defined date and the cumulated revenue that would have been recognized at this
date with application of the new standard from the start of all open contracts. The cumulative
effect has to be calculated at the start of the retrospective comparative period for the Full
Retrospective Method or at the date of adoption for the Modified Retrospective Method. The
Transition Method will be discussed in more detail in Section 9.3.
9.2 Transition method
The topic of transition method is critical to the success of a revenue recognition project. Based
on the method you choose, the cumulative catch-up calculation changes, the reporting
requirements differ, and the data requirements vary. This is something that should be disclosed
in your company’s 10K disclosure reporting. Per the SEC, both transition methods require a
two-year comparative reporting timeframe. One method requires running in parallel (both the
old and new revenue recognition standards) while the other does not.

There are two transition methods available and they are:

Full retrospective
Modified retrospective

9.2.1 Full retrospective

For the full retrospective transition method and a date of adoption of January 1, 2018, the
comparative time frame starts on January 1, 2016. During this timeframe, from January 1, 2016
to January 1, 2018, an entity has to report based on the old standard and provide comparative
figures for the new accounting standard. Financial statements published are based on the old
accounting standard until the date of adoption at which time financial statements are then
published under the new standard going forward. The cumulative catch-up is calculated at the
transfer date and posted to the leading ledger or G/L accounts at the date of adoption. After
date of adoption, the entity will only need to continue reporting based on the new accounting
standard.

Companies should also perform the data migration close to the transfer date to minimize the
changes to the operational system. Depending on when the migration can be performed, the
operational events may not be available to provide full retrospective reporting. If you are
currently using traditional SD-based revenue recognition, other limitations may apply to the full
retrospective transition method for periods in the past.

9.2.2 Modified retrospective

For the modified retrospective transition method and a date of adoption of January 1, 2018, the
comparative timeframe starts on January 1, 2016. During the timeframe, from January 1, 2018
to January 1, 2019, an entity will be running both accounting standards in parallel, will report
based on the new standard, and will provide comparative figures for the old accounting
standard. The entity will continue to publish financial results based on the old accounting
standard for the modified retrospective transition method.

With the date of adoption as January 1, 2018, the entity will add the new accounting standard.
The new accounting standard is either based on data in the leading ledger or in the general
ledger accounts referring to this accounting principle depending on which parallel accounting
approach has been chosen. The cumulative catch-up is calculated and posted at the date of
adoption on January 1, 2018. The comparative timeframe, during which financial data on both
accounting standards need to be provided, is one year with retrospective pro-forma
comparison.

9.2.3 Transition method comparison

The transition method a company chooses depends on many factors, including data and system
availability, time to adoption, and what others in the industry choose (to name a few). Each
method has its advantages and disadvantages. To assist in the comparison, refer to Figure 9.1.

Figure 9.1: Transition method comparison

The Full Retrospective Transition Method requires the cumulative catch-up to be posted at the
transfer date, which is January 1, 2016 in Figure 9.1. This will require going through each month
from then to the current date to calculate your positions. Sometimes this is not feasible due to
missing data and an inability to recreate the state of operational documents (like deliveries, for
example). Using Full Retrospective, you do not need to run two accounting principles in parallel
as you only need to run the new accounting principle from the adoption date going forward
(assuming your adoption date is two years after your transfer date).

The Modified Retrospective Transition Method requires the cumulative catch-up to be posted at
the adoption date, which is January 1, 2018 in Figure 9.1. This eliminates the need for
recalculating prior months, though you do have to prepare a pro-forma report for prior reporting
years for comparison. If you use the Modified Retrospective transition method, you will need to
run two accounting principles in parallel for at least one year going forward.
9.3 Transition execution
During the migration process, you ran the operational load, the initial load, and you calculated
unbilled and deferred revenue.

During the transition process, you perform the following steps:

Reverse unbilled or deferred revenue for the new accounting principle

Calculate the cumulative catch-up
Calculate time-based revenue for the new accounting principle
Calculate contract asset and liabilities for the new accounting principle
Execute the comparative report
Post revenue for the new accounting principle

9.3.1 Reverse unbilled or deferred revenue

The new accounting principle needs to post information according to the new accounting
standard and, as a result, deferred revenue and unbilled receivables that have already been
calculated need to be reversed. These transactions will update the posting table
FARR_D_POSTING in Revenue Accounting (FI-RA). They will also update the FI General
Ledger under the new accounting principle. It is advisable for this posting to be done into a
special period for FI. If you need to reverse these items for any reason, you can run transaction
FARR_TRANS_REV_URDR. You can run this transaction in test mode to view the job log
where you can validate the transaction reverses to the correct entries for Deferred and Unbilled
Revenue as well as corresponding receivable adjustments.

9.3.2 Calculate the cumulative catch-up

The contracts under the new accounting principle need to be restated. The addition of
performance obligations, contract combinations, and other changes are still possible. For new
event type “Goods Issue,” fulfilled quantities up to the transition date must have been
transferred from the operational application. The cumulative catch-up determines the fulfilled
quantity at transition date from the historic goods issue events in the legacy system.

For new event type “Percent of Completion (PoC)”, a PoC must have been transferred from the
operational application, from a legacy system, or from the old accounting principle. The PoC
can also be maintained manually in the new accounting principle.

If an accounting principle or company code is in status “transition,” then any manual changes or
manual combinations are handled as retrospective changes with a cumulative catch-up from
contract inception.

The changes between old and new accounting principles are used in the cumulative catch-up
calculation. The cumulative catch-up effect is the effect on the accounts from the difference
between the historic cumulative recognized revenue at transition date and re-calculated
recognized revenue up to that date, according to the new attributes of the performance
obligations (POBs).

You can use transaction FARR_TRANS_CATCHUP to re-process your contracts under the new
accounting principle. The effect of re-calculation is stored under a specific reconciliation key
that is flagged for transition.

9.3.3 Calculate time-based revenues

To reflect changes for time-based performance obligations between old and new accounting
principles, you need to run transaction FARR_TM_TRANSFER for time-based revenue
calculation after the calculation of the cumulative catch-up. This transaction transfers the effect
on time-based revenues into the posting table. If there are any changes to time-based POBs—
where future revenue has been manually maintained—that cause a change in allocated price or
cumulative catch-up of recognized revenue, manual spreading will be invalidated and time-
based revenue must be [Link] Figure 9.2.

Figure 9.2: Calculate time-based revenue

9.3.4 Calculate contract assets and liabilities

The balances of the contract assets and contract liabilities need to be calculated using the
transaction FARR_LIABILITY_CALC. The new balances are determined by the current setting
of the new accounting principle and are posted against a receivables adjustment account (see
Figure 9.3).

Figure 9.3: Calculate contract assets and liabilities

9.3.5 Execute the comparative report

Once you have loaded your legacy data into Revenue Accounting (FI-RA) for the new
accounting principle, you can run the comparative report for old and new accounting principles
which compares differences according to posting category. Before you run the comparative
report, you must first prepare the data for the report. You do this using the transaction
FARR_PREPARE_COMP. The report stores comparative data in the table
FARR_D_COMP_TRAN. See Figure 9.4.
Figure 9.4: Prepare data for comparative report

9.3.6 Execute the comparative report

Once you have run the transaction to prepare the data for the comparative report, you can
execute the report using WebDynpro application FARR_TRANSITION_COMP_REPORT. The
comparative report highlights the main details by contract combination. The selection criteria
can be seen in Figure 9.5.
Figure 9.5: Transition comparative report

9.3.7 Post revenues for the new accounting principle

You can use transaction FARR_REV_POST to post the effects of the cumulative catch-up (see
Figure 9.6). The effect is the difference between the recalculated cumulative recognized
revenue up to transfer date according to attributes of the new accounting principle and the
recognized revenue that has been transferred as posted recognized revenue up to the transfer
date.
Figure 9.6: Revenue posting run

This program clears the balances of unbilled receivables and deferred revenues against the
receivable adjustment and builds up contract asset and contract liability accounts. The revenue
adjustment is posted automatically for the new standard by revenue account.

To run the post -revenue transaction, you select the data based on the period referring to the
transfer date. When you are ready to actually post, switch to posting mode. The cumulative
catch-up amount needs to be posted against retained earnings as a follow-up activity.
10 Implementation in practice
In this chapter, we will provide some general information around the implementation of
Revenue Accounting (FI-RA). We will look at the overall timing of a revenue project, the
challenges many will face, and recommendations for a realization project.
10.1 Timing
The topic of revenue recognition has been discussed by the accounting boards since 2002;
however, the new standard was not released until 2014. The original deadline for adoption was
December 15, 2016 for public companies and December 15, 2017 for private companies. This
deadline was delayed by one year for both public and private companies. The current deadline
for adoption is December 15, 2017 for public companies and December 15, 2018 for private
companies. There is little chance that the deadline will be delayed again.

Most revenue projects require companies to evaluate their current business processes around
revenue recognition. Often times there are impacts to tax, compensation, procurement, and
various other departments requiring companies to look at their business as a whole versus just
at the accounting aspect of revenue. This potential for change has impacted many of the
companies we have worked with and has been generally underestimated. The deadline for
compliance is approaching and companies need to factor in time for organizational change
management.
10.2 Challenges
The challenges of implementing the FI-RA add-on presented here do not lie solely in the
technical installation and definition. Before using the add-on, you have to complete a number of
analytical tasks, starting with determining whether and where the requirements of the new
standard are relevant for the company-specific current and future business models and how
they can be best integrated in the existing processes and system landscapes.

We recommend that you follow the current ongoing intensive discussions in expert circles
regarding the changes contained in ASC 606 compared to current regulations—particularly from
a financial perspective.

Across various industries, ASC 606 users believe the new standard contains both content and
material changeover effects which result in particular in organizational and technical changes.

10.2.1 Structural shifting of revenues

To illustrate the above, let us take another look at the example from the telecommunications
industry presented in Section 1.2: following the evaluation model of the new standard, the first
step is to separate the different performance obligations from contracts and report them at the
time of the performance fulfillment and weighted according to the respective standalone selling
price.

In the example selected, the performance obligations are the one-time provision of the end
device and the recurring telecommunications services. This separation and separate evaluation
results in a structural adjustment in the sales revenue. In our example, the proportional end
device revenue increases by a significant 30% to the detriment of the service proportion.

10.2.2 Time-based shifting of revenues

However, in addition to the structural adjustment, there is also a time-based adjustment of the
sales revenue. According to ASC 606, the revenue must be recognized when a customer
acquires control over the products or services. Our simple example showed this effect
decisively. While the contractually agreed telecommunications services are fulfilled over the
entire term of a contract and the revenues have to be recognized proportionately for each
contract period, the performance obligation from the sale of the end device is deemed fulfilled
when the device is handed over to the customer.

The consequence of this is that the end device revenue, which, according to previous
legislation, was to a large extent recognized evenly over the contract term, must in the future be
reported at the beginning of a contract.

As an interim result, we can state the following: by applying ASC 606, in the example selected,
the service revenue proportion of the total revenue of the multicomponent contract is reduced in
favor of the revenue from trading goods. From a time perspective, the service revenue
proportion is brought forward to the beginning of the contract, although the total revenue does
not change compared to previous practice.

10.2.3 Time-based and structural shifting of costs

In addition to the pure representation of revenue, the standard also provides new rules for
reporting expenses and costs that can be capitalized. In the future, under certain prerequisites,
costs for initiating and fulfilling customer contracts must be capitalized as direct contract costs
and written off over the total term of the contract. This means that in Profitability Analysis (CO-
PA), it will be possible, for example, to transfer commissions for services of indirect distribution
channels from operational expenses to the amortization area.

This can influence all company key figures based on EBITDA (Earnings before Interest, Taxes,
Depreciation, and Amortization) positively. Performance indicators which, for stakeholders and
potential investors, are significant criteria for assessing companies in terms of international
competition and can be influenced by a targeted design of distribution channel processes.

This effect can also impact the time of tax payments and profit distributions as well as
compliance with agreed credit clauses. Under some circumstances, further company targets
which are directly or indirectly connected to this factor may have to be subjected to a check—
right up to profit distributions and bonus systems, because ASC 606 also targets revenue
recognition and thus the most important tax and incentive element in sales. Therefore,
companies must check in each case whether it makes sense to redesign the current sales and
contract processes or even reorganize the existing distribution channels to achieve a certain
distribution of the sales revenues.

Even if the selected example gives this impression, the need for adjustment, which results from
the demonstrated structural and time-based shifting of the sales revenues and the possibilities
of alternative cost reporting, is not restricted solely to telecommunications companies or other
industries with multicomponent contracts. Indeed, we can state that there is a potential need for
action wherever the sale of a service gives rise to future performance obligations. How
significant the consequences of ASC 606 actually are will also depend on the reporting policy of
a company and on how the future voting rights available are used.

10.2.4 Time or period of revenue recognition

While the regulations valid up until now have based the recognition of revenue on the transfer of
the decisive opportunities and risks or, in the case of production orders, on the percentage of
completion—and thus proportionately on the performance progress—the new standard links the
reporting of revenue consistently with the transfer of the control over a good or service to a
customer.

With regard to the transfer of control, ASC 606 requires that at the time a contract is
concluded, you determine whether each performance obligation is fulfilled based on time or
based on a period. Therefore, companies that already apply the percentage of completion
method have to reassess whether the method for estimating the percentage of completion is
correct or needs to be changed.

In the future, period-based fulfillment of a performance obligation will lead to a successive,

continuous, and distributed reporting of revenues, provided that the percentage of completion of
the performance obligation can be determined reliably at any point in time.

10.2.5 Organizational structures and business models

For companies that are active internationally, ASC 606 also means that they will first have to
analyze the influencing factors which result from the organizational structure of corporate
groups: starting with legal units (e.g., legal split into production and sales units beyond product
groups and country borders), through sovereignty aspects (e.g., customs and handling
restrictions), right up to organizational structures within a corporate group if organizationally
separate units are responsible for the different main processes of order processing, delivery
processing, and invoicing or monitoring receivables.

A further aspect that has to be considered is different business models. It is quite feasible for a
production company to use the following business models for its customer-related business
processes in parallel:

Make-to-stock
Make-to-order
Engineer-to-order

The company may also separate these models into process views such as initial business,
spare parts business, service and maintenance business, as well as complaints and warranty
services.

10.2.6 System and application landscape

As far as the technical system and application prerequisites are concerned, companies must
also take into account that the order-to-cash process typically runs through different modules in
SAP systems. In terms of the availability of information, this means that the data for the above-
mentioned processes can come from different sources.

We can already see clearly here which different factors have to be taken into account for an
appropriate analysis in order to achieve a complete and standardized understanding of all
connecting factors, contexts, interactions, and restrictions involved in implementing ASC 606.

The effects and interactions demonstrated and whose influencing factors are illustrated again,
in summary form, in Figure 10.1, clearly indicate that companies should most definitely use the
time remaining until the new regulations come into force to establish the regulations in
commercial practice at an early stage.

Figure 10.1: Field of impact of ASC 606

10.3 Project content and structure
The challenges outlined result in the following specific fields of action and tasks in an
implementation project:

Information must be obtained about content issues and specific challenges and implications
of the new standard must be clarified.
The changes required in the organization of sales and distribution and in the business
models and processes must be analyzed and adapted where necessary.
In external and internal reporting, the invoicing process must be separated from the
recognition and reporting of revenue, but still be mapped with these in an integrated way.
The technical system and application prerequisites for implementing the requirements must
be met.

The list above clearly shows that the focus in an ASC 606 project cannot be on the installation
and activation of an add-on. Nevertheless, positive effects for understanding problems and for
solution approaches can be achieved by use of the add-on through specific prototyping during
all project tasks.

Of course, effective change management also plays an important role in such complex projects.
The top management of the company is the main driver and guarantee for the success of the
implementation. Any adjustments and changes required beyond the above-mentioned
boundaries must be implemented and installed via clear, binding specifications and consistent
decisions from process owners and teams responsible. This transformation process must be
supported by active communication over the entire distance.
A Terminology explanations
To make this book easier to understand, we have listed and explained a few recurring terms
and abbreviations from the context of the procedure for ASC 606 below.
Term
Explanation
Contract
Agreement between at least two parties with legally enforceable rights and duties
Customer
Natural or legal person who is in a business relationship with a company
Performance obligation
Commitment in a contract to transfer a separately identifiable good or service
Transaction price
Value of the consideration that the company can expect to receive from a contract for the transfer of the goods or the
fulfillment of the services
Standalone selling price
Price of a good or service which would be invoiced in general business dealings independently of a customer-specific
multicomponent contract
Recognized revenue
Revenue which must be reported due to the fulfillment of a performance obligation according to ASC 606 (including the
allocation effect)
Billed revenue
Revenue actually invoiced to a customer in an executed and transmitted invoice
RA
Revenue accounting
RAC
Revenue accounting contract
BRFplus
Business rule framework plus
POB
Performance obligation
RAI
Revenue accounting item
ARL
Adapter Reuse Layer
Table 10.1: Terms
You have finished the book.

Sign up for our newsletter!

Want to learn more about new e-books?

Get exclusive free downloads and SAP tips.

Sign up for our newsletter!

Please visit us at [Link] to find out more.

B The authors

M. Larry McKinney is an SAP alumnus with more than 20 years of experience implementing
and maintaining SAP at several Fortune 1000 companies. His skillset includes both functional
and technical aspects of SAP from configuration to development to Basis, as well as business
subject matter expertise in various industries.

Reinhard Müller has accompanied many international template developments and rollouts over
the last 20 years as a project manager in the area of SAP Financial Accounting and Controlling.
This has enabled him to gain valuable experience in various industries which he can use
consistently today in customer projects as a partner at Conessent.
In doing so, he uses his sound knowledge of national and international accounting principles and
group accounting in designing SAP solutions.

After completing his studies in economics at the University of Paderborn, with a focus on
financial statements, financial accounting, and taxes, Reinhard Müller was initially employed in
the internal audit division of a large company and as a commercial manager of a medium-sized
company for a few years, before becoming partner of a globally active management and IT
consultancy, and later a co-founder of Conessent Consulting GmbH.

Frank Rothhaas is the managing director of Conessent Consulting GmbH, a company which
provides international SAP consulting and software development. For more than 15 years, he
has been a project manager in international SAP implementation projects.

He has gathered experience in the areas of business design, business process integration, and
application design in numerous companies in various different industries and uses this
experience consistently in his consulting activities.

Frank Rothhaas’ work focuses on the implementation of international accounting principles and
the integration of these principles in management and group reporting.

He studied economics at the University of Mannheim and subsequently earned a doctorate in

Information Management.
C Disclaimer
This publication contains references to the products of SAP SE.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer,
StreamWork, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal
Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services
mentioned herein as well as their respective logos are trademarks or registered trademarks of
Business Objects Software Ltd. Business Objects is an SAP company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase
products and services mentioned herein as well as their respective logos are trademarks or
registered trademarks of Sybase, Inc. Sybase is an SAP company.

SAP SE is neither the author nor the publisher of this publication and is not responsible for its
content. SAP Group shall not be liable for errors or omissions with respect to the materials.
The only warranties for SAP Group products and services 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.
More Espresso Tutorials eBooks
Dieter Schlagenhauf & Jörg Siebert:
SAPF® Fixed Assets Accounting (FI-AA)

Processes and Functions in SAP ERP Financials

Validation and Reporting for IFRS
Posting Examples
Periodic Activities Explained

Paul Ovigele:
Reconciling SAP® CO-PA to the General Ledger

Learn the Difference between Costing-based and Accounting-based CO-PA

Walk through Various Value Flows into CO-PA
Match the Cost-of-Sales Account with Corresponding Value Fields in CO-PA

Thomas Michael:
Reporting for SAP® Asset Accounting

Basic Asset Accounting Reporting Features

Asset History Sheet and US tax reporting
Balance Reports
Transaction Reports

Lennart B. Ullmann & Claus Wild:

Electronic Bank Statement and Lockbox in SAP® ERP

Processing the Electronic Bank Statement in SAP

Integrating Payment Advices as of SAP EhP 5
New Functionality for Post-Processing as of SAP EhP 6
Detailed Message Monitoring and Reprocessing Examples

Stephen Birchall:
Invoice Verification for SAP®

Learn everything you need for invoice verification and its role in FI and MM
Keep user input to a minimum and automate the process
Discover best practices to configure and maximize the use of this function

Janet Salmon & Ulrich Schlüter:

SAP® HANA for ERP Financials, 2nd edition

Basic principles of SAP HANA

The idea behind SAP Accounting powered by SAP HANA
HANA applications in ERP Financials
Implications on business processes

Ann Cacciottolli:
First Steps in SAP® FI Configuration

Get an overview of SAP Financials configuration

Explore fundamental aspects of FI-GL, FI-AR, and FI-AP configuration
Learn how to create, define, and assign company codes and chart of accounts
Obtain hands-on instruction based on examples and screenshots
Janet Salmon & Claus Wild:
First Steps in SAP® S/4HANA Finance

Understand the basics of SAP S/4HANA Finance

Explore the new architecture, configuration options, and SAP Fiori
Examine SAP S/4HANA Finance migration steps
Assess the impact on business processes

Common questions

A Revenue Accounting Item (RAI) represents a data element transferred to the Revenue Accounting module and reflects performance obligations, their valuation, and status . The processing involves mapping from operational documents to revenue contracts, monitoring fulfillment using FARR_RAI_MON, and recording recognized revenue accordingly . RAIs are crucial for ensuring compliance with ASC 606 by maintaining accurate accounting records of obligations and revenue events .

The SAP Revenue Accounting and Reporting add-on serves as a subledger to integrate requirements from ASC 606, mapping performance obligations and revenue recognition within SAP systems . BRFplus (Business Rule Framework plus) plays a role in customizing performance obligations through decision tables and enabling control over revenue allocation, exclusions, and adjustments . This enhances the flexibility and precision of implementing ASC 606 standards through intelligent configuration of accounting practices .

Under ASC 606, performance obligations and revenue are recognized based on the transfer of control to the customer, separate from the billing documents which trigger cash flow . This separation contrasts with previous standards where revenue recognition often aligned directly with billing events, integrating financial reporting with service delivery more intricately . The decoupling allows for more transparent reflection of a company's performance and obligations in financial statements .

ASC 606 mandates revenue recognition based on the transfer of control over a good or service to the customer, whereas traditional methods often relied on the transfer of risks and rewards or completion of performance. Under ASC 606, companies need to evaluate performance obligations and recognize revenue based on meeting specific conditions, potentially leading to deferred revenue recognition .

The "standalone selling price" serves as the baseline for allocating transaction prices to individual performance obligations within a contract, ensuring that revenue recognition aligns with the value of goods or services as sold independently . This principle helps to accurately represent the economic reality of contracts in financial statements, influencing how revenues are split and recognized over time .

Non-compliance with ASC 606 could result in inaccurate financial reporting, potentially leading to restated financial statements, loss of investor confidence, and financial penalties . Operationally, inadequate compliance could disrupt business processes and misrepresent the financial health of a company, affecting decision-making and stakeholder relationships . Companies risk misalignment in revenue reporting, impacting profitability assessments and financial ratios .

Challenges include adapting accounting systems to separate billing from revenue recognition and integrating with existing processes and reporting requirements . Companies can address these by prototyping with the SAP add-on, ensuring management support, and implementing clear process changes through effective change management strategies .

ASC 606 can significantly influence financial metrics such as EBITDA by shifting revenue recognition timelines and capitalizing contract initiation costs . This, in turn, affects key indicators critical for investor evaluation, tax payments, and compliance with financial covenants. The standard may also prompt adjustments in business strategies, such as restructuring sales processes to optimize revenue and cost reporting under the new guidelines .

Effective change management is critical in ASC 606 projects due to the extensive modifications required in accounting practices and system integrations . Successful change management ensures that process adjustments are communicated and adopted across all organizational levels, which is vital for meeting compliance deadlines and maintaining financial integrity . Top management's role in steering these changes is essential for overcoming resistance and securing the necessary resources and commitment .

A company might redesign its sales and contract processes to optimize tax outcomes, enhance financial performance metrics like EBITDA, and ensure compliance with ASC 606 . Such redesigns can enable more strategic allocation of revenues and costs, align operational practices with legal requirements, and potentially increase competitiveness . Benefits include improved financial reporting accuracy, better stakeholder communication, and a stronger position in investor and market evaluations .

Salmon J., Wild C. First Steps in SAP S-4HANA Finance 2018
No ratings yet
Salmon J., Wild C. First Steps in SAP S-4HANA Finance 2018
263 pages
Fi-Ra Revenue Accounting
No ratings yet
Fi-Ra Revenue Accounting
173 pages
S4F02 Col14
No ratings yet
S4F02 Col14
307 pages
SAP Central Finance Overview
100% (2)
SAP Central Finance Overview
391 pages
SAP Process Refinements Guide
100% (1)
SAP Process Refinements Guide
269 pages
Accruals Management in SAP S/4HANA
0% (1)
Accruals Management in SAP S/4HANA
62 pages
SAP S/4HANA Finance Customization Guide
100% (2)
SAP S/4HANA Finance Customization Guide
300 pages
Discover SAP: A Comprehensive Guide
100% (1)
Discover SAP: A Comprehensive Guide
540 pages
Guide to Transitioning to SAP S/4HANA
No ratings yet
Guide to Transitioning to SAP S/4HANA
136 pages
Data Migration For SAP - Copy C3ek-J9tq-Buhs-8rv4
100% (2)
Data Migration For SAP - Copy C3ek-J9tq-Buhs-8rv4
569 pages
SAP Credit Management Overview
100% (1)
SAP Credit Management Overview
114 pages
Bank Communication Management in SAP
No ratings yet
Bank Communication Management in SAP
230 pages
Machine Learning With SAP - Copy Gvru-B3my-Z56s-N98h
No ratings yet
Machine Learning With SAP - Copy Gvru-B3my-Z56s-N98h
499 pages
SAP Analytics Cloud Guide 2024
100% (1)
SAP Analytics Cloud Guide 2024
1,126 pages
SAP MM Demand-Driven Replenishment Guide
100% (2)
SAP MM Demand-Driven Replenishment Guide
170 pages
BRFplus Output Management in S/4HANA
0% (1)
BRFplus Output Management in S/4HANA
95 pages
SAP PRESS: Expert Guides for Users
No ratings yet
SAP PRESS: Expert Guides for Users
195 pages
Data Migration With SAP
No ratings yet
Data Migration With SAP
550 pages
ABAP Development For SAP Business Workflow - Copy Yadp-82bf-q76m-Iuzh
100% (3)
ABAP Development For SAP Business Workflow - Copy Yadp-82bf-q76m-Iuzh
199 pages
SAP S4 Hana Finance
83% (6)
SAP S4 Hana Finance
785 pages
SAP S/4HANA Finance Overview Guide
100% (2)
SAP S/4HANA Finance Overview Guide
232 pages
Introducing GRIR Reconciliation With Machine Learning in SAP S4HANA - Copy 34uv-Kbnf-Tmia-Srgp
No ratings yet
Introducing GRIR Reconciliation With Machine Learning in SAP S4HANA - Copy 34uv-Kbnf-Tmia-Srgp
65 pages
SAP S/4HANA Cloud 2502 Release Insights
No ratings yet
SAP S/4HANA Cloud 2502 Release Insights
186 pages
SAP Workflow Management Overview
No ratings yet
SAP Workflow Management Overview
23 pages
Custom Extensions in SAP S/4HANA Guide
No ratings yet
Custom Extensions in SAP S/4HANA Guide
68 pages
Expert Insights on SAP PRESS Publications
No ratings yet
Expert Insights on SAP PRESS Publications
621 pages
Successfully Managing S4HANA Projects
100% (8)
Successfully Managing S4HANA Projects
365 pages
SAP Global Trade Services Overview
No ratings yet
SAP Global Trade Services Overview
88 pages
SAP Fiori Implementation and Development
No ratings yet
SAP Fiori Implementation and Development
573 pages
RISE with SAP: A Comprehensive Guide
No ratings yet
RISE with SAP: A Comprehensive Guide
87 pages
Winshuttle-Migrating-Finance-SAP-ECC-to-S4HANA-whitepaper-EN
100% (1)
Winshuttle-Migrating-Finance-SAP-ECC-to-S4HANA-whitepaper-EN
62 pages
Data Provisioning and Cleansing With SAP HANA SDI and SAP HANA SDQ PDF
No ratings yet
Data Provisioning and Cleansing With SAP HANA SDI and SAP HANA SDQ PDF
92 pages
SAP S/4HANA Accruals Management Exercise
100% (1)
SAP S/4HANA Accruals Management Exercise
191 pages
S4/HANA Finance Configuration Guide
100% (1)
S4/HANA Finance Configuration Guide
85 pages
Bertram E. SAP Analytics Cloud Performance Optimization Guide 2023
100% (1)
Bertram E. SAP Analytics Cloud Performance Optimization Guide 2023
817 pages
Selective Migration to SAP S/4HANA Guide
No ratings yet
Selective Migration to SAP S/4HANA Guide
21 pages
ABAP in The Cloud - Development and Operations With SAP BTP, ABAP Environment - 2021
67% (3)
ABAP in The Cloud - Development and Operations With SAP BTP, ABAP Environment - 2021
311 pages
Configure Batch Management in SAP S/4HANA
0% (1)
Configure Batch Management in SAP S/4HANA
10 pages
SAP Press License Key Information
100% (1)
SAP Press License Key Information
501 pages
SAP Press License Key Information
No ratings yet
SAP Press License Key Information
616 pages
SAP S/4HANA Finance Overview 1909
100% (4)
SAP S/4HANA Finance Overview 1909
364 pages
FS250 EN Col95 FV Ltr1
50% (2)
FS250 EN Col95 FV Ltr1
318 pages
SAP S/4HANA Data Migration Guide
100% (1)
SAP S/4HANA Data Migration Guide
24 pages
Material Ledger in SAP S4HANA
100% (3)
Material Ledger in SAP S4HANA
508 pages
SAP Convergent Invoicing Exercises
No ratings yet
SAP Convergent Invoicing Exercises
145 pages
SAP S/4HANA Architecture Overview
No ratings yet
SAP S/4HANA Architecture Overview
37 pages
DMM116 - Transition To SAP S/4HANA: Tools For On-Premise and Cloud Migration
No ratings yet
DMM116 - Transition To SAP S/4HANA: Tools For On-Premise and Cloud Migration
50 pages
Full Stack Development With SAP - Copy s3y7-Ugx6-Hm9b-Redp
100% (1)
Full Stack Development With SAP - Copy s3y7-Ugx6-Hm9b-Redp
639 pages
S4F23 en 20 Ex
No ratings yet
S4F23 en 20 Ex
236 pages
SAP BW4HANA - The Comprehensive Guide
100% (2)
SAP BW4HANA - The Comprehensive Guide
667 pages
Intro ERP Using GBI Slides FI en v2.01
No ratings yet
Intro ERP Using GBI Slides FI en v2.01
25 pages
Implementing SAP S/4HANA Cloud ALM
No ratings yet
Implementing SAP S/4HANA Cloud ALM
324 pages
SAP Fiori and UI5 Training Overview
50% (2)
SAP Fiori and UI5 Training Overview
121 pages
RE050 - EN - Col06 Leasing For IFRS and US GAAP With SAP Real Estate Management
No ratings yet
RE050 - EN - Col06 Leasing For IFRS and US GAAP With SAP Real Estate Management
149 pages
B071H6YNMN
100% (2)
B071H6YNMN
395 pages
S4SD1 EN Col09 ILT FV Part A4
100% (1)
S4SD1 EN Col09 ILT FV Part A4
152 pages
SAP S/4HANA 2023 Feature Overview
No ratings yet
SAP S/4HANA 2023 Feature Overview
778 pages
SAP RAR IFRS15 Implementation Guide
No ratings yet
SAP RAR IFRS15 Implementation Guide
11 pages
SAP End-to-End Configuration Guide
No ratings yet
SAP End-to-End Configuration Guide
2 pages
Three-Way Match Process in SAP S/4HANA
No ratings yet
Three-Way Match Process in SAP S/4HANA
10 pages
SAP S/4HANA Funds Management Guide
No ratings yet
SAP S/4HANA Funds Management Guide
60 pages
Creating Fixed-Term Deposits in SAP F111
No ratings yet
Creating Fixed-Term Deposits in SAP F111
18 pages
Treasury & Risk Management Exercises
No ratings yet
Treasury & Risk Management Exercises
235 pages
Universal Parallel Accounting in SAP S/4HANA
No ratings yet
Universal Parallel Accounting in SAP S/4HANA
6 pages
SAP WIP Calculation for Month-End Entries
No ratings yet
SAP WIP Calculation for Month-End Entries
3 pages
SAP Project Cost Planning Overview
No ratings yet
SAP Project Cost Planning Overview
5 pages
Industrial Attachment Report: Enkipai Hotel
No ratings yet
Industrial Attachment Report: Enkipai Hotel
17 pages
VFX and Motion Graphics Roles Explained
No ratings yet
VFX and Motion Graphics Roles Explained
18 pages
FINA3383: Financial Regulations Overview
No ratings yet
FINA3383: Financial Regulations Overview
5 pages
Dop Integrity Test
No ratings yet
Dop Integrity Test
17 pages
Customer Service Process Checklist Workshop
No ratings yet
Customer Service Process Checklist Workshop
4 pages
2018 Caldera Spas Vacanza Series Owners Manual 303766.18
No ratings yet
2018 Caldera Spas Vacanza Series Owners Manual 303766.18
42 pages
Test Item Handling Procedure (QP-125)
No ratings yet
Test Item Handling Procedure (QP-125)
9 pages
Liber Loagaeth: Secrets Revealed
No ratings yet
Liber Loagaeth: Secrets Revealed
1 page
Trading Strategy with ASR Indicators
No ratings yet
Trading Strategy with ASR Indicators
11 pages
Agniveer Women Military Police Recruitment 2024
No ratings yet
Agniveer Women Military Police Recruitment 2024
21 pages
Ponsonby's Influence in Ottoman Turkey
No ratings yet
Ponsonby's Influence in Ottoman Turkey
358 pages
Role of Administration in Organizations
No ratings yet
Role of Administration in Organizations
10 pages
English Proficiency Requirements Guide
No ratings yet
English Proficiency Requirements Guide
1 page
Power Series and Convergence Explained
No ratings yet
Power Series and Convergence Explained
3 pages
OGUK - Use of Barrier Materials in Well Decommissioning - Issue 3 - 2022
No ratings yet
OGUK - Use of Barrier Materials in Well Decommissioning - Issue 3 - 2022
39 pages
Understanding Linear Relationships in Regression
No ratings yet
Understanding Linear Relationships in Regression
8 pages
Analyzing Common Word Frequencies
No ratings yet
Analyzing Common Word Frequencies
140 pages
Smart Card Personalization System Overview
No ratings yet
Smart Card Personalization System Overview
8 pages
Beachfront Land in El Nido, Palawan
No ratings yet
Beachfront Land in El Nido, Palawan
2 pages
Bill of Entry for Bearings Import
No ratings yet
Bill of Entry for Bearings Import
2 pages
Merchant of Venice: A Book Review
No ratings yet
Merchant of Venice: A Book Review
11 pages
MEMS Mechanical Sensors Steve P. Beeby
No ratings yet
MEMS Mechanical Sensors Steve P. Beeby
83 pages
Lehninger - Carbohydrates Notes PDF BSC Zoology
No ratings yet
Lehninger - Carbohydrates Notes PDF BSC Zoology
78 pages
Mastering Sentence Combining Techniques
No ratings yet
Mastering Sentence Combining Techniques
4 pages
OpenBSI Utilities Manual Overview
No ratings yet
OpenBSI Utilities Manual Overview
658 pages
Rizal's Early Influences on Nationalism
No ratings yet
Rizal's Early Influences on Nationalism
5 pages
Customer Value and Loyalty Strategies
No ratings yet
Customer Value and Loyalty Strategies
16 pages
NTSE Results for Tamil Nadu Students
No ratings yet
NTSE Results for Tamil Nadu Students
26 pages
5G RAN 8.1 User Experience Enhancements
No ratings yet
5G RAN 8.1 User Experience Enhancements
56 pages
Sims 3 Application Build Report
No ratings yet
Sims 3 Application Build Report
6 pages

SAP FI-RA Revenue Accounting Guide

Uploaded by

SAP FI-RA Revenue Accounting Guide

Uploaded by

M.

Practical Guide to SAP® FI-RA—Revenue

All rights reserved

Check out our YouTube channel to watch our videos at

If you are interested in SAP Finance and Controlling, join us at [Link]

Related titles from Espresso Tutorials:

For the subsequent implementation in SAP, we decided to present a strict chronological

Contract assets/contract liabilities

We have added a few icons to highlight important information. These include:

Examples help illustrate a topic better by relating it to real world scenarios.

1.1.2 Basic principle

1. Identify the contract with the customer

1.1.3 Revenue recognition in SAP

Here, too, there are two alternatives:

Time-based revenue recognition: revenues are recognized in the same proportions

The following factors make this possible:

The import of data in the form of orders, invoices, and events

Cell phone contract with an end device

According to current accounting standards, the accounting representation of this contract is

This results in the following representation:

Figure 1.3: Allocation of the transaction price

Figure 1.4: Cell phone contract in SD

Figure 1.5: Cell phone contract in Revenue Accounting (FI-RA)

Figure 1.7: Goods issue for the cell phone device

Figure 1.8: Recognized revenues from fulfillment

Figure 1.10: Accounting representation

Figure 2.1: Business processes

How strongly is the company’s business model affected by ASC 606?

Figure 2.2: Data flow (contract and delivery)

As a result of the data processing, a separate revenue accounting contract with

As mentioned before, a performance obligation in a revenue accounting contract reflects a

Figure 2.3: Data flow (billing document)

REVREC 100: contains the functional part of Revenue Accounting (FI-RA)

Figure 3.1: Transaction SAINT

SAP composite note for Revenue Accounting (FI-RA)

SAP Note 1987012 contains a very useful summary of the prerequisites,

SAP Revenue Accounting 1.0:

SAP Revenue Accounting 1.1:

SAP Revenue Accounting 1.2:

SAP Revenue Accounting 1.3:

Regenerating the classes after an update

Multiple element arrangement (MEA)

Foreign currency exchange processing based on IAS 21 and ASC 830

Additional SD process support for:

Figure 3.2: Customizing: revenue accounting items

You can assign names of your choice to the classes.

Figure 3.3: Classes: revenue accounting items

Figure 3.4: Classes: interface components

Figure 3.5: Classes: generation

Figure 3.7: Classes: database tables

Figure 3.8: Revenue accounting item management

Figure 3.9: Source item types

Figure 3.10: Logical system

Figure 3.12: Assignment of the source item types

The roles delivered include:

Figure 3.13: Roles in Revenue Accounting (FI-RA)

Figure 3.14: Revenue accounting authorization objects

Figure 3.16: Authorization object for changing items

Figure 3.17: Authorization object for settlement

Figure 3.18: Authorization object for the contract

Prerequisite for customizing

Figure 3.19: Subpackages of the development package FARR

Additional fields may be required for the following purposes:

Processing revenue accounting items

Figure 3.22: Enhancement spots for SD integration

Figure 3.23: Enhancement spots for ARL

Figure 3.24: Enhancement spots for revenue accounting contracts

Figure 3.25: Enhancement spots for accrual postings

Figure 4.1: Customizing in SD

Figure 4.2: Activating Revenue Accounting (FI-RA) in SD

Figure 4.3: Activating item types in SD

Figure 4.4: Create performance obligation for SD billing item

Figure 4.6: Customizing for revenue accounting contracts

Figure 4.7: Customizing for Accounting Principles

Figure 4.8: Accounting principles

Figure 4.9: Assigning the accounting principle to the ledger group