S4F55_EN_Col12 SAP Revenue Accounting and.pdf

S4F55
SAP Revenue Accounting and
Reporting
.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 12
Course Duration: 5 Day(s)
e-book Duration: 1 Day 6 Hours 25 Minutes
Material Number: 50150920

SAP Copyrights and Trademarks
© 2019 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional
trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only,
without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate
company 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.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business
outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’
strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any
reason without notice. The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking statements are subject to
various risks and uncertainties that could cause actual results to differ materially from expectations.
Readers are cautioned not to place undue reliance on these forward-looking statements, which speak
only as of their dates, and they should not be relied upon in making purchasing decisions.
© Copyright. All rights reserved. iii

Typographic Conventions
American English is the standard used in this handbook.
The following typographic conventions are also used.
This information is displayed in the instructor’s presentation
Demonstration
Procedure
Warning or Caution
Hint
Related or Additional Information
Facilitated Discussion
User interface control Example text
Window title Example text
© Copyright. All rights reserved. iv

Contents
vii Course Overview
1 Unit 1: Overview and Architecture
2 Lesson: Outlining SAP Revenue Accounting and Reporting and Its
Architecture
20 Unit 2: Integration with Sender Components
22 Lesson: Understanding the Integration of SAP Revenue Accounting
and Reporting with Sales and Distribution (SD)
40 Lesson: Understanding the Integration of SAP Revenue Accounting
and Reporting with SAP Customer Relationship Management
52 Lesson: Explaining the Integration with SAP Billing and Revenue
Innovation Management
64 Lesson: Understanding the Integration with External Systems
73 Unit 3: Inbound Processing
75 Lesson: Configuring Import Structures
95 Lesson: Working with the Revenue Accounting Item Monitor
103 Lesson: Transferring and Processing Revenue Accounting Items
117 Lesson: Explaining Return Orders
122 Lesson: Creating Revenue Accounting Items for Testing
141 Lesson: Transforming Data with BRFplus
168 Unit 4: Contract Management
170 Lesson: Outlining Performance Obligations Including Concept and
Navigation
195 Lesson: Outlining Revenue Contracts and Their Navigation
204 Lesson: Creating Manual Contract Combinations
212 Lesson: Creating Cost Recognition
228 Lesson: Understanding the Right of Return
230 Lesson: Monitoring Revenue Contracts
252 Unit 5: Price Allocation
253 Lesson: Performing Price Allocation
267 Unit 6: Contract Change
268 Lesson: Changing Contracts
© Copyright. All rights reserved. v

283 Unit 7: Fulfillment and Invoices
285 Lesson: Fulfilling Performance Obligations
306 Lesson: Posting Invoices
322 Lesson: Understanding Simplified Invoice Handling
333 Unit 8: Integration with Cost Object Controlling
334 Lesson: Integrating with Cost Object Controlling
352 Unit 9: Revenue Postings
354 Lesson: Understanding the General Posting Logic
364 Lesson: Explaining the Integration with FI-GL
368 Lesson: Understanding Contract Assets and Contract Liabilities
375 Lesson: Processing Revenue Postings
394 Lesson: Handling Foreign Currency
413 Lesson: Performing Period End Closing
428 Unit 10: Reconciliation and Consistency Checks
429 Lesson: Performing Reconciliation and Consistency Checks
441 Unit 11: Reporting
442 Lesson: Explaining Reporting Functionalities
454 Unit 12: Migration and Transition
456 Lesson: Preparing for Migration and Transition
476 Lesson: Migrating to SAP Revenue Accounting and Reporting
493 Lesson: Migrating from SAP Billing and Revenue Innovation
Management
501 Lesson: Transitioning to the New Revenue Recognition Standard
© Copyright. All rights reserved. vi

Course Overview
TARGET AUDIENCE
This course is intended for the following audiences:
Application Consultant
© Copyright. All rights reserved. vii

UNIT 1 Overview and
Architecture
Lesson 1
Outlining SAP Revenue Accounting and Reporting and Its Architecture 2
UNIT OBJECTIVES
Understand when and why customers need SAP Revenue Accounting and Reporting
Compare the new approach of revenue recognition with existing solutions
List the main features of SAP Revenue Accounting and Reporting
Describe the integration of SAP Revenue Accounting and Reporting with Financial
Accounting
Explain the architectural components of SAP Revenue Accounting and Reporting
Understand deployment options of SAP Revenue Accounting and Reporting
Understand the differences to Sales and Distribution revenue recognition
© Copyright. All rights reserved. 1

Unit 1
Lesson 1
Outlining SAP Revenue Accounting and
Reporting and Its Architecture
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Accounting
SAP Revenue Accounting and Reporting Framework
How Does Revenue Accounting Work According to IFRS 15?
Timing of Revenue Recognition
IFRS15, 31: Recognize Revenue when control of good or service is transferred to
customers (new terminology: when performance obligation is satisfied).
This can be near the time of invoice (that is, in the same financial period) But it can also be
at other events or over time. Possible events:
- Goods issue
- Proof of delivery
Amount of Revenue Recognition
IFRS15, 73ff.: Recognize the amount of consideration to which an entity expects to be
entitled in exchange for transferring goods or services to the customer.
- Multiple Element Arrangement (MEA):
Allocate the complete transaction price on a relative Standalone Selling Price (SSP)
basis.
According to the new revenue standard IFRS15, companies recognize revenue when a
performance obligation is satisfied (IFRS15, 31). Therefore, fulfillment and event type play an
important role. Revenue Accounting manages the fulfillment statuses of performance
obligations. This means that when a performance obligation qualifies as fulfilled, it is tracked

as fulfilled in SAP Revenue Accounting and Reporting. The corresponding revenues and costs
are then recognized in SAP Financials in a revenue posting job, which is typically performed at
the close of an accounting period.
Another aspect is that according to the new standard, companies recognize the amount of
consideration to which an entity expects to be entitled in exchange for transferring goods or
services to the customer (IFRS15, 73ff.). For Multiple Element Arrangements (MEAs),
companies need to allocate the complete transaction price based on the relative Standalone
Selling Price (SSP). Revenue Accounting allows you to allocate the transaction price among
the performance obligations (POBs) in a RA contract. The standard price allocation is based
on the SSP. However, the system allows you to specify other methods of price allocation to
address your specific business scenarios.
Figure 1: Allocate Transaction Price in MEA
IFRS 15 compliance poses a challenge to many industries, but there are some that bundle
goods and services - such as telecommunications and high tech - that it impacts to a greater
extent.
For example, the telecommunications industry, Telcos, typically bundle services and
handsets or equipment, and due to mergers and acquisitions, these companies have a variety
of systems that hold information about a customer contract, making it difficult to obtain a
holistic view of the customer. In addition, data may be 'over aggregated' to get a converged
invoice, with no visibility or traceability back to the originating source for the invoice.
To comply with IFRS 15, Telcos need to change revenue recognition when accounting for
multiple performance obligations, or when there is an uncertain or variable consideration in
determining transaction prices. There are also changes related to the following:
Collectability
Allocation of the transaction price and establishing Standalone Selling Prices
Equipment installation revenues
Contract and customer acquisition costs
Lesson: Outlining SAP Revenue Accounting and Reporting and Its Architecture

For instance, under IFRS 15, Telcos need to allocate revenue based on the Relative
Standalone Selling Price of a handset and the monthly service plan. In many cases, this would
result in the company allocating some of the revenue that is currently associated with the
service to the handset. In addition, IFRS 15 compliance could result in different revenue
amounts being allocated to the same or similar monthly service plans. To achieve this
requires the integration of enormous amounts of data from diverse sources that most likely
are not aligned or integrated today.
The following example illustrates this based on an example of a Multiple Element
Arrangement with allocation of transaction price:
A Telco company sells a mobile phone for 20,- CU, if the customer enters into a service
contract for 24 months with a monthly charge of 20,- CU.
The mobile phone would be sold alone for 360,- CU. Customers can enter a similar service
contract without buying a phone with a monthly charge of 10,- CU (that is, total charge 10,-
CU * 24 = 240,- CU).
The total transaction price of 20,-CU + 24 * 20,- CU = 500,- CU is allocated to the mobile
phone and to the service proportionately to their respective Standalone Selling Price.
Allocated price of mobile phone = Standalone Selling Price of mobile phone / (sum of all
Standalone Selling Prices) * complete transaction price = 360,- CU / 600,- CU * 500,- CU =
300,- CU.
Allocated price of service = 240,- / 600,- * 500,- = 200,-
Revenue for the mobile phone is recognized at delivery of the phone in period 1. Revenue for
the service is recognized evenly spread over the duration of the contract of 24 months.
Figure 2: History of Revenue Recognition Standard
The introduction of the new revenue standard has been a long and thorough process and the
governing body has taken into account comments from many different sources such as filers,
preparers, and analysts.
An important point is that this standard replaces all the industry-specific standards in US
GAAP that is, SOP 97-2, EITF 0801. This standard is relevant for all contracts. The industries
most affected are technology, high tech, and Telcos.
The final standard of IFRS 15 was published on May 28, 2014 and the effectivity date was
January 1, 2018.
Unit 1: Overview and Architecture

Revenue Recognition Approaches
Figure 3: 5-Step Model of Revenue Recognition in IFRS 15
The figure, 5-Step Model of Revenue Recognition in IFRS 15, outlines a 5-step model of
revenue recognition.
1. Identify the contract with a customer. SAP Revenue Accounting and Reporting can
combine items from different operational contracts from different operational
applications in one revenue accounting contract. The contract is the level for
determination and allocation of the transaction price.
2. Identify the separate performance obligations in the contract. The performance obligation
(POB) is the level where the standalone selling price (SSP) is defined, where the price is
allocated, and the fulfillment (for example, PoC) is determined. It corresponds to an item
of an operational contract, but it can also be a combination of several items, for example,
from a sales bill of material (BoM), or an implicit obligation (customer right for software
upgrade).
3. Determine the transaction price. The transaction price is determined from pricing
conditions of the operational items. It cannot be maintained within Revenue Accounting.
4. Allocate the transaction price to the separate performance obligations in the contract. The
transaction price is allocated to the distinct POBs of a contract on a Relative Standalone
Selling Price basis.
5. Recognize revenue when (or as) a performance obligation is satisfied. Revenue is
recognized at the satisfaction of a POB. Satisfaction can be a defined fulfillment event (for
example, goods issue) or over time. Over time fulfillment can be calculated time-based or
based on percentage of completion (PoC).

Figure 4: SAP Existing Approaches to Revenue Recognition
Within the SAP solution portfolio, there are existing approaches to recognize revenues, such
as SD Revenue Recognition or Results Analysis as part of Cost Object Controlling.
SD Revenue Recognition allows:
For sales from stock scenarios to recognize revenue based on defined events.
For service contracts to recognize revenue spread straight line over the duration of a
billing plan.
Results Analysis allows recognition of revenue based on a percentage of completion that
can be calculated with different methods (for example, based on actual costs and total
planned revenue/planned cost.)
Figure 5: Current Revenue Recognition in Sales and Distribution

Even without SAP Revenue Accounting, SD revenue accounting offers an integrated revenue
recognition solution based on SD documents.
With SD Revenue Recognition, invoices are not posted to revenue but to accounts for
deferred revenue or unbilled receivables.
Defined fulfillment events (goods issue, proof of delivery, and so on) post revenue against
deferred revenue or unbilled receivables (depending on previous balance of recognized
revenue and invoiced amounts).
Service revenue can be recognized over defined periods of time separate from the billing plan.
Recognized revenue is also passed to Profitability Analysis (CO-PA).
The following are the pain points of the existing SD Revenue Recognition:
Pain Points of Existing SD Revenue Recognition
No Multiple Elements Arrangements
- SD Revenue Recognition does not offer an allocation of the transaction price.
- Revenue is recognized separately for every SD order item according to its pricing
conditions.
No Parallel Accounting
- SD Revenue Recognition cannot manage different accounting principles.
- With New GL, SD Revenue Recognition always posts to ledger group blank, that is, to all
ledgers at the same time and with the same amount.
Cost Recognition
- Costs of goods sold is recognized and synchronized with revenue (that is, at the same
event). SD can only recognize all costs either at goods issue or at billing.
Disclosures
- IFRS 15 requires new disclosures, especially around contract balances.
Figure 6: SD Revenue Recognition - Upgrade to SAP S/4HANA

Frequently asked questions around SD Revenue Recognition and IFRS 15 are addressed in
note 2341717.
SAP Revenue Accounting and Reporting Features
Main Functionalities of SAP Revenue Accounting and Reporting
Revenue Accounting Decoupled from Operational Application(s)
- Revenue Accounting is an add-on to ERP Financials with an open interface to
operational applications.
Multiple Element Arrangements
- Allocate transaction price to distinct items of a contract.
- Combine items from different operational contracts into one contract.
- Combine items from different operational applications.
Parallel Accounting
- Revenue Accounting can manage all data and valuations separately for parallel
accounting principles.
- Parallel accounting principles can post to different ledgers in New GL or to different
accounts.
SAP Revenue Accounting and Reporting was built from the ground up to handle the new
revenue recognition regulations announced on May 28, 2014 (IFRS 15 & ASC 606) and are
effective from January 1, 2018 in countries adhering to both US GAAP and IFRS.
The solution automates the revenue recognition and accounting processes, and simplifies the
tasks of revenue accountants following the new accounting guidelines published May 28,
2014.
Figure 7: Step 1 of the 5-Step Model: Identify the Contract with a Customer
In step 1, an entity has to identify the contract or contracts with a customer.

Operational contracts can be combined, either by rules in a custom-specific BAdI
implementation or manually within SAP Revenue Accounting and Reporting. It is also possible
to split items of an operational contract to different revenue accounting (RA) contracts.
Tracking and checking legal contracts and combining them to revenue accounting contracts
is a challenge. Another challenge is the probability that the entity collects the consideration,
or handles contract modifications, for example, do they lead to a prospective or retrospective
change?
Figure 8: Step 2 of the 5-Step Model: Identify Separate Performance Obligations
In step 2 an entity has to identify the separate performance obligations in the contract. The
performance obligation is the level where the Standalone Selling Price (SSP) is defined, where
the price is allocated and the fulfillment (POC) is determined.
If a customer can benefit from the separate lower level items of a sales bill of material (BoM)
on their own, then every item corresponds to a separate distinct POB.
If a customer cannot benefit from the separate lower level items of a sales BOM on their own,
then the BOM as a whole corresponds to one POB, as outlined in the scenario for the
smartphone pack. An indicator as to whether a customer can benefit from the separate items
on their own can be whether they are also sold on their own.
If the lower level items correspond to distinct POBs, then any events on the higher level items
are broken down to the separate POBs.
If the BOM as a whole corresponds to one POB, but the lower level items of the BOM are
relevant for delivery or billing, then special non-distinct POBs are created in the RA contract.
Events on the lower level items are then aggregated on the higher level "compound" POB.
SAP Revenue Accounting and Reporting can create separate linked POBs for implicit
obligations that are not included as explicit items in the operational contract. These POBs
always have to be linked to a leading POB that corresponds to some operational item. For
example, the right for upgrades or maintenance without explicit charge.

Figure 9: Steps 3 and 4 of the 5-Step Model: Determine and Allocate the Transaction Price
In steps 3 and 4, an entity has to determine the transaction price and allocate the transaction
price to the separate POBs in the contract.
From SD orders, all pricing conditions are transferred to SAP Revenue Accounting and
Reporting and summed up to the transaction price. The transaction price can only be
maintained via conditions in the operational contract (or invoice).
After a complete delivery and final invoice, the transaction price must be equal to the total
invoiced amount in the operational application.
The SSPs for allocation can be delivered by a special condition from the operational
application, or they can be maintained (or uploaded) in BRFplus in SAP Revenue Accounting
and Reporting.
Figure 10: Step 5 of the 5-Step Model: Recognize Revenue When (or as) POB is Satisfied
In step 5, the entity has to recognize revenue when or as it satisfies the performance
obligation (POB).

A POB can have an event-based or time-based fulfillment type.
For event-based, possible event-types are:
Goods issue
Invoice
Manual fulfillment (manual input of Percentage of Completion)
For time-based fulfillment, the start date and duration, or end date, can be transferred from
the operational item or maintained manually in SAP Revenue Accounting and Reporting.
SAP Revenue Accounting and Reporting Integration
Figure 11: Integration of Operational Sales and Billing Applications
Revenue Accounting is decoupled from operational sales and billing applications. Data from
different operational applications can be transferred into Revenue Accounting.
It is an add-on to ERP Financials and a sub-ledger of Financials. This aspect is important as
Revenue Accounting holds its own sub-ledger table for postings.
Revenue Accounting utilizes BRFplus, which is a flexible rules framework that is used to define
rules for the transformation of operational items (such as SD orders) into contracts and
performance obligations according to the revenue standard.
Once contracts have been processed, Revenue Accounting creates postings in FI-GL and CO-
PA.

Figure 12: Decoupling of Operational Sales and Billing Applications
Another aspect of the decoupling between operational applications and Revenue Accounting
is that the operational process continues to work in general independently from Revenue
Accounting.
Revenue Accounting reacts to certain events such as order creation or change, goods issue
and invoice and processes these events according to the revenue recognition regulations.
SAP Revenue Accounting and Reporting Architecture Components
Figure 13: SAP Revenue Accounting Architecture: Building Blocks

To support the process flow in operational applications, an Integration Component (IC)
creates Revenue Accounting Items (RAIs) and sends them to SAP Revenue Accounting and
Reporting.
An RAI contains all of the data from the operational items and events that is relevant for
revenue accounting.
The structure of RAIs can be configured in SAP Revenue Accounting and Reporting separately
for different operational applications.
SAP provides Integration Components for several operational applications such SAP Sales
and Distribution, SAP Customer Relationship Management Service, and SAP Billing and
Revenue Innovation Management (Convergent Invoicing and Financials Contract Accounting).
However, customers can feed SAP Revenue Accounting and Reporting from external, non-
SAP components.
The Adapter Reuse Layer (ARL) of SAP Revenue Accounting and Reporting receives RAIs, and
transforms them into revenue accounting contracts (RA) and Performance Obligations
(POB)s.
Rules for transformation can be defined in the Business Rules Framework plus (BRFplus).
The following items are components of the SAP Revenue Accounting and Reporting engine:
Contract Management to calculate the price allocation
Process Management that offers manual processing
Invoice Management to calculate the effects from invoices
Fulfillment Management that determines recognized revenue from fulfillment events
Posting Management that creates postings of recognized revenue and invoice corrections
Accrual Run that creates postings in FI-GL and CO-PA
Data Provisioning to extract data into BI
Figure 14: Adapter Reuse Layer Architecture

The figure, Adapter Reuse Layer Architecture, takes a closer look at the architecture of the
ARL. A Revenue Accounting Item (RAI) is a subset of an item in an operational system. It must
contain all of the data that is relevant for SAP Revenue Accounting and Reporting.
Each sender component defines this subset on its own through the configuration of an RAI
class. The subset (RAI) can be configured in a framework (similar to the BIT management
from SAP Billing and Revenue Innovation Management). Based on this subset definition, the
framework allows the generation of a persistence for the RAIs (in other words, the
corresponding database tables) and an RFC-enabled function module for RAI creation (plus
access methods, structures, indexes, and so on).
SAP Revenue Accounting and Reporting allows the configuration and processing of order
items, invoice items, and fulfillment items.
Processing of the RAIs is agnostic of the sender components, which means that all further
process steps are not specific per operational system.
In RAI transfer and RAI processing, RAIs from all sender components are transferred and
processed at once.
In RAI processing, several BRFplus rules are executed. Examples are the creation of additional
POBs or SSP determination. Once an order RAI has been processed, an RA contract is
created. The link between the RAIs and the created POBs is stored in a mapping table.
RAI monitoring allows the monitoring of erroneous RAIs. It is also possible to transfer and
process RAIs.
Figure 15: Business Rules Processing to Transform Operational Items into Contracts and POBs
Customers can configure rules for the different steps of transformation from RAIs to RA
contracts and POBs.
In a BAdI, customers can determine automatic combination of operational contracts (or items
of operational contracts) to one RA contract.
In BRFplus rule sets, customers can define rules to determine:
Which operational items are managed as distinct POBs.
Specific attributes of a POB (can also be defaulted from a POB type)

Creation of linked POBs for implicit obligations
The Standalone Selling Price can be maintained in BRFplus or they can be uploaded into
BRFplus. It can also be sent with special condition types from the operational application.
For special clauses, additional POBs can be created from defined special condition types.
BRFplus data can be dependent on accounting principle. Other data does not depend on
accounting principle.
Figure 16: Revenue Accounting Engine Architecture
In addition, the SAP Revenue Accounting and Reporting engine uses the following
components and functionalities:
User interface based on Web Dynpro ABAP with Floor Plan Manager and Personal Object
Work List (POWL) for error and review work lists
Invoice and fulfillment management calculates data for posting
Accrual run creates aggregated actual postings to FI-GL and CO-PA
Reconciliation explains aggregation of posting data into postings
Data provisioning offers data sources for legal reporting and analytics
SAP Revenue Accounting and Reporting Deployment Options

Figure 17: Deployment Options - Integrated System
The installation prerequisites are listed in the administrators guide. It is SAP ERP 605 as a
minimum release for revenue accounting and SAP ERP 600 for the SD integration
component.
Figure 18: Deployment Options - Multiple Systems
The installation prerequisites are listed in the administrators guide. It is SAP ERP 605 as a
minimum release for revenue accounting and SAP ERP 600 for the SD integration
component.
Please note that you have to migrate from SD-based revenue recognition to SAP Revenue
Accounting and Reporting before you upgrade to SAP S/4HANA.
Revenue Accounting Differences to Sales and Distribution

Figure 19: Integration of Sender Systems
Note:
You can find further information about external system-required fields in unit 2.
Figure 20: More Information
LESSON SUMMARY
You should now be able to:
Accounting

Unit 1
Learning Assessment
1. Which sender components are supported by SAP Revenue Accounting and Reporting?
Choose the correct answers.
X A Sales and Distribution
X B Customer Relationship Management (CRM)
X C SAP Flexible Real Estate Management
X D SAP Billing and Revenue Innovation Management
X E External systems
2. What are the main features of SAP Revenue Accounting and Reporting?
X A Decoupling from the operational system
X B Supporting multiple element arrangements
X C Parallel accounting
3. Which of the following statements about SAP Revenue Accounting and Reporting are
true?
X A SAP Revenue Accounting and Reporting is an add-on, which runs on SAP ERP 6,
EHP 5 or higher, SFINANCIALS, or SAP S/4HANA.
X B SAP Revenue Accounting and Reporting has a separate license fee.
X C Cost object controlling can only run on the same instance as SAP Revenue
Accounting and Reporting (if it is integrated with revenue accounting).

Unit 1
Learning Assessment - Answers
1. Which sender components are supported by SAP Revenue Accounting and Reporting?
X A Sales and Distribution
X B Customer Relationship Management (CRM)
X C SAP Flexible Real Estate Management
X D SAP Billing and Revenue Innovation Management
X E External systems
You are correct. Apart from SAP Flexible Real Estate Management, all components are
supported.
2. What are the main features of SAP Revenue Accounting and Reporting?
X A Decoupling from the operational system
X B Supporting multiple element arrangements
X C Parallel accounting
You are correct. All of these features are supported by SAP Revenue Accounting and
Reporting.
3. Which of the following statements about SAP Revenue Accounting and Reporting are
true?
X A SAP Revenue Accounting and Reporting is an add-on, which runs on SAP ERP 6,
EHP 5 or higher, SFINANCIALS, or SAP S/4HANA.
X B SAP Revenue Accounting and Reporting has a separate license fee.
X C Cost object controlling can only run on the same instance as SAP Revenue
Accounting and Reporting (if it is integrated with revenue accounting).
You are correct. SAP Revenue Accounting and Reporting has no separate license fee.

UNIT 2 Integration with Sender
Components
Lesson 1
Understanding the Integration of SAP Revenue Accounting and Reporting with Sales and
Distribution (SD)
22
Lesson 2
Understanding the Integration of SAP Revenue Accounting and Reporting with SAP Customer
Relationship Management
40
Lesson 3
Explaining the Integration with SAP Billing and Revenue Innovation Management 52
Lesson 4
Understanding the Integration with External Systems 64
UNIT OBJECTIVES
List the main tasks of the integration component
Explain how document chains work
Understand supported Sales and Distribution processes
Desribe the customizing and enhancement options
Understand the basic architecture of CRM processes and modules
Explain the setup for creating Revenue Accounting Items from the CRM service
Select the appropriate release, enhancement package, and support package
Explain how order item Revenue Accounting Items are created from CRM Service
Explain how invoice item Revenue Accounting Items are created from CRM Service
Describe in which process step the SD Integration Component is used
List the components required for integration with SAP Billing and Revenue Innovation
Management
Understand how consumption-based revenue is generated

Understand the integration of revenue accounting with an external system
Understand deployment options

Unit 2
Lesson 1
Understanding the Integration of SAP Revenue
Accounting and Reporting with Sales and
Distribution (SD)
LESSON OBJECTIVES
SAP Sales and Distribution Integration Component
Figure 21: Main Tasks
The Sales and Distribution (SD) integration component listens to SD events and sends
revenue recognition relevant information as "Revenue Accounting Items" (RAI) to the SAP
Revenue Accounting and Reporting module. To integrate SAP Revenue Accounting and
Reporting with SD in Customizing you have to select the checkbox that activates the
integration component and maintain your RFC destination (Customizing: Sales and
Distribution Revenue Accounting and Reporting Integrate with Revenue Accounting ). If
you use the same system, you can select None.

The integration component sets reference ID and type to determine which RAI items should
be in one revenue accounting contract. By default, the reference ID is set to the order number,
which leads to the creation of one revenue accounting contract for each SD order. The
reference ID can be changed in a customer exit.
Dependent on sales organization, document type, and document item category an item can
be marked as relevant for revenue recognition. This activation cannot be entered manually
and cannot be changed once the order is saved and subsequent documents are created. RAIs
are created for items only relevant for revenue recognition and passed to the SAP Revenue
Accounting and Reporting module.
If a sales order is relevant for SAP Revenue Accounting and Reporting data from the sales
order is mapped to the revenue accounting contract, such as dates.
Specific customizing settings, such as account determination, as well as scenarios, such as
billing plans, are discussed along the training course.
SAP Sales and Distribution Document Chains
Figure 22: Evaluation of References
The Sales and Distribution (SD) copy routines have to be set up so that the activation is
copied to follow on documents.
The SAP delivered copy routines Order Goods Issue and Order/Goods Issue to Invoice have
been extended so that the activation flag is passed to the subsequent document.
SAP Sales and Distribution Processes
Note:
Additional scenarios such as drop shipment or inter company processes have
been enabled in the latest feature packs. See SAP Note 2591055 - Functional
limitations in the SD Integration Component - for the currently supported
scenarios.
The following list outlines the supported business scenarios using the Sales and Distribution
(SD) Integration component:
Lesson: Understanding the Integration of SAP Revenue Accounting and Reporting with Sales and Distribution (SD)

Supported Scenarios
Order/contract related billing
Delivery related billing
Return order
Planned Invoices for periodic/milestone billing plans
Credit/debit memo w/o reference to sales order …
Scheduling Agreements
Different Currencies
Exclusion of Billing Plan Items
Performance Obligation Cancellation
Supported Scenarios: Delivery Related Billing
Figure 23: Supported Scenarios: Delivery Related Billing
Using transaction VA01, a sales order is created with a relevant item for SAP Revenue
Accounting and Reporting.
The next step consists of the creation of the delivery (transaction VL01N). By posting the
goods issue, the Accounts Receivable Ledger (ARL) receives a fulfillment Revenue
Accounting Item (RAI) and the Performance Obligation (POB) is fulfilled in the revenue
accounting contract. Once completed, revenue can be recognized.
The invoice is created (transaction VF01). Therefore, the delivery number provided in the
previous step is relevant. The values of the invoice are transmitted to the revenue accounting
engine and stored in the POB.
Unit 2: Integration with Sender Components

Supported Scenarios: Return Order
Figure 24: Supported Scenarios: Return Order
The return order is created with reference to the sales order. When a return order RAI, which
is linked to a predecessor document item, is processed, the result of the aggregation leads to
a change of the already available POB.
A return order item only reduces the quantity and the amounts of the referenced sales
document item. Therefore, the return delivery and/or the negative goods issue reduce the
fulfilled quantity of the POB. Based on the return order, a return delivery is created and a
negative goods issue is posted. The quantity of the predecessor POB is updated. To finalize
the return process, a credit memo is created and sent to SAP Revenue Accounting and
Reporting. The credit memo reduces the invoiced quantity and the invoiced amounts. The
result leads to a contract change and it is sent to contract management. SAP Revenue
Accounting and Reporting is able to handle negative fulfillment values that result from the
return order.
Supported Scenarios: Planned Invoices for Periodic/Milestone Billing Plans
Figure 25: Supported Scenarios: Planned Invoices for Periodic/Milestone Billing Plans
Using transaction VA01, a sales order is created with a relevant item for SAP Revenue
Accounting and Reporting (which includes a milestone billing plan). In the operational
application, the IC creates an RAI that contains all of the data from the operational items and
events that are relevant for SAP Revenue Accounting and Reporting. For an item with a

periodic/milestone billing plan, only one corresponding POB in contract management is
created.
Contracts are created for each active accounting principle in SAP Revenue Accounting and
Reporting. In this scenario, one RA contract with one POB (hardware) is created for one
accounting principle (IFRS).
After each stage/period of the project is completed, you can bill the customer for a certain
total value. POB is now partly fulfilled and revenue is recognized according to the percentage/
period of the project that has been completed based on the customer invoice.
Supported Scenarios: Credit/Debit Memo with Reference to Sales Order
Figure 26: Supported Scenarios: Credit/Debit Memo with Reference to Sales Order
A credit/debit memo request is created with a relevant item for SAP Revenue Accounting and
Reporting. In the operational application, the IC creates an order RAI that contains all of the
data from the operational items and events that are relevant for SAP Revenue Accounting and
Reporting.
If you set the relevant type as M (debit/credit note with reference to predecessor) in
customizing, the debit/credit note does not create a separate POB. The invoice of the debit/
credit note updates the transaction price of the corresponding POB (the corresponding RAI is
value relevant).

Supported Scenarios: Credit/debit Memo w/o Reference to Sales Order
Figure 27: Supported Scenarios: Credit/debit Memo w/o Reference to Sales Order
A credit/debit memo request is created with a relevant item for SAP Revenue Accounting and
Reporting. In the operational application, the IC creates an order RAI that contains all of the
data from the operational items and events that are relevant for SAP Revenue Accounting and
Reporting.
Contracts are created for each active accounting principle in SAP Revenue Accounting and
Reporting. There you can decide how to proceed with the POB based on the credit/debit
memo request. For example, you can combine it with another revenue accounting contract.
The next process step consists of the creation of the credit/debit memo. The ARL receives an
invoice RAI and the value of the memo is transmitted to the revenue accounting engine and
stored in the negative/positive POB invoice. Once this is completed, revenue can be
recognized in the revenue schedule. However, revenue postings are not made at the time of
the event.
SAP Sales and Distribution Processes
To trigger the creation of performance obligations, the Sales Area/Item Category
combination used in the scheduling agreement needs to be customized as Relevant for
Revenue Accounting.
Business processes with external agent and self billing processes are not supported.
Support of Scheduling Agreements Follow-on Documents
Delivery
Invoice, Credit Memo, Debit Memo
Credit Memo Request, Debit Memo Request
Return Order
Cancellation of Delivery, Invoice, Credit Memo, Debit Memo
Supported Scenarios: Service Acceptance
Supported Scenarios: Service Acceptance
A goods issue can be created for non-stock materials without material movement or material
document. In the document flow, these goods issues display as Service Acceptance.

Functionality was added to create fulfillments in the SAP Revenue Accounting And Reporting
module for service acceptance documents. These fulfillments do not carry costs.
Figure 28: Supported Scenarios: Transfer Future Milestone Billing Plan
A future milestone billing plan can be transferred to SAP Revenue Accounting and Reporting
by activating the corresponding configuration.
Go to IMG Sales and Distribution Revenue Accounting and Reporting Activate Functions
to Integrate with Revenue Accounting
Figure 29: Supported Scenarios: Exclusion of Billing Plan Items
For some business processes, billing plan items are permanently blocked for billing and no
billing documentation is created for these billing plan items.
For example, in a First Month Free deal the first month of a billing plan might be permanently
blocked for billing. These billing plan periods can be excluded from processing in the SAP
Revenue Accounting And Reporting module.
The value of the billing plan item is not transferred and no planned invoice items are created.
Setting the attribute excluded from SAP Revenue Accounting and Reporting for a billing block
only has an effect if the billing block is used in a billing plan item. It does not affect the
processing if a billing block is used on sales order items or the sales order header.
If such a billing block is set for a billing plan item, the value of the billing plan item is
subtracted from the value of the POB.

For example, the order item has three billing milestones $100, $200 and $300. If the first
milestone has a permanent billing block, the value of the POB created for the order item is
$500.
Figure 30: SAP Sales and Distribution Processes
Invoice documents can be created in a different transaction currency than the currency
referenced in the sales/ service document.
SAP Revenue Accounting and Reporting expects that the invoice events are passed with the
same transaction currency as the related POB.

The handling of supported processes must be distinguished between Invoice RAI/Legacy RAI
created by SD Operational Load, and Invoice RAI created by already active revenue
accounting (during the accounting document creation).
1. Due to the summation of the legacy revenue values, the SD operational load converts the
currency information.
2. Invoice documents with active revenue accounting can be handed over with divergent
currency information. The conversion is carried out during inbound processing.
In both SD operational load and inbound processing, the BAdI FARRIC_BADI_INVOICE
method CONVERT_INVOICE_CURRENCY is called, which performs the conversion.

The referenced revenue accounting contract is created based on the sales order currency.
Both the sales order and the revenue accounting contract have the same currency.
The sales order and invoice are created in Euro. The credit memo request is created in USD,
and is customized with reference to its predecessor.
Based on the customizing, no new revenue accounting contract is created. The revenue
accounting contract is based on the sales order item currency and is also relevant for the
credit memo values.
Inbound processing converts the transaction value from USD to EUR.

During inbound processing, the transaction value from the credit memo is converted from
USD19.90 to EUR19.10. The local currency amounts stay unchanged.
The conversion date is the translation date from the SD Invoice RAI. If the translation is initial,
the posting date from the SD Invoice RAI is relevant.

Exchange rates from the accounting document are substituted as they are related to the
transaction currency of the invoice.
First local currency EUR:
- Ex.rate accounting document 0,96000 19,90 USD x 0,96000 = 19,10 EUR
- Ex.rate Inbound processing 1,00000 19,10 EUR x 1,00000 = 19,10 EUR
Second local currency HKD:
- Ex.rate accounting document 7,90000 19,90 USD x 7,90000 = 157,21 HKD
- Ex.rate Inbound Processing 8,22927 19,10 EUR x 8,22927 = 157,21 HKD
Third local currency USD:
- Ex.rate accounting document 1,00000 19,90 USD x 1,00000 = 19,90 USD
- Ex.rate Inbound Processing 1,04168 19,10 EUR x 1,04168 = 19,90 USD
The exchange rates from the second and/or third local currency are newly determined
depending on the related source currency customizing. (Transaction OB22).
If the source currency customizing has the value 1(translation taking transaction currency as
a basis) the inbound processing determines the inverted exchange rate.
If the source currency customizing has the value 2 (translation taking first local currency as a
basis) the inbound processing determines no new exchange rates.

Based on the inbound processing, SAP Revenue Accounting and Reporting calculates
invoiced amounts in the referenced currency EUR from the sales order 25989.
Figure 37: Supported Scenarios: Performance Obligation Cancellation
A contract with a customer is completely fulfilled or the operational document is changed to
reflect contract changes.
However, in some scenarios a change of the operational document is not needed and the
performance obligations created for that operational document need to be canceled. For
example, if a customer calls to cancel a partially fulfilled contract, the operational document is
typically only flagged as canceled or no further delivery without changing the order.
In this case, the POB can be canceled by passing a finalization date to the POB. At the
finalization date the following values are adjusted:

Contractual value of the POB is set to the invoiced amount. The invoiced amount is the
sum of billing, credit memo, and debit memo documents posted when the POB is
canceled. Documents with future posting dates are also taken into account in this
calculation.
The fulfillment is set to 100%.
The unbilled receivables amount is zero for a fully invoiced POB. If all POBs in a contract are
canceled, the contract liability and contract asset calculate to zero. The rejection reason is
always on the item level.
Figure 38: Performance Obligation Creation for Billing Documents
For SD-Contract items or SD-Order items, POBs are created. However, for special processes
like migrated SD documents it can be helpful to create POBs for billing documents.
In this process, a billing document item creates a POB and at the same time an invoice event
from a billing item.
Operational load for POBs created from billing items is not supported in REVRECSD support
pack 8 (minimum SP level for release 1.2).
SAP Sales and Distribution Enhancement Options

Figure 39: Customizing - Performance Obligation Creation for Billing Documents
The creation of a POB for billing document items can be activated dependent on sales
organization, billing type, and item category in a customizing view.
The activation can be cleared in the BADI FARRIC_BADI_INVOICE method
CLEAR_RELTYPE_FLAG dependent on the following field values:
Billing Type
Sales Organization
Distribution Channel
Division
Company code to be billed
Sales document item category
Material Number
Even if the billing item is activated for revenue accounting, no POB is created if a predecessor
document like SD-Order item did already create a POB.
The Migration Package field has no functionality.

Figure 40: Customizing
In the Maintain Revenue Accounting Item Settings IMG node, you can determine the order
items are to be transferred to SAP Revenue Accounting and Reporting. The subsequent
documents in the document chain are forwarded.
In BAdI FARRIC_BADI_ORDER, you can clear the relevance of an order item for revenue
accounting if required.
For credit or debit memo requests with referencing an order, they can be customized if a new
POB is created or not. If you select type Credit/Debit Memos with reference , no new POBs are
created for the credit/debit memo. The order POB is updated by the credit/debit memo.
There are many SD processes used in different ways. Examples are:
Stock in transit
Consignment stock
Intercompany processes
Call-off orders
And others
You may want to check if these processes can be supported in SAP Revenue Accounting and
Reporting according to your specific business requirements.
Figure 41: Customizing Additional Features

Further aspects of the integration are explained in the invoice lesson.
Figure 42: Enhancements
BAdI: Sales Order Processing Enhancements:
- Method ORDER_DATA_TO_ARL:You can modify some values in standard fields during
transfer to Revenue Accounting
- Method ORDER_DATA_TO_ARL_CUSTOM:You can modify some values in customer
specific fields.
- Method CLEAR_RELTYPE_FLAG:You can clear the relevance of an order item for
Revenue Accounting
- Method DETERMINE_MIG_PACKAGE:You can overwrite the migration package ID
determined from Customizing
- Method EXCLUDE_CONDITIONS: The specified conditions are not transferred to
Revenue Accounting.
BAdI: Delivery Processing Enhancements:
- Method EXCLUDE_CONDITIONS: Determine conditions that are not transferred:
- Method DELIVERY_DATA_TO_ARL_CUSTOM:You determine additional fields
transferred to inbound processing.
BAdI: Invoice Processing Enhancements:
- Method INVOICE_DATA_TO_ARL:You can modify some values in standard fields.
- Method INVOICE_DATA_TO_ARL_CUSTOM:You can modify some values in customer-
specific fields.
- Method EXCLUDE_CONDITIONS: The specified conditions are not transferred to
Revenue Accounting
- Method CLEAR_RELTYP_FLAG:You can clear the relevance of an order item for
Revenue Accounting.
BAdI: Legacy Data Attributes
- You can modify legacy data required in migration.

LESSON SUMMARY

Unit 2
Lesson 2
Understanding the Integration of SAP Revenue
Accounting and Reporting with SAP Customer
Relationship Management
LESSON OBJECTIVES
SAP Customer Relationship Management (CRM) Architecture and Processes
Figure 43: Integration of Service Contracts into SAP Revenue Accounting and Reporting and Reporting
You can connect SAP Customer and Relationship Management (CRM) powered by SAP
HANA to SAP Revenue Accounting and Reporting.
The integration takes place from SAP CRM powered by SAP HANA via SAP ERP to SAP
Revenue Accounting and Reporting and Reporting. If you bill the CRM service business
transaction in SAP ERP SD, the SD integration components must then be installed for revenue
accounting (add on component REVRECSD in the ERP system).

You can set up the CRM integration for periodically billed contracts. An example of time-
related revenue recognition is a contract where the customer gets an invoice for the product
with the help of a periodic billing plan. The contract covers 12 periods and a total amount of
€12,000. This means that over 12 periods, €1,000 is generated per contract period.
Service contracts are often used as periodically billed contracts. However, the point in time of
the service consumption is different.
It is also possible that the scheduled contract invoice periods in the billing plan differ from the
fiscal periods, for example, if the contract invoices are triggered quarterly and the fiscal
periods are defined on a monthly basis. In this case, the corresponding revenues accrue in
different portions and in different periods of the fiscal year. This results in an unbalanced
periodical result.
Based on the following data of the service contract, it is possible to transfer the revenue
recognition data into SAP ERP:
Start date
End date
Billing plan
Figure 44: Integration of CRM Service Contracts into SAP Revenue Accounting and Reporting and Reporting with
SD Billing in SAP ERP
The SAP CRM powered by SAP HANA service integration into SAP Revenue Accounting and
Reporting considers the service contract as the core object for identifying the contract with a
customer.
From the SAP CRM powered by SAP HANA service application, the revenue-accounting-
relevant information is sent to SAP Revenue Accounting and Reporting in the appropriate
format for order items.
From the SD invoicing module, the revenue-accounting-relevant information is sent to SAP
Revenue Accounting and Reporting in the appropriate format for invoice items.
In the revenue accounting process flow, operational information is transformed into revenue
contracts and performance obligations. The performance obligations are allocated
considering standalone selling prices, and the resulting revenues for fulfilled performance
obligations are recognized and posted into the general ledger.
Lesson: Understanding the Integration of SAP Revenue Accounting and Reporting with SAP Customer Relationship Management

Figure 45: Integration of CRM Service Contracts into SAP Revenue Accounting and Reporting with CRM Billing
Alternatively, you can use the CRM Billing engine to send revenue-accounting-relevant
information to SAP Revenue Accounting and Reporting in the appropriate format for invoice
items.
The following list outlines the prerequisites for this integration:
You utilize the CRM Service application and use business transactions of the following
types:
- Service contract
- Service order and service confirmation
- Product package service order quotation
You have activated business functions and the following in each system:.
- CRM_SRV_REVACC_4 (CRM Service: SAP Revenue Accounting and Reporting in
enhancement package 4) in the CRM system.
- CRM_SRV_REVACC_ERP_8 (CRM Service: SAP Revenue Accounting and Reporting
Integration) in the ERP system.
You set up accounting integration for CRM service business transactions in ERP.
You can bill CRM service business transactions (by means of the Billing Engine) and have
set up the corresponding accounting interface in SAP ERP, or you bill CRM service
business transactions in ERP SD and set up this interface in SAP ERP.

Integration of CRM Package Quotations into SAP Revenue Accounting and Reporting
Figure 46: Integration of CRM Package Quotations into SAP Revenue Accounting and Reporting
In a CRM package quotation, bundles or solutions are offered and sold to customers. Bundles
can consist of various types of products (physical, non-physical) which lead to various types
of items within a package quotation:
Sales quotation items for the selling process of the physical product
Service quotation items for the installation of the physical product
Service contract quotation items for the maintenance of the physical product over a given
period of time.
If this type of quotation is accepted, different operational transactions are created from the
package quotation to trigger the corresponding processes:
Sales quotation items lead to the creation of a sales order with a corresponding sales item.
Service quotation items lead to the creation of a service order with a corresponding service
order item. Service contract quotation items lead to the generation of a service.
SAP CRM powered by SAP HANA sales orders are replicated to SAP ERP as SD orders and
integrated into SAP Revenue Accounting and Reporting in the same way as an SD order that
was created in SAP ERP.

Figure 47: Integration of CRM Package Quotations into SAP Revenue Accounting and Reporting with SD Billing
The CRM package quotation is a transaction that can be used to offer different kinds of
products and services. Depending on the kind of product, several different follow-up
documents of a package quotation can be created to fulfill the content of the quotation.
During the integration into SAP Revenue Accounting and Reporting of documents that
contain items of different object types, all items must lead to the same revenue accounting
contract. To achieve this, a new logic is implemented, which determines a reference number
and a reference type right at the beginning of the process. This is done to collect all of the
items that belong together into one revenue accounting contract, although the items are
distributed across different systems after creation.
The CRM Service application sends all relevant revenue accounting information during the
creation or change of the CRM service contract and service order.
To use the provided SD integration component, the SD add-on REVRECSD must be installed
in the related SAP ERP system. The SD integration component is used for the creation or
change of debit memos that are related to a service contract item, a service order item, or a
service confirmation item. SD Billing sends the related invoice information. The SD integration
component is also used during the creation or change of SD sales orders, deliveries, and
invoices triggered by the package quotation creation.
Based on the sales order item, the order-relevant information is sent to SAP Revenue
Accounting and Reporting. During the goods issue posting, the relevant fulfillment
information is determined and then forwarded to SAP Revenue Accounting and Reporting. As
soon as the accounting document has been created, the relevant invoice information is sent
to SAP Revenue Accounting and Reporting.

Figure 48: Integration of CRM Package Quotations into SAP Revenue Accounting and Reporting with CRM Billing
Alternatively, the CRM billing module can send the relevant invoice information to SAP
Revenue Accounting and Reporting during the creation of the accounting document.
The related SAP ERP system must have the SD add-on REVRECSD installed to use the
already provided SD integration component. Also, the SD integration component is used
during the creation/change of SD sales orders, deliveries, and invoices triggered by the
package quotation creation.
SAP Customer Relationship Management (CRM) Integration Setup
Figure 49: Overview of CRM Service Supported Processes: Order Revenue Accounting Item Creation
To set up integration, make the following system settings in Customizing for Revenue
Accounting under Inbound Processing :
Under Revenue Accounting Item Management , define logical systems and assign them to
sender component CRS (CRM service) in the Define Sender Components IMG activity.

Under Revenue Accounting Items , create Revenue Accounting Item classes CS01, CS03,
and generate them. The technical names are set by SAP. This ensures that the system
automatically provides the required settings for each class when it is generated.
The Revenue Accounting Item class CS01 defines the technical characteristics of the order
items, and the class CS03 defines those of the invoice items of CRM billing.
The class SD03 defines the technical properties of the invoice items from ERP SD.
You can activate the integration with Revenue Accounting in Customizing for CRM service
business processes in the CRM system.
As a first step, configure the RFC destination to the revenue accounting system, which is the
system that runs SAP Revenue Accounting and Reporting.
SAP Customer Relationship Management Product Details
Figure 50: Set up Integration of CRM Service: CRM Service Specific Part for Activation (1/2)
To set up the integration to CRM Service you first have to activate the business functions
CRM_SRV_REVACC_4 (CRM Service: Revenue Accounting in enhancement package 4) in the
CRM system, and CRM_SRV_REVACC_ERP_8 (CRM Service: Revenue Accounting
Integration) in the ERP system.
Next, configure the RFC destination in the CRM system.

Figure 51: Set up Integration of CRM Service: CRM Service Specific Part for Activation (2/2)
To set up the CRM service process for revenue accounting, make the following settings in
Customizing for Customer Relationship Management under Transactions Settings for
Service Transactions Integration Revenue Accounting Integration Define Relevance
Type for Revenue Accounting .
The relevance type determines whether a business transaction item is relevant for SAP
Revenue Accounting and Reporting. A Revenue Accounting Item is only generated by the
system if the relevance type is set.
You can set the relevance type depending on the following attributes:
Transaction type
Item category
Service organization
Organizational unit (Service)
Sales organization
Organizational unit (Sales)
BAdI: Determine Relevance Type and Reference for Revenue Accounting
You can use this BAdI to set the relevance type and the reference for SAP Revenue
Accounting and Reporting. The relevance type defines whether or not an item is relevant for
revenue accounting.You can use the reference to bundle several business transactions into
one revenue accounting contract.
BAdI: Customer Enhancements for Revenue Accounting
You can use this BAdI to transfer additional standard or customer fields from the CRM system
to Revenue Accounting and Controlling to use them in your business rules. It was extended
for use in the SAP CRM (CRM) service integration into SAP Revenue Accounting and
Reporting. The BAdI is called when items are transferred from the CRM to the revenue
accounting system, using CRM middleware. Method DETERMINE_COSTS is used to extend
data for Revenue Accounting Items (RAIs) and to change and extend their conditions.

Method MAP_BILL_TO_ACCOUNT_REVENUE is used to change, or enrich fields, of the billing
RAIs that the CRM system sends to the SAP ERP system.
Figure 52: Set up Integration of CRM Service: ERP SD Specific Part for Activation
A minimum technical requirement for the integration is the deployment of the add-on
component REVRECSD 1.0 with support package 6.
In SD, configure the corresponding settings to integrate SD with revenue accounting including
activating item categories for the use with SAP Revenue Accounting and Reporting.
For RAIs based on CRM service contract items or service order items, configure the revenue
accounting type M, which refers to credit/debit memos with reference to predecessor.
For RAIs based on SD orders, use revenue accounting type X, which indicates that the item is
relevant for SAP Revenue Accounting and Reporting.
SAP Customer Relationship Management (CRM) Order Items
Figure 53: Set Up Integration of CRM Service: Revenue Accounting "Order Items"

The package quotation itself does not create the RAI. The order RAIs are created by the
service contract item, the service order item, and the sales order item.
The order RAIs are independent and can be transferred to SAP Revenue Accounting and
Reporting independently.
They are linked together with a package quotation number as a reference, and are handled in
one revenue accounting contract.
SAP Customer Relationship Management Invoice Items
Figure 54: Set Up Integration of CRM Service: Invoice Revenue Accounting Item Creation
Depending on the CRM service process, the invoice RAI is created with either CRM billing and
SD debit memo, or an SD invoice.

Figure 55: Invoice Revenue Accounting Item Creation: CRM Billing
For the CRM service contract, the start and end date of the item are transferred to SAP
Revenue Accounting and Reporting.
Based on this information, the revenue schedule is created.
CRM billing transfers the invoice RAI to SAP Revenue Accounting and Reporting with the
creation of the accounting document.
You can use the relevant BAdI CRM_UPLOAD_CO to enhance the data on the Revenue
Accounting Items.
SAP Customer Relationship Management Integration Component
Figure 56: Invoice Revenue Accounting Item Creation: SD Debit Memo

The SD debit memo request item does not create an order RAI.
SD billing transfers the invoice RAI information to SAP Revenue Accounting and Reporting
with the creation of the accounting document.
Figure 57: Invoice Revenue Accounting Item Creation: SD Invoice
For an SD sales order triggered by the CRM package quotation, the SD integration in SAP
Revenue Accounting and Reporting is used.
In case of an event-based set up process, the goods issue posting triggers the fulfillment of
the POB and a fulfillment RAI is created.
The setup of the relevant event is based on BRFplus rules.
The invoice RAI is transferred to SAP Revenue Accounting and Reporting with the creation of
the accounting document.
LESSON SUMMARY

Unit 2
Lesson 3
Explaining the Integration with SAP Billing and
Revenue Innovation Management
LESSON OBJECTIVES
Management
SAP Billing and Revenue Innovation Management Integration
Figure 58: Overview
SAP Billing and Revenue Innovation Management offers an integrated end-to-end operational
process chain for high volume customers such as telecommunication, transportation, or high-
tech customers.
Business scenarios deal with subscriptions of digital content, shipping services, or
communication services, also providing product bundles (multiple element arrangements)
combining hardware and consumption services.

From an SAP Billing and Revenue Innovation Management perspective, the process steps are
handled in the following SAP components:
Order / contract management: SAP Billing and Revenue Innovation Management,
subscription order management
Mediation: SAP Billing and Revenue Innovation Management, mediation by DigitalRoute
Rating & charging: SAP Billing and Revenue Innovation Management, charging
Billing & invoicing: SAP Billing and Revenue Innovation Management, invoicing
A/R SAP Billing and Revenue Innovation Management: customer financials
G/L, Controlling: SAP Financials General Ledger,
Controlling Financial Customer Care: SAP Billing and Revenue Innovation Management,
customer financials
SAP Billing and Revenue Innovation Management components can be launched in flexible
modular deployments.
Requirement and Motivation
The SAP Billing and Revenue Innovation Management solution has to account for the
resulting revenues from contracts with customers compliant to the IFRS15 accounting
standard.
The out-of-box integration between SAP Billing and Revenue Innovation Management and
SAP Revenue Accounting and Reporting 1.1 (RAR) is provided as of SAP ERP 6.0 EHP 7
SP09.
In the overall SAP Billing and Revenue Innovation Management scenario, CRM Sales and
Order Management, Convergent Charging (CC) and Convergent Invoicing (CI)/ Contract
Accounts Receivable and Payable (FI-CA) in ERP are involved.
To serve all possible deployments in SAP Billing and Revenue Innovation Management,
with a non-SAP CRM in place for capturing customer contracts, the decision has been
taken to realize the integration into RAR out of the ERP CI component basically sending the
required Revenue Accounting Items (RAIs) for order items, fulfillments, and invoices to the
adapter reuse layer (ARL) of RA.
SAP Billing and Revenue Innovation Management, Convergent Charging, is not linked
directly to the RAR application.
You can integrate the Offer-to-Cash end-to-end process with SAP Revenue Accounting and
Reporting.
SAP Revenue Accounting provides functions to support you with adhering to revenue
recognition regulations, especially the regulations effective in countries subject to both US
GAAP and IFRS.
SAP Revenue Accounting and Reporting automates the revenue recognition and accounting
process and simplifies the tasks of revenue accountants in following the accounting
guidelines. These tasks are described in the following steps:
Identify the revenue contract (combine contracts)
Identify the performance obligations in the contract
Lesson: Explaining the Integration with SAP Billing and Revenue Innovation Management

Determine the transaction price
Allocate the transaction price to the performance obligations of the contract
Recognize the revenue as the performance obligations are satisfied
To enable the integration, you must activate the business function FICA_EHP7_RA in the ERP
system and the business function CRM_PROVORDERINT_3_9 in the CRM system.
Within the Offer-to-Cash end-to-end process, all data required by SAP Revenue Accounting
and Reporting is communicated by the SAP ERP system.
To integrate the Offer-to-Cash end-to-end process with SAP Revenue Accounting and
Reporting, SAP provides the sender component CA (SAP O2C) with SAP Revenue Accounting
and Reporting.
Figure 59: Decoupled Operational Sales/Billing and Revenue Accounting
While SAP Sales and Distribution (SD) was integrated with SAP Revenue Accounting and
Reporting 1.0, the BRIM end-to-end solution including CRM Sales and Order Management has
been integrated out-of-the box since SAP Revenue Accounting 1.1.

Figure 60: SAP Billing and Revenue Innovation Management – RA Integration Architecture
The SAP Billing and Revenue Innovation Management integration into the generic SAP
Revenue Accounting and Reporting solution utilizes the 'full deployment ' scenario,
considering the provider contract as the core object for identifying the contract with a
customer.
From the SAP Billing and Revenue Innovation Management invoicing module, the revenue
accounting relevant information is sent to the revenue accounting engine in the appropriate
format for order items, fulfillment items for usage based revenue recognition, and for invoice
items.
In the SAP Revenue Accounting and Reporting process flow, operational information is
transformed into revenue contracts and performance obligations, the performance
obligations are allocated taking into account standalone selling prices. Resulting revenues for
fulfilled performance obligations are recognized and posted into the general ledger.
SAP Revenue Accounting and Reporting receives the operative data (order items, invoice
items, and fulfillment items) from the ERP system and stores the data in the form of Revenue
Accounting Items. The technical properties of the Revenue Accounting Items are determined
by Revenue Accounting Item classes.You define these technical properties in the
Customizing for Revenue Accounting under Inbound Processing Revenue Accounting Items .
To transfer Revenue Accounting Items from the ERP system to the revenue accounting
system, the Revenue Accounting Item classes CA01 (for order items), CA02 (for fulfillment
items), and CA03 (for invoice items) must be available in the revenue accounting system.
SAP defines the technical names of these classes. Using these technical names during
revenue item class generation, the system automatically applies the settings required for
each class.

Figure 61: Product Versions
The SAP Billing and Revenue Innovation Management integration into SAP Revenue
Accounting and Reporting is available as of ERP 6.0 Enhancement Pack 7 Support Package 9
and CRM 7.0 Enhancement Pack 3 Support Package 9 (also with ERP 6.0 Enhancement Pack
8 and CRM 7.0 Enhancement Pack 4) with SAP Revenue Accounting and Reporting 1.1.
To establish communication between your ERP system and the SAP Revenue Accounting and
Reporting:
In the ERP system, activate the integration in Customizing for Contract Accounts Receivable
and Payable under Integration Revenue Accounting. In the same Customizing activity, enter
the RFC destination for the revenue accounting system.
In the revenue accounting system, define the logical systems and assign these to the sender
component CA (SAP O2C) (see Customizing for Revenue Accounting under Inbound
Processing Revenue Accounting Item Management).

Figure 62: Provider Order in CRM
A provider contract comprises of all legally binding agreements regarding the provision and
billing of services that are entered into by a customer and a company for a specified period of
time.
If you have made the appropriate system settings, the master data of provider contracts is
automatically replicated from the CRM system to the ERP and SAP CC system.
Figure 63: Provider Contract in ERP
The figure, Provider Contract in ERP, shows the provider contract in ERP. It includes the
preliminary contract term and additional revenue relevant data. Products can be split into
usage service types.

Figure 64: Sales Order in SD
The figure, Sales Order in SD, shows the SD sales order with reference to a provider order. It
is marked as relevant for revenue accounting.
Figure 65: RAIs from SAP Convergent Invoicing
The RAIs from SAP convergent invoicing contain the following different service types:
Recurring charge with price and SSP from provider contract
Usage based services from provider contract
One off charge from BIT

Figure 66: Order Item Revenue Accounting Items (RAIs) in ERP (RA)
You can combine RAIs from SD and SAP Convergent Invoicing using the reference ID as in
this example. In the condition item view, you can see the prices and SSP from the sender
system.
Figure 67: Revenue Contract
If the RAIs are processed successfully, a corresponding revenue accounting contract is
created.
Consumption-Based Revenue

Figure 68: Consumption Based Fulfillments
While recurring charges have time-based fulfillment and hardware can have event-based
fulfillment type with event type “Goods issue”, consumption-based revenue recognition takes
place by evaluating the billable items of a specific period.
Figure 69: Fulfillment Revenue Accounting Items (RAIs) in ERP (RA)
Consumed quantities are transferred as fulfillment items to revenue accounting.
Figure 70: Revenue Contract: Updated POB by Fulfilled Quantity

Revenue Accounting system calculates the revenue to be recognized based on the
fulfillments.
Figure 71: Invoice in Convergent Invoicing
Also the Invoices for Convergent Invoicing and SD are sent to revenue accounting using
Revenue Accounting Item class CA03 and SD03.
Figure 72: Revenue Contract: Updated POB by Invoiced Amount
The invoice amount is forwarded to the performance obligations and visible in the list view - as
shown - or in the revenue schedule or in the conditions of the performance obligations.

Figure 73: Postings First Month
Here you see the report FI document by contract for the first month.
Figure 74: G/L Document
Here you see the corresponding G/L document.

Figure 75: SAP Billing and Revenue Innovation Management: Deletion of Revenue Accounting Item Records
You can reduce RAI records by deleting data from tables that you do not archive and no
longer need for Revenue Accounting. SAP provides the new deletion object 0016' and you can
delete using Deletion Other Objects in the SAP menu of the Convergent Invoicing / Contract
Accounts Receivable and Payable component in ERP via Periodic Processing Delete Data
Other Object.
You can find the deletion objects in Customizing for Contract Accounts Receivable and
Payable (FICAIMG) under Data Deletion Enter Deletion Objects.
You can change the default residence time under Data Deletion Change Default Settings for
Deletion Objects.
LESSON SUMMARY
Management

Unit 2
Lesson 4
Understanding the Integration with External
Systems
LESSON OBJECTIVES
Revenue Accounting Connections
Figure 76: Integration with External System
The external system calls the function module of the corresponding RAI class to create
Revenue Accounting Items.
Revenue Accounting Integration Options

Figure 77: Basic Concept
You need to provide business data in structure and content logic of RAIs and need to build up
references to predecessor documents yourself (such as a fulfillment relates to an order).
This is explained in the attachment of note 2392956. The session on test data explains how to
fill the fields. For migration, you need to set the initial load indicator and the migration
package (optional).
Figure 78: Basic Concept - Attachment of Note 2392956
The figure, Basic Concept - Attachment of note 2392956, gives an overview about the
contents of note 2392956. Further information is included in session Revenue Accounting
Item creation for testing.
Further information on how to create Revenue Accounting Items are included in session
Revenue Accounting Item creation for testing.
Lesson: Understanding the Integration with External Systems

Figure 79: Portfolio Approach
For high data volume scenarios, it might be useful to create a portfolio contract that includes
several customer contracts with similar behavior. This portfolio contract is creating one
contract in revenue accounting. Fulfillments and Invoices have to be directed to this contract.
You can contact SAP Innovative Business Solutions (Custom Development) with further
questions.
LESSON SUMMARY

Unit 2
Learning Assessment
1. If an order item is relevant for revenue accounting, the SD integration component sends
revenue information from deliveries and invoices to Revenue Accounting.
Determine whether this statement is true or false.
X True
X False
2. Which of the following scenarios are supported by Revenue Accounting and Reporting?
X A Return orders
X B Exclusion of billing plan items
X C Different currencies in a contract
X D Delivery-related billing
X E Cross-company code contracts
3. The inbound processing converts foreign currency in local currency (such as USD to EUR.
X True
X False

4. Which of the following statements are true for the integration with SAP Customer
Relationship Management?
X A If you bill CRM service contracts with ERP SD, you must install the SD integration
component.
X B The SAP CRM service integration into SAP Revenue Accounting considers the
service contract as the core object for identifying the contract with a customer.
X C The CRM billing engine can send Revenue Accounting Items directly to revenue
accounting.
X D SAP CRM sales orders are replicated to SAP ERP as SD orders and integrated into
SAP Revenue Accounting in the same way as an SD order that was created in SAP
ERP.
5. Which areas of the out-of-box integration between SAP Billing and Revenue Innovation
Management and SAP Revenue Accounting are directly linked to Revenue Accounting?
X A CRM Sales and Order Management
X B Convergent Charging (CC)
X C Convergent Invoicing (CI)
X D ERP SD
6. For an integration with SAP Billing and Revenue Innovation Management, Revenue
Accounting Item classes CA01 (for order items), CA02 (for fulfillment items), and CA03
(for invoice items) must be available in the revenue accounting system.
X True
X False
7. An external system can create Revenue Accounting Items by calling a function module in
the generated RAI class.
X True
X False
Unit 2: Learning Assessment

8. An external system needs to build up references between fulfillments, invoices, and orders
in Revenue Accounting Items.
X True
X False
Unit 2: Learning Assessment

Unit 2
Learning Assessment - Answers
1. If an order item is relevant for revenue accounting, the SD integration component sends
revenue information from deliveries and invoices to Revenue Accounting.
X True
X False
You are correct. If an order item is relevant, revenue information from deliveries and
invoices is sent to Revenue Accounting.
2. Which of the following scenarios are supported by Revenue Accounting and Reporting?
X A Return orders
X B Exclusion of billing plan items
X C Different currencies in a contract
X D Delivery-related billing
X E Cross-company code contracts
You are correct. Apart from the cross-company code contracts all other features are
available.
3. The inbound processing converts foreign currency in local currency (such as USD to EUR.
X True
X False
You are correct. The inbound processing converts foreign currency in local currency.

4. Which of the following statements are true for the integration with SAP Customer
Relationship Management?
X A If you bill CRM service contracts with ERP SD, you must install the SD integration
component.
X B The SAP CRM service integration into SAP Revenue Accounting considers the
service contract as the core object for identifying the contract with a customer.
X C The CRM billing engine can send Revenue Accounting Items directly to revenue
accounting.
X D SAP CRM sales orders are replicated to SAP ERP as SD orders and integrated into
SAP Revenue Accounting in the same way as an SD order that was created in SAP
ERP.
You are correct. All of the statements about the integration with SAP Customer
Relationship Management are true.
5. Which areas of the out-of-box integration between SAP Billing and Revenue Innovation
Management and SAP Revenue Accounting are directly linked to Revenue Accounting?
X A CRM Sales and Order Management
X B Convergent Charging (CC)
X C Convergent Invoicing (CI)
X D ERP SD
You are correct. Convergent Invoicing is directly linked to Revenue Accounting.
6. For an integration with SAP Billing and Revenue Innovation Management, Revenue
Accounting Item classes CA01 (for order items), CA02 (for fulfillment items), and CA03
(for invoice items) must be available in the revenue accounting system.
X True
X False
Unit 2: Learning Assessment - Answers

7. An external system can create Revenue Accounting Items by calling a function module in
the generated RAI class.
X True
X False
8. An external system needs to build up references between fulfillments, invoices, and orders
in Revenue Accounting Items.
X True
X False
Unit 2: Learning Assessment - Answers

UNIT 3 Inbound Processing
Lesson 1
Configuring Import Structures 75
Lesson 2
Working with the Revenue Accounting Item Monitor 95
Lesson 3
Transferring and Processing Revenue Accounting Items 103
Lesson 4
Explaining Return Orders 117
Lesson 5
Creating Revenue Accounting Items for Testing 122
Lesson 6
Transforming Data with BRFplus 141
UNIT OBJECTIVES
Understand the basic concepts and parameters that define and control inbound
processing
Know the field structures provided in standard and how to enhance them with individual
source information
Specify the technical properties that suit your needs for SAP Revenue Accounting and
Reporting items
Generate the interfaces for the transfer and storage of SAP Revenue Accounting and
Reporting items
List the BAdIs available during inbound processing for SAP Revenue Accounting and
Reporting

Understand how to prevent the deletion of data after the import method for generation of
RAI classes
Navigate in the Revenue Accounting Item (RAI) monitor
Outline the most important fields in Revenue Accounting Items
Understand manually executed activities
Outline the benefits of the personalization features in the Display of Revenue Accounting
Items transaction
Understand Revenue Accounting Item statuses and data management
Transfer Revenue Accounting Items (RAIs)
Process Revenue Accounting Items (RAIs)
Understand when it makes sense to exempt or restore Revenue Accounting Items
Know how to exempt or restore Revenue Accounting Items
Perform the deletion of exempted Revenue Accounting Items
Use further selections in the Transfer Revenue Accounting Items and Process Revenue
Accounting Items transactions
List the attributes that link a Revenue Accounting Item to a predecessor item
Explain how RAIs that refer to a predecessor document are handled in the Adapter Reuse
Layer during RAI processing
Explain return orders after a prospective contract change
Understand the benefit of using a test program when creating Revenue Accounting Items
Upload sample data and use the test program
Understand the BRFplus user interface
Provide an overview of the Business Rules Framework (BRFplus)
Understand the sequence and features of BRFplus functions called by Revenue
Accounting.
Unit 3: Inbound Processing

Unit 3
Lesson 1
Configuring Import Structures
LESSON OBJECTIVES
Understand the basic concepts and parameters that define and control inbound
processing
Know the field structures provided in standard and how to enhance them with individual
source information
Specify the technical properties that suit your needs for SAP Revenue Accounting and
Reporting items
Generate the interfaces for the transfer and storage of SAP Revenue Accounting and
Reporting items
List the BAdIs available during inbound processing for SAP Revenue Accounting and
Reporting
Understand how to prevent the deletion of data after the import method for generation of
RAI classes
Inbound Processing
Figure 80: Inbound Processing

In operational applications, an integration component (IC) creates Revenue Accounting Items
(RAI) and sends them to the revenue accounting application.
An RAI contains all data from operational items and events that are relevant for revenue
accounting. The structure of RAIs can be configured in SAP Revenue Accounting and
Reporting separately for different operational applications.
The Adapter Reuse Layer (ARL) receives RAIs and transforms them into revenue accounting
contracts and performance obligations.
Definition - Revenue Accounting Item (RAI)
Revenue recognition-relevant transactions result in the creation of RAIs
RAIs contain source information about these transactions that result in the creation of
revenue accounting contracts, performance obligations, and order fulfillment in SAP
Revenue Accounting and Reporting
The class for RAIs determines the technical properties of RAIs
The following statuses are possible for a RAI:
- Raw
- Processable
- Processed
Each RAI consists of 1 main item and 0..n conditions. Main items contain the basic data of a
RAI. Conditions are linked to one main item and cannot be processed without an existing main
item. Conditions contain the amounts as well as the accounts per condition type.
Definition - Revenue Accounting Item Class
The RAI class determines and controls the following technical attributes of RAIs:
1. Database tables, in which the system saves the RAIs, depending on their status and on the
record type they belong to
2. Function modules that receive the RAIs
3. Function modules that save the RAIs in the appropriate database tables
4. Specific fields of RAIs that you have added, either by your selection of interface
components or using customer fields

Figure 81: Definition - Revenue Accounting Item Class Types
Each RAI class has a certain type. The following RAI class types are provided by the system:
Order item (01): Classes of this type store order items/contract items. Order Revenue
Accounting Items contain the header data of the order as well as the item data.
Additionally, order item RAIs contain conditions.
Fulfillment Item (02): Revenue Accounting Item classes of this type store fulfillment items
(example: goods issue).
Invoice item (03): Classes of this type store invoice items/billing document items (credit
memo, debit memo and billing document share the same attributes). Invoice Revenue
Accounting Items contain the header data of the invoice as well as the item data.
Additionally, invoice item RAIs contain conditions.
Inbound Processing Field Structure
Figure 82: RAI Interface Components
Lesson: Configuring Import Structures

The Adapter Reuse Layer (ARL) provides standard interface components for the import of the
contract information from SAP components.
Interface components contain the structure of all fields that are either mandatory for later
processing or optional for additional data checks and enrichment. Please note that the
specific fields and their meaning is explained in later units.
RAI classes can be created by selecting the appropriate interface components, and they can
be enhanced by customer-specific fields.
The interface components used for the configuration of RAI classes are displayed and
maintained in the IMG under path Financial Accounting Revenue Accounting Inbound
Processing Revenue Accounting Items Define Interface Components .
Figure 83: RAI Interface Components - Field Overview Basic Fields for Conditions
The Basic Fields Conditions (BASIC_CO) interface component includes the basic fields for RAI
conditions. It contains the most important selection data and management data of the RAI
and of the Condition record type.
This interface component is a basic component that is always active in classes using the
Condition record type.
The interface components for the Condition record type are activated automatically for RAI
classes of Order Item and Invoice Item class types. It may also be added manually to RAI
classes of the Fulfillment Item class type.

Figure 84: RAI Interface Components - Field Overview Basic Fields for Main Items
The Basic Fields for Main Items (BASIC_MI) interface component forms the basis for RAIs. It
contains the most important selection data and management data of the RAI.
This interface component is a basic component that is always active in each RAI class. It is
relevant for the Main Items record type.
Dependencies
If this interface component is active, in the Customizing activity Maintain Revenue Accounting
Item Class, you can select and add customer fields for main items. For more information, see
the documentation about the relevant Customizing.
Figure 85: RAI Interface Components - Field Overview Basic Fields for Order Items (Main Items)
The Basic Fields for Order Items (Main Items) (BASIC_MI01) interface component forms the
basis for Revenue Accounting Items resulting from order items. It contains the most
important selection data and management data of the Revenue Accounting Item of the
revenue accounting Order Item class type.
Lesson: Configuring Import Structures

S4F55_EN_Col12 SAP Revenue Accounting and.pdf

S4F55_EN_Col12 SAP Revenue Accounting and.pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to S4F55_EN_Col12 SAP Revenue Accounting and.pdf

Similar to S4F55_EN_Col12 SAP Revenue Accounting and.pdf (20)

Recently uploaded

Recently uploaded (9)

S4F55_EN_Col12 SAP Revenue Accounting and.pdf