The document outlines the features and functionalities of a new revenue accounting module (RAR) by SAP, designed to comply with the IFRS 15 five-step model for revenue recognition. It highlights the complexities in revenue recognition, providing a structured approach for handling contracts, performance obligations, transaction pricing, and fulfillment management. The module aims to streamline revenue accounting processes and improve compliance for both B2B and B2C sales arrangements, addressing gaps in previous SAP offerings.

1. RAR Overview
General overview session
October 30, 2017

2. Agenda
 RAR Overview – Why and Basic Structure
 IFRS15 – Mandatory 5-Step Model for RevRec
 Functionality of 5-Step Model
 Current: OLD RevRec in Sales & Distribution
 New: RAR decoupled SD from Revenue
Accounting
 Flow and Processing in RAR
 From SD to RAI
 From RAI to RA contract
 From RA contract to FI-GL posting

3. Increasing Revenue Recognition complexities
result in reporting issues
In the past years, complexity for sellers has increased significantly:
Of products
 complex integration of hardware, software, maintenance, support, training, services
Of both B2B as well as B2C sales arrangements
 Negotiation-driven discounts, customer relationship / contract building across time, etc
Of increasingly global sales interactions
Of accounting reporting requirements
 Reporting under multiple GAAPs
 Segmental other details
 Higher personal C-level accountability for reporting content and impact
However, even companies in the same industry, reporting under the same
standards, were often left to interpret the business situations by themselves
and find their own reporting solution to it
That lead to reporting inconsistencies and incomparability, eventually forcing
financial reporting authorities – IASB, FASB - to step in

4. Why a New Revenue Recognition module by
SAP?
As standard, SAP offered only the SD-based revenue recognition transactions
VF44 and VF45.
This functionality only allows revenue recognition only
Over time
For specific (isolated) SD orders / line items
Therefore, SAP realized there was a significant gap in their application:
Multiple Element Arrangements (see below) not covered
No Parallel Accounting (individual order-based – one value to FI/CO)
Cost Recognition missing
Required Disclosures as per guidelines incompletely covered
No integration with other SAP or third party applications
…leading it develop the new RAR (FI-RA, FARR) module

5. Basic aspects of the New SAP RAR
module
To understand the New RAR module, the two fundamental aspects determining
the structure of the New SAP RAR module are:
The module strictly follows the 5-step-model required in the new
IFRS/GAAP guidelines
This may not be directly apparent, as multiple steps are performed “in one
go” behind the scenes based on rules settings
This is the case even when using the module to calculate and post values as
per approaches used prior to IFRS15
The module is structured as a separate, independent component -
outside of the SD (operational) module
This means that any customizations and changes for RevRec purposes in SD
can be removed
This means that the module will always start off with an offset of the
“gross” = unrecognized revenue numbers as per SD billing and posting to FI

6. IFRS15 – Mandatory 5-Step Model for Revenue Recognition
Affecting All Revenue Contracts (IFRS 15, FAS 2014-09, ASC
606)
1
2
3
4
5
Identify the contract with the customer
Identify the separate performance
obligations in the contract
Allocate the transaction price
Manage fulfillment of performance
obligations
Make revenue postings
• Final standard published May 2014
• Effective date latest 2018* (early adoption
possible for IFRS preparers)
• New single principled 5-step model (SSP)
for recognizing revenue
• Disclosure changes include both
quantitative and qualitative
information about the amount,
timing, and uncertainty of revenue
from contracts with customers and
the significant judgments used.
• All companies (public and private) will be
required to prepare their revenue
contracts now to comply with this new
regulation by 2018/19*

7. Functionality Corresponding to 5-Step Model
1: Identify the Contract with a customer
 An economic agreement or “deal with the customer is represented as a single Revenue
Accounting , RA contract
 Revenue Accounting contract can correspond to one or multiple operational documents from
back-end operational systems (at McAfee: SD)
 RA Contract is the container for Performance Obligations, POBs.
POB 1
POB 2
POB 3
Operational contract 1
Item 1
Item 2
POB 4
Operational contract 2
Item 1
Item 2
Revenue Accounting
contract

8. Functionality Corresponding to 5-Step Model
2: Identify the separate performance obligations, POBs, in the
contract
 Performance Obligation is the level where the Standalone Selling Price (SSP) is defined, where
the revenue is allocated, and the fulfillment (% of completion) determined
 Usually, a POB corresponds to an item of an operational contract, but it can also be a
combination of several items, e.g., from a sales BoM (bill of material; or an implicit obligation,
e.g., customer’s right for software upgrade)
 At McAfee, often, multiple (“non-distinct”) contract items are merged into a compound POB
 McAfee also separates out revenue into a new POB (material rights)
Revenue Accounting
contract
1 Compound
Operational
contract
1. Security appl (SW)
2. Support
3. Support
2 Material Right
Leading POB
Sales

9. Functionality Corresponding to 5-Step Model
3: Allocate Transaction Price
 Determine the total price by aggregating the pricing conditions
passed from SD, and then allocate the total price among the
performance obligations
 Some amounts per condition types are not added to the
transaction price and not allocated
- Non-pricing condition types, such as costing condition types
- Statistical condition types
 Allocation effect indicates how much the allocated prices differ
from their original prices.
.

10. Functionality Corresponding to 5-Step Model
4: Manage fulfillment of POBs
 Recognize revenue for performance obligations as they are fulfilled.
 Revenue Accounting manages the fulfillment statuses of performance
obligations on its own. When a performance obligation qualifies as fulfilled, it
is tracked as fulfilled in Revenue Accounting.
 Revenue Accounting supports various calculations of performance obligation
fulfillment.
On the occurrence of a certain event
Over a period of time
Over a period of time that starts with an event
Manually managed
Here’s all the Transaction layer
activity as it’s funneled into
SAP Revenue Accounting
Invoice
Delivery
Manual POC’s

11. Functionality Corresponding to 5-Step Model
5: Make revenue postings
 Make periodic or on demand postings to the general ledger to reflect revenue-related
transactions.
 The general task of revenue posting is divided into three steps.
1. Calculate Time Based Revenue (posting / current period revenue)
2. Calculate Contract Liabilities and Assets (posting period balance sheet positions)
3. Execute Revenue Posting Run (process data to create FI-GL documents)

12. Current OLD RevRec in Sales & Distribution

13. NEW: RAR decoupled SD from Revenue Accounting

14. Overall flow chart – from SD to Financial
Posting

15. From SD document to RAI - overview
 Information from SD or other operational systems is brought into RAR in packets of
information called “Revenue Accounting Items” (RAI)
 There are mainly three types of RAIs:
 SDOI (SD01) = Order items (RA contract creation and changes)
 SDFI (SD02) = Fulfillment items (if an event triggers revenue recognition)
 SDII (SD03) = Billing items (impact on balance sheet positions, and if recognition event = invoice)

16. From SD document to RAI - config
 SD documents are brought into RAR only when they are made relevant in config
 This is by Sales Org, Sales Document Type, and Item Category

17. From SD document to RAI - example

18. From SD document to RAI – RAI monitor
 The RAI monitor is the central transaction to process RAI items into RA contracts
 FARR_RAI_MON transaction is used for this process.
 If there is an issue with the RAIs, this issue will go into the contract; the RAI monitor is
therefore one step to check if the issue is in the underlying data, or subsequent processing

19. From RAI to RA contract: Flow

20. From RAI to RA contract: Processed RAI - 1
 Similar to other documents in SAP, RAI items have a header section (“main item”, and
detail lines (“condition items”)
 The fields and content of these depend on the type of RAI

21. From RAI to RA contract: Processed RAI - 2

22. RA contract: Contract Search

23. RA contract: POB structure - Hierarchical

24. RA contract: Revenue Schedule
 The Revenue Schedule shows the projected revenue, data, and status
 per POB
 per period
 for the entire contract term
 Generally, if the revenue schedule is “off”, postings will also be “off”

25. RA contract: Price Allocation

26. From RA contract to FI-GL posting - Flow

27. From RA contract to FI-GL posting:
Overview
 The posting process consists mainly of three steps, which have to be run in sequence:
 “Transfer Revenue” = Period Revenue (staging),
 “Calculate Contract Liabilities and Assets” = Balance Sheet Positions (staging),
 “Revenue Posting Run” = Posting to GL (simulated or update mode)
 These steps have to be executed in this sequence
 An error in a preceding step has to be fixed before the subsequent step can be successful
 These steps are usually executed automated
 There are additional transactions and options (reversal, shift revenue, etc)

28. From RA contract to FI-GL posting: Posting
jobs monitor
 The posting process jobs monitor is the central transaction to analyze each of the steps
 If successful, it also has a direct link to the FI-GL document posted in the run:

29. From RA contract to FI-GL posting: Reporting
 SAP offers a number of standard reports to analyze postings
 Single most reconciliation between RA contract and FI-GL document
is “FI documents by contract” report
 McAfee is also using BW extensively

30. FI-GL posting: FI documents by contract -
example

31. Useful transactions
• NWBC transaction will be used for net viewer launcher.
o Revenue Accountant:-
 Contract management will be used for Contract search, manual
fulfillment , POB cancellation.
 Revenue Posting run – it will be used for Transfer revenue, calculate
assets and liabilities and Revenue posting.
 Reporting- All out of the Box RAR reports can be utilized here e.g. FI
documents by contract, posted amount by contract, revenue by
customer.
o Revenue account admin will be used for RAR configuration , decision table and
account determination.
• BRF+ will be used for framework rules

32. Q&A