RAR Overview

General overview session

October 30, 2017
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
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
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

 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
IFRS15 – Mandatory 5-Step Model for Revenue Recognition
Affecting All Revenue Contracts (IFRS 15, FAS 2014-09, ASC
606)
• Final standard published May 2014
Identify the contract with the customer
• Effective date latest 2018* (early adoption
possible for IFRS preparers)
1
Identify the separate performance
obligations in the contract
• New single principled 5-step model (SSP)
for recognizing revenue
2
• Disclosure changes include both
quantitative and qualitative
information about the amount,
3 Allocate the transaction price

timing, and uncertainty of revenue

from contracts with customers and
Manage fulfillment of performance
the significant judgments used. 4 obligations

• All companies (public and private) will be

required to prepare their revenue
contracts now to comply with this new
5 Make revenue postings
regulation by 2018/19*
 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.

Operational contract 1 Revenue Accounting

Item 1 contract
Item 2 POB 1
POB 2
Operational contract 2 POB 3
Item 1 POB 4
Item 2
 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)

Operational Revenue Accounting

Sales contract contract
1. Security appl (SW) 1 Compound Leading POB
2. Support
3. Support
2 Material Right
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.
Functionality Corresponding to 5-Step Model
4: Manage fulfillment of POBs

Manual POC’s

Here’s all the Transaction layer

Invoice activity as it’s funneled into
SAP Revenue Accounting

Delivery

 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
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)
Current OLD RevRec in Sales & Distribution
NEW: RAR decoupled SD from Revenue Accounting
Overall flow chart – from SD to Financial
Posting
 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)
 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
From SD document to RAI - example
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
From RAI to RA contract: Flow
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
From RAI to RA contract: Processed RAI - 2
RA contract: Contract Search
RA contract: POB structure - Hierarchical
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”
RA contract: Price Allocation
From RA contract to FI-GL posting - Flow
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)
 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:
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
FI-GL posting: FI documents by contract -
example
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
Q&A