1

2
3
4
5
Example of Multiple Elements Arrangement with allocation of transaction price:

A Telco company sells a mobile phone for 1,- CU, if the customer enters at the
same time into a service contract for 24 months with a monthly charge of 19,95
CU.
The mobile phone would be sold alone for 180,- CU.
Customers can enter a similar service contract without buying a phone with a
monthly charge of 15,- CU (i.e. total charge 15,- * 24 = 360,- CU).

The total transaction price of 1,- + 24 * 19,95 CU = 480,- CU has to be

allocated to the mobile phone and to the service proportionately to their
respective stand-alone selling price.

Allocated price of mobile phone = stand-alone selling price of mobile phone /

(sum of all stand-alone selling prices) * complete transaction price =
= 180,- / 538,- * 480,- = 160,-
Allocated price of service = 360,- / 538,- * 480,- = 320,-

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.

6
7
This has been a long process, the governing body has taken into account
comments from many different sources filers, preparers analysts.
Important point is that this standard will replace the all the industry specific
standards in US GAAP ie SOP 97-2, EITF 0801. This standard will be relevant
for all contracts.
Industries probably most effected will be technology, high tech software, also
the telcos.

Final standard: IFRS 15 – published on May, 28th. 2014

8
Step 1 – Revenue Accounting 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.

Step 2 - The Performance Obligation (POB) is the level, where the Stand-alone Selling
Price (SSP) is defined, where the price is allocated and the fulfillment (PoC)
determined.
Usually it 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.

Step 3 – The transaction price is determined from pricing conditions of the operational
items. It cannot be maintained within Revenue Accounting.

Step 4 - The transaction price is allocated to the distinct POBs of a contract on a

relative stand-alone selling price basis.

Step 5 – Revenue is recognized at satisfaction of a POB.

Satisfaction can be a defined fulfillment event (e.g. goods issue) or over time.
Over time fulfillment can be calculated time-based or based on PoC (Percentage of
Completion).

9
10
SD Revenue Recognition allows:
 For Sales from stock:
Recognize revenue based on defined events
 For service contracts:
Recognize revenue spread straight line over duration of billing plan

Results analysis allows recognition of revenue based on a percentage of

completion that can be calculated with different methods (e.g. based on actual
costs and total planned revenue / planned cost.

11
SD offers an integrated Revenue Recognition based on SD documents.

With SD Revenue Recognition, Invoices are not posted to revenue but to

Deferred Revenue or Unbilled Receivables (depending on previous balance of
Recognized Revenue and Invoiced amounts).
Defined fulfillment events (goods issue, proof of delivery) 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
billing plan.

Recognized Revenue is also passed to CO-PA (Profitability Analysis).

12
13
14
15
Operational contracts can be combined:
 By rules in a custom specific Badi implementation
 Manually within Revenue Accounting

It is also possible to split items of an operational contract to different RA

contracts.

16
If a customer can benefit from the separate lower level items of a sales BoM on
their own, then every item corresponds to a separate “distinct” POB.
If a customer can not benefit from the separate lower level items of a sales
BoM on their own, then the BoM as a whole corresponds to one POB.
(Indicator, whether a customer can benefit from the separate items on their
own, can be, whether they are usually 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 also
created in the RA contract. Events on the lower level items are then aggregated
on the higher level “compound” POB.

Revenue Accounting can create separate “linked” POBs for implicit obligations
that are not included as explicit item in the operational contract. These POBs
always have to be linked to a “leading” POB that corresponds to some
operational item.
Examples: rights for software upgrades or maintenance without explicit charge.

17
From SD orders, all pricing conditions are transferred to Revenue Accounting
and summed up to the transaction price.
The transaction price can only be maintained via conditions in the operational
contract (or invoice).
After complete delivery and final invoice, the transaction price must be equal to
the total invoiced amount in the operational application.

(In future release it may be possible to maintain estimates for variable

consideration within Revenue Accounting. But in the end these estimates have
to be replaced by actually invoiced amounts.)

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
Revenue Accounting.

18
A POB can have fulfillment-type event-based or time-based.
For event-based, possible event-types are:
 Goods issue
 Invoice
 Manual fulfillment (manual input of PoC)
In future further types of event shall be supported, e.g. proof of delivery.

For time-based fulfillment, start date and duration or end date cna be
transferred from the operational item or maintained manually in Reveneu
Accounting.

19
20
 Revenue Accounting is decoupled from operational sales applications.
 It is an Add-on to ERP Financials
 Data from different operational applications can be transferred into Revenue
Accounting.
 BRFplus is a flexible rules framework that is used to define rules for the
transformation of operational items into contracts and performance obligations.
 In the end, Revenue Accounting creates postings to FI-GL and CO-PA

21
In operational applications, an Integration Component (IC) creates Revenue
Accounting Items (RAI) and sends them to Revenue Accounting.
A Revenue Accounting Item contains all data from operational items and events
that are relevant for revenue accounting.
The structure of Revenue Accounting Items can be configured in Revenue
Accounting separately for different operational applications.

The Adapter Re-use Layer (ARL) of Revenue Accounting receives RAIs and
transforms them into RA contracts and Performance Obligations.
Rules for transformation can be defined in Business Rules Framework plus
(BRFplus).

Components of the Revenue Accounting Engine:

 Contract Management calculates price allocation
 Processes Management offers manual processing
 Invoice Management calculates effects from invoices
 Fulfillment Management determines recognized revenue from fulfillment events
 Postings Management creates postings of recognized revenue and invoice corrects
 The Accrual Run creates postings in FI-GL and CO-PA
 Data Provisioning extracts data into BI

22
A RAI is a subset of an item in an operational system.
It must contain all the data which is relevant for revenue accounting.

Each sender component defines this subset on its own (configuration of a RAI-class).
The subset (RAI) can be configured in a framework (copy from BIT-management).
Based on this subset definition the framework allows the generation of a persistence
for the RAIs as well as an RFC-enabled function module for RAI-creation (+ access
methods, structures, indexes, …).

Currently we allow the configuration and processing of order items, invoice items and
fulfillment items.

Processing of the RAIs is agnostic of the sender components.

(All further parts are not specific per operational system.)
In RAI-transfer and RAI-processing RAIs from all sender components are tranferred /
processed at once.

In RAI-processing, several BRF+ rules (examples: creation of additional POBs, SSP

determination) are executed. A 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.

23
Customers can configure rules for the different steps of transformation from
Revenue Accounting Items -> RA contract 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 in order to determine:

 Which operational items shall be managed as distinct performance obligation
 Specific attributes of a POB (can also be defaulted from a POB type)
 Creation of linked POBs for implicit obligations
 The Stand-alone Selling Price can be maintained in BRF+ or they can be uploaded
into BRF+. (They 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.

24
Adapter Re-use Layer passes RA contracts with performance obligations,
invoice event data and fulfillment event data of the Revenue Accounting
Engine.

Components and functionality of Revenue Accounting engine:

 User Interface based on Web Dynpro ABPA with Floor Plan Manager and Personal
Object Work List for error and review work list.
 Invoice and fulfillment management calculates data for posting
 Accrual run creates aggregated actual postings to FI General Ledger and to CO-PA
 Reconciliation explains aggregation of posting data per POB into postings
 Data provisioning offers data sources for legal reporting and analytics

25
26
27