Reading Sample Sappress 1436 SAP Revenue Accounting and Reporting and IFRS 15 PDF

First-hand knowledge.
Reading Sample
The IFRS 15 standard is herethat means its time for your compa-
ny to become compliant! SAP Revenue Accounting and Reporting
and IFRS 15 contains the foundations of the IFRS 15 standards, the
usage and migration process of SAP RAR, and business cases from
telecom and high-tech industries. In this sample, explore the foun-
dations of IFRS, the impact of the new standards (IFRS 15), and
SAPs answer: SAP RAR.
Introduction to IFRS 15 and SAP

Revenue Accounting and Reporting
Contents
Index
The Authors
Dayakar Domala, Koti Tummuru

SAP Revenue Accounting and Reporting and
IFRS 15
376 Pages, 2017, $99.95
ISBN 978-1-4932-1436-5
www.sap-press.com/4206
This chapter introduces the IFRS 15 standard: its requirements, its scope,
Chapter 1
and the software and hardware requirements needed to address it. We

will then dive into SAP Revenue Accounting and Reporting and its
response to this standard.
1 Introduction to IFRS 15 and SAP Revenue

Accounting and Reporting
Revenue is one of the most important key performance indicators (KPIs) used by
investors when assessing a companys performance and prospects. Revenue recogni-
tion represents one of the highest risks on financial statements, and it is one of the
leading causes of restatements. Every publicly traded company has to follow the
guidelines set by the Securities and Exchange Commission (SEC) to communicate
their financials effectively to investors. Based on the operations in different coun-
tries, businesses sometimes need to comply with more than one set of standards.
Most of the companies located in North America or Europe comply with gener-
ally accepted accounting principles (GAAP) and International Financial Reporting
Standards (IFRS). Recently, the standards-setters developed new revenue-related
standards (IFRS 15 and Accounting Standards Codification [ASC] 606), which
ensure clarity and transparency in reporting revenue. These new guidelines
require a substantial change in the way currently revenue is being reported com-
pared to the new revenue recognition standards.
The main objective of the new standards (IFRS 15 and ASC 606) is to provide a
single, comprehensive revenue recognition model for all customer contracts,
improving comparability within and across industries and across capital markets.
Initially, when the standards were released on May 28, 2014, all companies were
expected to comply by 2017. However, based on the complexities involved and
the feedback from major industries around the implementation of the new stan-
dards, the International Accounting Standards Board (IASB) and Financial
Accounting Standards Board (FASB) deferred the effective date to 2018.
15
1 Introduction to IFRS 15 and SAP Revenue Accounting and Reporting Global Accounting Standards 1.1
With the effective date of these new standards approaching, its important to nature. The United States controls fifteen trillion dollars in foreign assets, and
understand what challenges your company will face and how SAP Revenue companies are expected to supply the market with high-quality financial informa-
Accounting and Reporting (RAR) can help. In this chapter, we will begin by intro- tionespecially in the global economy, which is dynamic and often unpredict-
ducing the concept of the new revenue accounting standards and a brief history able. Overall, US-GAAP is more rule-based in nature, whereas IFRS is more
of how these new standards have evolved (Section 1.1). We will also touch on the principle-based. Currently, there are many key differences in the way revenue is
associated business challenges and the impact of the new standards on customers recognized by businesses using one or the other sets of accounting standards.
(Section 1.2). We will also discuss the design of the standards for addressing these
In order to address these major concerns, the FASB began working on these
new standards and how SAP is addressing these requirements. This chapter will
issues in 2002. In 2008, the IASB joined the FASB, collaborating to issue a new
outline how SAP RAR handles the IFRS 15 requirements, including a look at its
standard on May 28, 2014. These new standards will harmonize and standardize
architecture and integration with other applications (Section 1.3).
the revenue recognition process reported in the financial statements for both US-
GAAP and IFRS preparers.
1.1 Global Accounting Standards This new revenue recognition standard will add additional disclosures about rev-
enue (making it more transparent), provide additional guidance for services and
The new IFRS 15 guidelines embody a major shift in how revenue will be recog- contract modifications (which are not very clear in the current regulations), and
nized in many companies. Therefore, businesses need to perform a thorough provide detailed guidance for multiple-element arrangements. In the US, the new
analyses of existing business models, company accounting practices, and policies. revenue recognition standards will replace more than two hundred specialized,
industry-specific revenue recognition requirements. The US-GAAP and IFRS 15
In this section, we will discover what led to the need for new accounting and
will greatly expand the revenue recognition process in IFRS.
reporting standards and specific business challenges that come with these new
guidelines. Based on the initial observation, these new standards will have a high impact on
the telecommunications, high-tech (software), professional services, automotive,
and real estate industries. Now, well look at the business challenges these indus-
1.1.1 New Accounting Guidelines
tries and other companies will face.
Accounting has a long history; the first formal accounting goes back to the fif-
teenth century, beginning with double-entry bookkeeping (debits on left and
credits on right). In the 1920s, General Motors introduced the first KPI-based 1.1.2 Business Challenges
accounting, such as the return on investment and the return on equity. In 1934, Lets explore some of the business challenges that may arise when implementing
the SEC was formed to formalize accounting standards. After four decades of the new IFRS 15 guidelines:
effort, in 1973, the FASB formulated standards that govern the preparation of
The implications of new guidelines are far broader than simply changing
financial statements, as mandated by the SEC for all US capital markets. The IASB
accounting and reporting methods, although that change itself is highly com-
was established in 2001 and is the standard-setting body of the IFRS foundation.
plex in nature. The new guidelines affect product offerings and how products
Based on the historical evidence, weak or inconsistent accounting standards have are sold, related taxes, and commissions.
negatively impacted the US and global economies. Now more than ever, there is Businesses need to go through large change management processes, both on
a need for standardized financial reporting as companies become more global in the process side and the system side.
16 17
1 Introduction to IFRS 15 and SAP Revenue Accounting and Reporting IFRS 15 1.2
Businesses will also need to change their communication strategy with stake- Based on FASBs recent publication (see http://www.fasb.org), the objectives of
holders, including suppliers, customers, and investors. these new guidelines are as follows:
Based on your transition approach (full retrospective or modified retrospec- Establish principles to report useful information to users of financial state-
tive), companies may face challenges to generate data on both accounting stan- ments about the nature, amount, timing, and uncertainty of revenue from con-
dards. tracts with customers.
Most organizations financial systems are not adequately equipped to handle Remove inconsistencies and weaknesses in existing revenue requirements and
transition or dual reporting requirements, which requires significant manual provide a more robust framework for addressing revenue issues.
effort and time. It is important that organizations upgrade their systems in
Improve comparability of revenue recognition practices across entities, indus-
order to help automate the new revenue guidelines process.
tries, jurisdictions, and capital markets.
Its important that businesses choose the right tool to automate revenue guide-
Provide more useful information to users of financial statements through
lines and perform a detailed vendor analysis in the market before finalizing the
improved disclosure requirements.
tool selection. They should consider the new accounting requirements (use
cases, revenue scenarios), fit/gap analysis, data migration, and reporting re- Simplify the preparation of financial statements by reducing the number of
quirements. requirements to which an organization must refer.
Its important for businesses to onboard key stakeholders from day one of this Adopting these new standards can be quite challenging and complex. The regula-
transformation and transition process. tions are subject to interpretation, because the standards are principles-based and
Its also important for businesses to assess the new revenue standards and emerging. Based on the IFRS 15 guidelines, the revenue recognition process
develop an approach plan, and then convert that plan into a strategy to achieve needs to be adopted in a five-step framework.
the organizations final goals. In this next section, well discuss what the five-step framework is, the impact this
Now that weve explored the involved business challenges, let's dive deeper into new standard has on industries, how to choose which vendor tool to use in sup-
the impact of these new standards, and take a closer look at what IFRS 15 is, its port of the new revenue standard, and how SAP is addressing these new require-
framework, existing tools available to address these new standards, and how SAP ments within its own technology.
is addressing this change.
1.2.1 Five-Step Framework for Revenue Recognition
The five-step framework is the core structure of IFRS 15; it consist of the five dif-
1.2 IFRS 15 ferent steps for revenue recognition in IFRS paragraph IN-7, (a) through (e).
As previously mentioned, prior to the new standards, the revenue recognition Figure 1.1 outlines the five-step framework.
guidelines differed between US-GAAP and IFRS. Because the standards were dif-
ferent and businesses were expected to meet these standards within set guide-
Identify the Allocate the trans- Recognize revenue
lines, it became increasingly challenging to comply with both standards. There- Identify the
separate performance Determine the action price to sep- when (or as) each
contract(s) with
obligations in the transaction price arate performance performance obligation
fore, the FASB and the IASB issued their long-awaited joint standard for revenue the customer
contract(s) obligations is satisfied
recognition in May 2014 via IFRS 15.
Figure 1.1 Five-Step Framework for Revenue Recognition
18 19
In the following subsections, well look at each step in greater depth before dis- goods or services promised in the contract. In this case, the transaction price is
cussing how the steps impact current industry practices. not adjusted for credit risk, unless the contract includes a significant financing
component, and includes all amounts the seller has the right to under the present
contract, payable by any party, that is, not limited to receipts from customers.
Step 1: Identify the Contract(s) with the Customer
The consideration promised in a contract with a customer may include fixed
In Step 1, companies must identify their contract(s) with a customer. A contract is amounts, variable amounts, or both.
an agreement between two or more parties that has enforceable rights and obli-
gations. Contracts can be written, oral, or implied by an entitys customary busi- The allocable transaction price is the transaction price minus any discounts given
ness practices. Electronic assent constitutes acceptable evidence of a contract. to the customer at the time of the contract initiation.
The practices and processes used to establish contracts with customers may vary
across legal jurisdictions and across various industries and entities. They also may Step 4: Allocation of Transaction Price
vary within the entity, depending, for example, on the nature of the customer or Step 4 allocates the transaction price to the distinct POBs in a contract. An entity
the products and services. typically allocates the transaction price to each POB based on the relative stand-
alone selling prices of each distinct good or service promised in the contract.
In some cases, IFRS 15 requires an entity to combine contracts and to account for
them as one contract in any of the following situations: If a standalone selling price is not observable, an entity estimates it. Sometimes,
the transaction price includes a discount or a variable amount of consideration
The contracts are entered into at near or the same time with the same customer.
that relates entirely to a part of the contract. The requirements specify when an
The contracts are negotiated as a package with a single commercial objective. entity allocates the discount or variable consideration to one or more, but not all,
The price of one contract depends on the price or performance of another con- POBs (or distinct goods or services) in the contract.
tract.
The goods or services of a contract are single performance obligations (POBs). Step 5: Recognize Revenue When a Performance Obligation Is Satisfied
POB satisfaction can be a defined fulfillment eventfor example, typically a sales
Step 2: Identify the Separate Performance Obligations in the Contract(s) order with hardware or a handset needs to be delivered and goods issued, which
Now, the POBs in a contract must be identified. A contract includes promises to can act as a trigger for recognizing the revenue. Goods issued also act as a trigger
transfer goods or services to a customer. If those goods or services are distinct, for recognizing the costs. Similarly, professional services or network services ren-
the promises are performance obligations and are accounted for separately. dered over a period of time can be recognized as the appropriate time passes; for
instance, one month of service delivered will trigger the recognition of the related
A good or service is distinct if the customer can benefit from the good or service revenue.
on its own or together with other resources that are readily available to the cus-
tomer and if the entitys promise to transfer the good or service to the customer For over time POBs, fulfillment can be calculated on a passage of time basis or
is separately identifiable from other promises in the contract. based on percentage of completion (PoC). For example, for project-related POBs,
the PoC can act as a trigger for revenue recognition compared to events-based
(goods issued) or time-based recognition. Alternatively, customers can also use
Step 3: Determination of Transaction Price manual triggers for recognizing revenue. All these events are triggers for satisfy-
The next step is to determine the transaction price, the amount of consideration ing a POB.
that the seller expects to be entitled to in exchange for transferring the control of
20 21
With this understanding of the five-step framework, lets now look at how the the revenue is being recognized as amounts are invoiced. Because the company
new standards and these steps affect different industries. offered its handsets up front at a discounted amount, the handset revenue does
not cover the incurred costs until the end of the twenty-four-month period. With
the new revenue standards, the handset revenue is recognized immediately at the
1.2.2 Impact of the New Standards
inception of the contract based on the fair market value (i.e., the standalone sell-
Within IT, often there exists a misconception that reporting requirements are ing price [SSP], based on the new revenue standards).
simply a representation of existing data in different dimensions. However, the
new revenue recognition and reporting guidelines issued by the IASB and the Based on this information, the telecommunications company needs to take the
FASB will significantly impact the way companies operate, store, and report their following actions to adopt and transition to the new accounting standards:
financials. The new guidelines will impact not only publicly traded companies, Identify distinct vs. non-distinct POBs (see Step 2 of the Five-Step Framework
but also private and nonprofit organizations that follow the FASB and the IASB for Revenue Recognition) and set up multiple POBs.
standards. The FASB represents US-GAAP, and the IASB represents the IFRS.
Create criteria for determining the transaction price.
Although only some industries are impacted heavily by the new revenue regula- Identify effects of collectability and whether theres a right of return.
tions (automotive, financial services, high-tech, entertainment and media, engi-
Identify the standalone selling price (SSP) and the related allocation of the
neering and construction, franchises, professional services, telecommunications,
transaction price among POBs.
and real estate), almost all other industries are impacted in some manner, as they
are expected to comply with expanded disclosure requirements. The new stan- Consider the treatment of distinct/non-distinct services, such as installation
dards are codified in several hundred pages, which are typically interpreted and fees, activation fees, and so on.
implemented by businesses based on their operational footprint and guidance Identify contract costs.
from their audit firm. The new standards propose a five-step approach for new
revenue recognition processes. The effective date of these new standards is fiscal
Impact on the Automotive Industry
year 2018. The IASB allows early adoption of the program, but the FASB requires
the adoption to be in or after financial year (FY) 2018. The automotive industry is another industry that will be heavily impacted by the
new IFRS 15 standards. When a dealer sells a car to a customer, the dealer typi-
The adoption dates for these programs may appear to be far off, but complying cally includes certain mandatory services and may offer certain discounts on
with these standards may require significant changes to business processes and optional services it renders over a period of time. In this example (see Figure 1.2),
related disclosure requirements. Companies need to start initiating these projects when a dealer sells a brand-new car, the car transaction price includes free main-
proactively in order to assess the impact on their financial reporting as soon as tenance for thirty-six months (assuming its part of the initial offer) and a free
possible. bumper-to-bumper warranty up to thirty-six months or thirty-six thousand miles.
To better illustrate how these standards impact different industries, well walk Also, at the time of sale the customer is offered a special detailing service for
through some industry-specific examples in the following subsections. ninety dollars for three years, which includes six services. The SSP for detailing
may be ninety dollars per service, but new customers are offered a special dis-
count as part of the new customer loyalty program. In this example, the transac-
Impact on the Telecommunications Industry
tion price needs to be allocated among maintenance, warranty, and optional ser-
First, lets look at an example telecommunications company. In this example, the vices.
contract duration is twenty-four months, and under the current IFRS standards,
22 23
Automotive Example High-Tech Industry Example (On-premise Subscription)

SSP Allocation SSP Allocation
Car sale price $15,000.00 Auto SSP $16,500.00 87.61% Contract amount $806,405.00 Software License $850,000.00 85.00%
Maintenance: 36,000 miles/3 years $- Maintenance SSP: $504.00 2.68% Contract term: Starting 01/01/2016 36 months Maintenance SSP: $150,000.00 15.00%
Warranty: 3 years/36,000 miles $- Warranty SSP $1,350.00 7.17% Software license $645,124.00 Total SSP $1,000,000.00 100.00%
Maintenance $161,281.00
Detailingservice: 3 years $90.00 Detailing SSP $480.00 2.55%
Total recurring revenue: $15,090.00 Total SSP $18,834.00 Current GAAP:

Total recognized revenue $ 806,405.00
Current IFRS: Maintenance and upgrade revenue are buried in transaction price
Total recognized revenue $15,090.00 New GAAP:
Maintenance revenue and warranty revenue are buried in transaction price Total recognized revenue $ 806,405.00
New IFRS: Maintenance and upgraderevenue is separate POB
Total recognized revenue $15,090.00 Maintenance and upgrade is amortized for 36 months recognized every quarter for 12 quarters
Maintenance revenue and warranty revenue are separate POBs

Contract start Q1 2016 Q2 2016 Q3 2016 Q4 2016 to Q4 2018 Total
Subsidized optional detailing service as a separate distinct POB 1 2 3 4 -36
Contract start Month Month Month Month Total Current GAAP $806,405.00 0 0 0 $- $806,405.00
1 2 3 4-36
New GAAP $685,444.25 $10,080.06 $10,080.06 $10,080.06 $90,720.56 $806,405.00
Current IFRS $15,090.00 0 0 0 $-
Note: This example is only for illustration purposes. The revenue recognition process may vary per industry.
New IFRS $13,219.97 $51.95 $51.95 $51.95 $1,714.19 $15,090
Note: This example is only for illustration purposes. The revenue recognition process may vary per industry.
Figure 1.3 Impacted Industries: High-Tech Industry
Figure 1.2 Impacted Industries: Automobile Example

You now should have a better idea of the impact these new accounting standards
will have. However, its also important to understand what tools are available to
Impact on the High-Tech Industry
support adoption and transition to the IFRS 15 standards. Well address this topic
For the next example, lets look at the high-tech industryspecifically the soft- in the next section.
ware industry. For this example (see Figure 1.3), the software license costs are
$806,000 for a period of three years. The SSP of the software license is $850,000,
and the maintenance is $15,000. 1.2.3 Existing Tools and Vendor Analysis Matrix
Currently, one of the biggest challenges businesses face is to choose the right
Under the current IFRS, the total amount is recognized immediately. However,
vendor tool to support and fulfill the revenue automation capabilities needed to
with the new IFRS 15 standard, a portion of the transaction price is allocated to
transition to the new revenue standard. Companies that currently use SAP ERP
maintenance and upgrades. The transaction price allocated to the license can be
Financials can leverage the new SAP RAR solution to address their revenue auto-
recognized immediately; that is, 85% of the revenue is recognized immediately.
mation needs.
However, 15% of the revenue is deferred and will be recognized ratably over the
next twelve months. This may not exactly replicate a typical scenario, but it illus- To capitalize on market needs and fill the new revenue guideline gaps, many ven-
trates the basic effects. In practice, you may have a number of components associ- dors have developed new revenue guidelinerelated packages and are attracting
ated with the contract, such as training vouchers, discounts, commissions, and so various customers at marketing shows, demos, and sponsorships.
on.
Vendors play a major role in a firms performance, and firms use vendor analysis
to select the right vendors for their organization. In this section, well look at how
24 25
to perform a vendor analysis and what parameters should be considered to final- Cost
ize a tool selection. Other customer references and feedback
As part of the vendor capability analysis, companies can ask various vendors to
What Is Vendor Analysis? submit a response for a request for proposal (RFP) based on the previously listed
A vendor is a firm or an individual that has a product or service for sale. Firms parameters.
depend on a vendors ability to meet their needs in order to efficiently perform
Its important to ask each vendor to provide a tool demo based on an organiza-
the functions of their business. Therefore, its important for a firm to choose ven-
tions new guideline requirements.
dors that can meet their requirements. Firms use a process known as vendor
analysis to assess the abilities of existing or prospective vendors. Its up to the business team to short-list companies and call for RFPs and demos to
rate individual vendors and finalize the supplier selection.
Vendor analysis identifies the strengths and weaknesses of each vendor, then
compares them to find the vendor that best matches the needs of a company. A Now that you have an understanding of how to analyze vendors based on pre-
vendor analysis is conducted whenever a firm needs to find a new vendor or defined parameters, lets look at how SAP specifically is addressing the new IFRS
review the performance of its existing vendors. Now, lets examine the vendor 15 requirements for their customers.
analysis process.
1.2.4 How SAP Is Addressing the New Requirements

Vendor Analysis Process and Parameters SAP took an active role in the standard setting process as the new standards were
As part of the vendor capability analysis, companies need to review various designed and drafted. The 2008 financial crisis demanded new and transparent
parameters and rank or score each vendor. The main parameters a company regulations that support a sustainable model for ongoing globalization. Both the
should consider are as follows: FASB and the IASB boards developed a framework for reporting revenue with uni-
fied requirements. Companies are required to be compliant with the accounting
Company profile
standards to maintain transparency. After six years of collaboration effort both the
The size, partner ecosystem, roadmap, and vision should be considered. Is this
IASB and the FASB announced the new standards in May 2014 with an effective
vendor a world leader in enterprise applications, or are they a smaller, less
date of FY 2017.
experienced company?
Vision and viability SAPs solution not only focused on meeting the regulatory requirements but
adapting to upcoming changes from regulations and customers. Some of the
Functional capabilities for GAAP/IFRS compliance
important factors include:
How many of the requirements of GAAP/IFRS does this vendor meet?
High performance revenue recognition
Master data and reporting capabilities
Due to ongoing globalization and localization, corporations are expected to
Technical capabilities
report with more transparency. In order to facilitate this requirement, compa-
These include the vendor's integration with other systems, architecture, flexi-
nies are expected to provide detailed disclosures, which are clearly auditable.
bility, and scalability.
This requirement demands the software be more robust to data handle vol-
Operational capabilities umes and facilitate all the requirements pertaining to transparency.
These include the vendor's capability for implementation, security, high avail-
ability, and support.
26 27
Highly automated processes (but not enough to claim that the product was complete), including prospective
When dealing with huge volumes, any performance issues can trigger an unau- contract modification in version 1.1, which was released to customers in late Sep-
ditability of the numbers. Handling huge data volumes manually is impractical tember 2015. The current version (1.2) was released for early adoption customers
and prone to risks and failure. Software is expected to define flexible rules for in early June 2016 and then to all other customers in November 2016.
automating the revenue recognition process with as less manual intervention
In this section, well outline the major functionality provided as part of SAP RAR
as possible.
version 1.2, including a brief look at the different releases.
Decoupling operational transactions from accounting
Currently most of the existing software solutions tightly integrate sales with
accounting. However the upcoming regulations require more details to be Parallel Accounting
stored at a POB and contract level. Also, many customers use legacy systems for A major area of IFRS 15 is disclosures reporting, and during the transition period
processing their sales and exclusively use financial systems for reporting. Not to IFRS 15, companies must prepare a dual reporting for multiple years to satisfy
all the necessary details are stored at operational (delivery/invoice) level. There the transition requirements.
is a greater need to decouple sales from accounting to facilitate the needed
SAP will support either a parallel ledger approach or an additional accounts approach
details to the contracts. This design will lower overall total cost of ownership
for parallel accounting. Most customers who use the new General Ledger (G/L)
(TCO).
will adopt the parallel ledger approach. Companies not yet using the new G/L will
Transitioning from existing revenue recognition solutions use the additional accounts approach. Both options are completely supported by
Customers may be using existing solutions from various sources. The new soft- SAP RAR and are complemented by best practices from the industry.
ware should be able to provide an easy transition to a new release to support
SAP doesnt recommend using either a special purpose general ledger or parallel
dual reporting (supporting multiple GAAPs) without interrupting existing con-
company codes for parallel accounting, as data can be manipulated and may raise
tracts.
audit issues.
SAP is considering these challenges, and is actively pursuing and preparing for
SAP RAR is designed to support dual reporting (i.e., existing US-GAAP/IFRS as
this change from several years. At the time of publication, SAPs new revenue
well as future US-GAAP/IFRS 15). If companies are already using IFRS/US-GAAP
accounting solution been deployed at seven different productive customers as of
in a leading ledger to support the new revenue accounting standards, such com-
September 2016 and a number of customers are in the early adoption program.
panies can adopt either a parallel ledger approach or an additional account
SAP is aggressively scheduling their software releases (four releases since Septem-
approach to accommodate dual reporting. A leading ledger maintains the same
ber 2014) to help customers with various demands that are arising as part of the
accounting principles as consolidated financial statements. If you choose to use a
implementation process. Based on the current strategy, the going forward
ledger approach, then at the end of the dual reporting period you may need to
approach for supporting the revenue recognition process is through the new SAP
initiate a new G/L migration project to switch ledgers. The recommended
RAR application. This application is built as a common framework, which sup-
approach is to use the G/L accounts in the leading ledger, use different financial
ports most of the revenue requirements of different industries.
statement versions (FSVs) to represent the postings, and discard the classic G/L
accounts at the end of the dual reporting period.
1.2.5 Functionality Overview
Table 1.1 provides an example of the parallel ledger approach, where 0L rep-
Version 1.0 of SAP RAR was released with very limited functionality in Septem-
resents the leading ledger and 1A is the nonleading ledger. Here, only one FSV
ber 2015 to ramp up customers. SAP subsequently added more new functionality
represents two years of dual reporting.
28 29
Ledger Dual Reporting Dual Reporting New Revenue To explain this clearly, refer to Figure 1.4. In this case, there are two FSVs repre-
Year 1 (2016) Year 2 (2017) Reporting senting two different standards (i.e., FSV-I represents IFRS, and FSV-II represents
(2018) IFRS 15).
GAAP/IFRS 0L (40000 0L (FSV1) 0L (FSV1) Drop current
(current 499999 and revenue (may Parallel Account Approach
revenue) 500000 want to keep 0L IFRS 15 pure
599999) still active for IFRS
accounts
pure accounts
audit purposes) 705000 - Invoice Corr
905000 - Invoice Corr 700010 - Receivable Adj
GAAP/IFRS 15 0L (40000 1A (FSV1) 1A (FSV1) Switch ledgers 900010 - Receivable Adj 700050 - Contract Asset
(new revenue 499999 and to leading led- 900050 - Service/Device Revenue 705040 - Product Revenue
900020 - Deferred Revenue 705050 - Service Revenue
accounting 500000 ger (may need 700020 - Deferred Revenue
599999) new G/L migra-
tion)
FSV I (Acct Group 1) FSV II (Acct Group 2)
Table 1.1 Parallel Accounting (Ledger Approach) Common accounts
100000 - Cash
400000 - Revenue
Table 1.2 illustrates the parallel accounting accounts approach. This approach 100400020 - AR
uses multiple FSV's for two dual reporting periods. It involves increasing the
chart of accounts. Accounts must be maintained for two FSVs, and at the ending
of the dual reporting period, the accounts must be blocked and no additional
work is required.
Figure 1.4 Parallel Accounts
Account Dual Reporting Dual Reporting New Revenue

Range Year 1 (2016) Year 2 (2017) Reporting Multiple-Element Arrangement
(2018)
One of the most salient challenges of the adoption of the new standards is the
GAAP/IFRS 0L/Account Ledger 0L/ Ledger 0L/ Drop current rev- accounting for multiple-element arrangements. It can be a challenge to handle this
(current group 1 Account group Account group enue FSV (block
requirement, because all the data required for accounting the multiple element
revenue) 400000 1 (FSV1) 1 (FSV1) accounts for
499999 and account group 1 arrangement may not reside in a single source, and there may be significant time dif-
900000 so no postings ferences between each source. For example, a typical telecommunications company
999999 can happen to has multiple source systems that store hardware, network services, discount informa-
them) tion, and other services offered by companies separately in different source systems.
GAAP/IFRS 15 0L/Account Ledger 0L/ Ledger 0L/ Use FSV2 for Even companies that are using the sales order process may not have all the informa-
(new revenue group 2 Account group Account group reporting (no tion in one spot and may have to connect multiple sources arriving at different times.
accounting) 400000 2 (FSV2) 2 (FSV2) migration proj-
499999 and ect required, you Based on the industry and type of business, multiple-element arrangement may
700000 may continue to include various types of POBs with different transaction prices and different
799999 use leading types of allocation processes among these elements. The arrangement can
ledger)
become increasingly complex when the requirements deal with multiple alloca-
Table 1.2 Parallel Accounting (Accounts Approach) tion groups and prorations with allocations in different periods.
30 31
Proration Functionality tomer entered into a 24-month contract for a subsidized device and a service con-
One of the most common concerns from customers is when contracts begin at tract, and after one month, the customer is charged with an activation fee.
different times, they would like to prorate these contracts based on different
Contractual
Recognized
rules. These proration rules can be set up at a POB level for time-based POBs. SAP
SSP Total
Allocated
Quantity
Quantity
Revenue
has delivered close to seven proration rules; if none of the proration rules meets
Period/
Month
Fulfill
Price
a customers requirements, the customer can define its own rules using a custom
Business Add-ins (BAdIs).
Handset April 2015 $139.99 $610.95 $420.35 1 100% $420.35
This proration functionality is part of the core functionality provided with ver- (First month)
sion 1.2 of SAP RAR, along with other functionalities, such as recognizing capital- Service April 2015 $1,080.00 $972.00 $799.64 1 6% $48.13
ized contract costs, cost recognition, automatic order revenue accounting item (24 months) (First month)
(RAI) creation from invoices, contract asset/liability determination at a POB level, Total $1,219.99 $1,482.95 $1,219.99 $468.47
SAP ERP Project System (PS) integration, CO-PA integration, advanced contract
modifications, and so on. Well try to address as much as possible with relevant Table 1.3 Contract Modifications: Cumulative Catch-Up (After the First Month)
examples throughout the book.
Contractual
Recognized
All that said, SAP RAR is still evolving as requirements from customers are emerg-
SSP Total
Allocated
Quantity
Quantity
Revenue
ing. SAP has released three versions of the product (at the time of publication),
Period/
Month
Fulfill
Price
which now addresses most of the common requirements from customers. How-
ever, there are multiple facets of complexity associated with requirement is from
various industry solutions, such as multicurrency, intercompany, taxes, time Handset May 2016 $139.99 $510.95 $432.41 1 100% $432.41
(Second month)
value of money calculations, tight integration with SAP ERP PS, SSP determina-
tion, call-off order functionality, and so on, which have yet to be addressed in Service May 2016 $1,080.00 $972.00 $822.58 1 6% $49.51
(24 months) (Second month)
future releases.
Activation Fee May 2016 $35.00 $0.00 $0.00 1 0% $0.00
(One-time charge) (Second month)
Contract Management Total $1,254.99 $1,482.95 $1,254.99 $481.91
There are several elements of contract-related functionality that can be found in
Table 1.4 Contract Modifications: Cumulative Catch-Up (After the Second Month)
SAP RAR. The following sections look at these areas.
Prospective change (contract modification)
Contract Changes
Considering the same example, lets say that theres no activation fee, and the
A contract modification is a change to a contract in the scope or price (or both) that
customer modifies the contract and adds a payment of $139.99 for a subsidized
is approved by the parties of a contract. Contract changes can include the follow-
handset. The customer pays $45.00 per month for service, increasing to $65.00
ing:
in the second month and thereafter. Because we already recognized the first
Cumulative catch-up/retrospective changes month, the contract modification would be as shown in Table 1.5 and Table 1.6
Table 1.3 and Table 1.4 show an example of a cumulative catch-up/retrospec- (first month and second month, respectively).
tive change. To use on example from the telecommunications industry, a cus-
32 33
Contract Asset/Contract Liability
Contractual
Recognized
Recognized
Cumulative
Based on the new IFRS 15 standards, the presentation of revenue becomes obso-
SSP Total
Allocated
Quantity
Quantity
Revenue
Revenue
Period/
Month lete, for the most part. Instead, in IFRS 15, this concept is replaced by contract
Fulfill
Price
asset/liability. A contract liability is a company's obligation to transfer goods or
services to a customer for which the entity has received consideration from the
Handset April 2016 $139.99 $510.95 $420.35 1 100% $420.35 $420.35
(First customer. This concept is slightly different from deferred revenue, which is typi-
month) cally recognized upon the instance of an invoice.
Service April 2016 $1,080.00 $972.00 $799.64 1 6% $48.13 $48.13 To better understand contract asset/liability, lets look at the telecommunications
(24 month (First example originally introduced in Section 1.2.2 (see Table 1.7). In this example,
contract) month)
when the system receives the contract information and allocates the revenue, the
Total $1,219.99 $1,482.95 $1,219.99 $468.47 $468.47 allocable amount is automatically attributed to the corresponding contract asset/
Table 1.5 Contract Modifications: Prospective Change in First Month liability. Simply, whenever the invoiced amount is lower than the revenue recog-
nized, then the difference is presented as contract asset (as any receivable amount
has been deducted). However, whenever the customer is invoiced more than the
Contractual
Recognized
Recognized
Cumulative
recognizable revenue (in this case, one month of advanced billing) the entity, is
SSP Total
Allocated
Quantity
Quantity
Revenue
Revenue
Period/
presented as a contract liability.

Month
Fulfill
Price
Transaction Price Contract Asset Contract Liability

Handset May 2016 $139.99 $510.95 $420.35 1 100% $420.35 $420.35
Contract value $1,724.95 $315.77 0
(Second
(total transaction price)
Month)
Sum of recognized revenue $578.22
Service May 2016 $1,310.00 $1,179.00 $1,029.64 1 8% $42.07 $90.20
(24 month (Second Sum of all issued invoices $262.45
contract) Month)
Table 1.7 Contract Asset and Liability Example
Total $1,449.99 $1,689.95 $1,449.99 $462.42 $510.55
Table 1.6 Contract Modifications: Prospective Change in Second Month For customers using SAP RAR for their current IFRS, the system can determine
the unbilled receivables and deferred revenue amounts rather than contract as-
Mixed change (prospective and retrospective change) sets and liabilities (relevant for IFRS 15).
Because contracts can be complex, there can be instances in which contracts
may have to adopt both prospective and retrospective changes (at the POB Note
level) at the same time. SAP RAR is designed to handle these scenarios based on Depending on the type of transaction and timing associated with the contract(s), there
the defined set of rules simultaneously. may be a greater need for contracts to be combined. For example, you might have a
master contract for licensing with a software vendor and may have subcontracts that
originated at different times. Under the current IFRS, these would be treated as separate
contracts. But under the new guidelines a single contract and revenue might have to be
allocated from the master contract to subcontracts or vice versa. This feature was avail-
able in SAP RAR version 1.1, but version 1.2 makes it much more flexible and user
friendly.
34 35
Deferred Costs/Deferred Revenue Compound POBs are used with reference to leading and linked POBs in order
Deferred costs are also referred to as commission assets. Typically, deferred costs to group the into a single compound. In this case, the compound is the distinct
are recognized for sales commissions and contact fulfillment costs. Functionalities POB. For example, if an entity is selling a service and offering a three-month
for deferred costs were introduced in SAP RAR version 1.2. complementary service, then the two components can be bundled into a com-
pound and revenue for the compound can be recognized based on a single pat-
Figure 1.5 shows the Account Determination in SAP RAR for Deferred Revenue tern. If the two components of the bundle are priced separately when revenue
and Unbilled Receivable versus Contract Liability and Contract Asset. is recognized, certain amounts within the compound might be re-allocated to
arrive to a single recognition pattern.
Fulfillment of performance obligations
Performance obligations can be fulfilled by the following methods:
Event-based (specific occurrence)
Time-based (over a period of time)
Percentage of completion (percentage of project completion)
Figure 1.5 Account Determination in SAP RAR Manual (recognize revenue manually)
Revenue can be recognized based on the triggers set up in the system. For exam-
Performance Obligations ple, for a network service of a telecom company, time-based revenue recogni-
Theres a lot of functionality in SAP RAR to consider when it comes to POBs. In tion may be a good fit; for a handset on a telecom contract, delivery of the device
the following subsections, well look into these important concepts. along with activation may be a good trigger; and for a software implementation
project, the PoC method makes sense. If for any reason none of these are appli-
Leading performance obligations and linked performance obligations
cable, the system can be configured to recognize revenue manually (but this
Often, contracts have to be designed to have a parent-child relationship. For
option isnt recommended for high-volume businesses).
example, if a high-tech company is selling software and provides optional ser-
vices associated with specific POBs, such as free upgrades, training, consulting Right of Return
support, and so on, then the software contract can be set up as a leading con-
Right of return is defined at the POB level. Right of return applies in situations in which
tract, and the other free services can be added as linked POBs.
a company may need to refund all or part of the expected return for a sales item to a
Distinct vs. nondistinct and compound performance obligations customer. In doing so, its necessary to specify the percentage of the expected return
Distinct versus nondistinct and compound POBs is a complex area to explore, and post it as a refund liability. Depending on the need, a portion of the revenue can be
and often the attributes distinct and nondistinct can sometimes lead to confu- identified and deferred for the right of return and can be recognized in the future (if the
right of return has not been executed).
sion. A nondistinct POB cant stand on its own (i.e., it cant be sold used on its
own). For example, the activation fee with a telephone contract is treated as a
nondistinct POB. However, in SAP RAR a nondistinct POB is similar to a child Posting and Reconciliation Process in SAP RAR
in a linked POB. Any POB thats set up independently is treated as distinct in SAP RAR is tightly integrated with the G/L. During month end, when batch jobs
nature. This is not to be confused with the definition from IFRS (e.g., in the pre- are run, postings pertaining to contracts are posted directly to the G/L with all the
vious example, the activation fee could be set up as distinct or could be added relevant financial information summarized. All the validations and substitutions
as a condition record in the main contract). and 999-line restrictions are still applicable to these postings from SAP RAR.
36 37
Because the G/L contains only the summarized and consolidated account balances 1.2.6 Licensing Options
(of all contracts), which is used by dual reporting, SAP has built in checks and bal- SAP takes compliance and regulatory requirements seriously and gives the high-
ances required to reconcile the summarized postings with SAP RAR, and SAP RAR est priority to all open development requests. SAP puts a lot of emphasis on cus-
has standard reports that can reconcile the postings at the contract level. tomer feedback and prioritizes development goals based on customer needs. As
part of the standard SAP ERP licensing, SAP offers SAP RAR at no additional
Integration license fee. There is a formal process for becoming an early adoption customer,
which allows a customer to work with SAP and contribute to product develop-
Some important integrations between SAP RAR and other solutions include the
ment, including relevant industry-specific requirements. General availability
following:
(GA) versions of each release are open for all customers to download and install.
SAP Hybris Billing Please refer to http://support.sap.com/swdc/ for more information about how to
SAP RAR has been compatible with SAP Hybris Billing from SAP RAR version become a ramp-up customer/early adoption customer.
1.1 onwards. More information on SAP Hybris Billing can be found in Section
There are some prerequisites for implementing the SAP RAR add-on. Please refer
1.2.8.
to SAP Note 2175281 for more information on installing the new revenue recog-
SAP BusinessObjects BI/SAP Business Warehouse (SAP BW) nition solution 1.1.
As previously mentioned, SAP RAR is treated as a submodule for the main gen-
eral ledger. All the underlying details reside in the submodule; only the sum- Although SAP RAR itself is covered under the standard license, and SAP also
marized postings reside in the main general ledger. SAP has provided a stan- offers comprehensive documentation for configuring SAP RAR, this is a relatively
dard extractor to extract all the revenue details into SAP BusinessObjects BI or new product with not many implementations, so its recommended to get help
SAP Business Warehouse (BW) so that revenue can be sliced and diced for man- from SAP or SAP-preferred partners when implementing this solution. Its essen-
agement, disclosure, and audit purposes. tial to work through some background tasks before starting the implementation
process; each industry is different and has to comply with different requirements.
Business Rule Framework plus (BRF+)
Refer to Chapter 2 for more information on the project implementation process.
SAP RAR leverages BRF+ functionality for deriving the key attributes for per-
formance obligations. BRF+ is an independent standalone application thats
flexible and dynamic in nature and that can be integrated with SAP RAR appli- 1.2.7 Architecture and Landscape
cation quite easily. BRF+ is a comprehensive API and UI for processing and As previously mentioned, SAP RAR is a decoupled application and is designed to
defining business rules, allowing you to model business rules and reuse them work as a standalone application to meet the new IFRS 15 revenue standards. In
in different applications. this section, well discuss the underlying architecture and how the five-step
framework is integrated within SAP RAR architecture.
Reporting in SAP RAR
SAP RAR provides basic reporting at the contract or customer level, but the Basic Architecture
reporting and audit capabilities are limited. However, all the required data, Revenue accounting is a critical piece of the revenue recognition process. All the
including the change logs, is available in the repository and can be reported easily source systems can be integrated directly into SAP RAR which contain the con-
with custom reporting. All the postings made from SAP RAR will be compliant tracts) through the adapter reuse layer (ARL), in which the business rules are
with dual reporting. transformed to derive the respective attributes for the corresponding POBs. The
38 39
same information is then transferred into SAP RAR. This information is then used 3. RAI4
later to recognize the revenue according to the defined rules. This is a processed RAI; at this stage, the revenue accounting contract is success-
fully created and is linked to the originating order.
In Figure 1.6, notice that source systems such as SAP ERP SD, SAP CRM, SAP
Hybris Billing, and third-party applications like Data Hub are integrated with SAP There are few BAdIs supplied as part of these processes. Customers not using
RAR through ARL. The source applications generate RAIs to pass the contract Data Hub or third-party applications can directly integrate their applications into
information to SAP RAR. Applications which reside in an SAP ERP environment, these corresponding RAI stages to integrate with SAP RAR.
such as sales orders from the SD module, can be configured to automatically gen-
erate RAIs and can be processed through ARL automatically. Third-party applica-
Business Rule Framework Plus
tions can use a normalized approach, like Data Hub, and imitate SD to process the
RAIs. The most prominent component in the ARL is the BRF+ application. BRF+ is a
standalone application that can derive the attributes relevant for the revenue
accounting contract via predefined business rules. BRF+ is a central design tool/
SAP
SAP SAP rules framework integrated not only with revenue accounting but also with SAP
SAP ERP Adapter Reuse Layer Revenue Accounting
SAP ERP SD SD IC CRM, SAP SRM, custom applications, banking applications, and more.
Configuration Revenue
and Mapping Accounting Contract
SAP ERP Generation RAI - POB Figure 1.7 provides a look at the BRF+ framework for processing business rules.
SAP ERP FIN
FIN IC POB 1
Revenue Accounting
Contract POB x
Revenue Accounting Add-on
SAP CRM SAP CRM IC POB 1 Accruals
RAI POB: Right of Return management Adapter Revenue SAP ERP
POB 2
Accounting Engine Financials
SAP Hybris SAP CRM Storage POb: Right of Return POB: Upgrade Right Data provisioning Revenue
Billing/ Provider/Order/ General
POb: Upgrade Right Accounting Contract Ledger
Rule: determine whether item is distinct

O2C SOM Contract IC RA Process Information lifecycle Performance Obligation
Rule: for combination of contracts

Mass Business RAI from
Rule: determine other clauses

management (POB) 1
Rule: derive additional POBs

rules management operational systems
SAP Hybris Convergent processing Revenue Accounting Contract Performance Obligation CO-PA
(e.g., Right of Return)

Rule: determine SSPS
Order/Contract (POB) x
Rule: derive POBs

Billing/CI Invoicing IC BRF+ Results Order/Contract
Performance Obligation (POb) 1
CO-PA GL POB: Right of Return
Analysis Performance Obligation (POb) 2
Item
POB: Upgrade Right

POb: Right of Return
SAP Item
SAP POb: Upgrade Right
IC
Third-party
Figure 1.6 Decoupled Architecture Business Rules Framework plus
Fair Estimations
There are typically three stages in RAI processing, but with the integrated values
approach we can skip a few stages by going to processed status without going
Figure 1.7 BRF+ Framework
through checks and putting the RAI items into a RAW status:
1. RAI0 BRF+ acts as an API as well as a UI for defining and processing business rules. The
This is a raw RAI item; no validations are performed at this stage. rules can be modeled in an intuitive way and can be reused in different applica-
2. RAI2 tions.
This is a processable RAI; all validations are performed in this stage, such as
valid master data, appropriate POB, company codes, and so on.
40 41
Example use cases for BRF+ include the following: All these steps are facilitated through the embedded architecture of SAP RAR, as
illustrated in Figure 1.8. Note that the controls are provided before and after the
Validating invalid data and correcting the data
ARL in order to provide provision for customization.
Calculating costs, overhead, and risks
Identifying the true market value/fair market price (SSP) for a POB
Operational SAP ERP
Identifying proration logic Systems Operational process stream
Identifying the type of POB (i.e., distinct, nondistinct, compound, etc.) Delivery/
Billing/ Accounts
SAP Sales Goods Issue/ GL
Invoicing Receivable
Major BRF+ components include applications, functions, catalogs, expressions, and Distribution Service Usage
(SD)
actions, and data objects, and SAP RAR leverages BRF+ functionality to derive key
attributes for performance obligations. SAP CRM SOM
SAP Billing
Five-Step Framework in SAP RAR Order/ and Revenue Multi-
Contract Innovation Ledger
Management
As outlined previously in Section 1.2.1, the five steps associated with the new Revenue Accounting Stream
revenue recognition rules are as follows: Other SAP Reconciliation
Control Control
Components
Flexible Revenue Allocation
1. Identify the contracts revenue Business accounting fulfillment
Non SAP rules
Identify all contracts that are impacted by the new revenue accounting rules. 3rdSAP
Party
accounting contract accruals
Profitability
Non guidelines
Systems Analysis
This step is performed at the RAI item generation level. If an item is passed to Third-party
Systems
SAP RAR without any impact, then that transaction can be a pass-through entry
Fair Analytical
Management
in SAP RAR. Values Estimations
Reporting
2. Determine the POBs
Identify the POBs in the contract and their true nature. These rules are built Figure 1.8 Integrating Five-Step Process into SAP RAR
into the BRF+ framework application.

3. Determine the transaction price Components in SAP RAR
Determine the transaction price, which is identified at the source contract level SAP RAR acts as a submodule; all information pertaining to the contracts is stored
and can be adjusted later in the control section based on the proration, timing, within SAP RAR, and only the summarized information is sent to SAP ERP Finan-
and so on. cial Accounting, which is the main reporting ledger.
4. Allocation of the transaction price Figure 1.9 illustrates the SAP RAR architecture. Here, RAI items are processed
When allocating the transaction price, SAP RAR can automatically allocate the through the ARL, and the corresponding SAP RAR contracts with POBs are gener-
price based on the true market value. ated. Fulfillment and invoicing events are triggered by the ARL upon the receipt
5. Satisfaction of the POB of information, and the triggers are passed to the engine for recognizing the rev-
Recognize the revenue in SAP RAR based on the current rules. The engine can enue.
be configured to recognize revenue based on time, event, or percentage of
completion.
42 43
Data Provisioning
Adapter SAP RAR
Offers data sources for legal reporting and analytics.
Reuse Layer
User interface
Web Dynpro ABAP Legal Posting Management
Configurations Analytics
Reporting
FPM POWL This component creates postings of recognized revenue and invoice correc-
POB types tions. The following areas exist under this component:
accounting principles Data Provisioning
Contract Management
Analytical
Accrual Run: Creates aggregated actual postings to G/L and to CO-PA.
Process
Engine
Management Reconciliation: Explains the aggregation of posting data per POB into post-
Invoice Fulfillment
Data Access (Data Source)
ings.
Management Management
(Hana/classic DB)
POB Financial Accounting 1.2.8 Integration with Existing Revenue Applications

RA Contract
Posting Management FI G/L As a standalone decoupled application, SAP RAR can be integrated with multiple
Invoice events POB
Posting Reconciliation Accrual run applications to combine information from different systems into a single con-
POB Data CO-PA
Fulfillment events
Profitability Analysis tract. In this section, well outline some of the standard available integration
applications that can be linked to SAP RAR directly.
Figure 1.9 Components in SAP RAR
Integration with SAP Hybris Billing

As shown in Figure 1.9, the following components are part of SAP RAR:
The SAP Hybris Billing solution works with contracts from customers that must
User interface be compliant with the new IFRS 15 revenue guidelines. As part of standard sup-
Designed with Web Dynpro ABAP with Floorplan Manager. The personal port, SAP developed a standard integration between SAP RAR and SAP ERP 6.07
object work list is used for reviewing and error handling. SP09. This new solution is compliant with SAP RAR 1.1 and beyond.
Contract Management
SAP Hybris Billing works with various kinds of orders, such as standard SAP CRM
The Contract Management component in SAP RAR calculates price allocation
sales orders, Order Management, Convergent Charging (CC), Convergent Invoic-
among POBs. Within this component are three subcomponents:
ing (CI), and Convergent Accounts Receivable and Payable (FI-CA). The standard
Processes Management: This functionality offers manual SAP RAR process- SAP RAR integration with SAP Hybris Billing creates the relevant RAIs (order, ful-
ing. fillment, and invoice) directly from the corresponding applications within SAP
Invoice Management: Calculates effects from invoices, such as recalculating Hybris Billing (i.e., SAP CRM and non-SAP CRM applications). These RAIs will be
the contract asset/liability, reducing the POB value, terminating the POB, created similarly to standard sales order RAI items and will be processed through
and so on. ARL for setting up the contracts in the SAP RAR system.
Fulfillment Management: Determines revenue to be recognized from fulfill- Figure 1.10 shows the process flow from the SAP Hybris Billing integration point.
ment events. Notice that on the left, the SAP order-to-fill (standard sales order) process inte-
Invoice and Fulfillment Management trigger the calculation of contract asset/ grates highly with the SAP RAR solution. On the right side, notice that SAP Hybris
liability for the posting. Billing is integrated with SAP RAR as well.
44 45
SAP RAR version 1.1 is integrated with SAP Hybris Billing for SAP CRM 7.03 SP
09. Figure 1.10 illustrates the integration of different source systems into SAP SAP Hybris Billing:
Rating Billing & Invoicing A/R
RAR. Order/Contract
Master Data Replication
Convergent G/L
Provider
Invoicing (CI) Controlling
contract
Operational
Financial Convergent
Processes
Offer Order Pricing, Invoicing Credit Sales and Order

Revenue customer Charging Contract
management Order processing rating, and and
(incl. product capturing and
Mediation
and payment
and expense
collections
care and Management Billable accounting
management dispute items Invoicing
modelling) monitoring charging statements mgmt.
mgmt. Rating (Usage)
as of as of Sales and Trigger/mass activity
SAP ERP SAP CRM Distribution -
= Revenue Accounting relevant
Applications
6.07 SP09 7.03 SP09 Hardware

SAP ERP
CC CM by CC CRM Integration Component
SAP CRM
DigitalRoute (for CFM)
CI FI-CA
CPS CPS
Adapter Revenue Accounting
Invoices
Revenue
Revenue
Accounting
Fulfillments Update POBs Contract Allocation
Revenue
Revenue Accounting Accounting Fulfillment
Adapter Reuse Layer Add on 1.1 Order items
POB 1 Invoice
Revenue Accounting
Configuration Business Accruals
Mapping Revenue Hardware Contract
and service Rules
RAI - POB Accounting POB Hardware POB 2
generation
Contract
Revenue Accounting Contract Reconciliation Revenue POB Service POB Right
Allocation Accounting Items of Return
POB 1 Transformation
Fulfillment
Estimations
RAI POB 2 Accruals
Plan Values SAP ERP Financials Add-on
storage POB: Right of Return
POB: Upgrade Right
Business
Mass Figure 1.11 SAP Hybris Billing and SAP RAR Integration
processing rules
BRF+
Integration with Sales and Distribution-Based and Results Analysis-Based

Figure 1.10 Supported SAP Hybris Billing Integrated Versions with SAP ERP
Revenue Recognition
Figure 1.11 shows the process flow from contract to order creation through gen- Many SAP ERP customers use the standard delivered revenue recognition solu-
eral ledger postings. Note that none of the processes for SAP Hybris Billing are tion from the SD module. The SD-based revenue recognition solution is highly
impacted by any of the settings from SAP RAR. SAP Hybris Billing is integrated, integrated with sales, delivery, and invoicing processes within SAP ERP (as seen
and if there is an exception its handled within SAP RAR; the SAP Hybris Billing in Figure 1.12). This solution is designed only with the SD module as an input,
functionality is untouched and will be processed normally. SAP RAR can be inte- and it works, for the most part. The SD module is designed in such a way that
grated with Hybris Billing and has triggers everywhere that a process is relevant when invoices are posted to accounting instead of to a revenue account, they are
for the SAP RAR application (as shown with checkmarks in the flow through SAP posted as deferred revenue or unbilled receivables. This process widely depends
RAR. on the previous balances of recognized revenue from the invoiced amounts.
This module is integrated with delivery and based on the post goods issue, the
fulfillment events are triggered from the delivery, and fulfillment can be posted
to deferred/unbilled revenue. Service revenue can be recognized directly based
on the billing plan information upon invoicing.
46 47
Integrated solution in SD affecting FI and supporting different methods of Revenue Recognition Revenue from Recognized with
(time-based, event-based).
SD Revenue Recognition
Sales and Distribution Financials CO Event based revenue recognition
Sale from stock
based on contract fulfillments
Revenue recognition at time of billing
Accounts Receivables
Invoice Revenue recognition based on events
(goods issue, proof of delivery)
Order
Time-based revenue recognition
Billing plan Unbilled Receivables
Services Straight line method
periodic
milestone
Contract
Delivery Results Analysis
Deferred Revenues
Percentage of completion based on
planned revenue/planned cost
Billing plan Revenue Make to order/ Percentage of completion Cost based percentage of completion
periodic Recognition professional services
milestone Percentage of completion based on
Process project earned value
Revenues Completed contract
Controlling Profitability Analysis

Figure 1.13 Result Analysis-Based Revenue Recognition
Objects from Sales and Distribution affecting Revenue Recognition
Solution Revenue Recognition
Lack support for parallel accounting
Figure 1.12 SAP ERP SD-Based Revenue Recognition One of the major requirements for IFRS 15 or migrating from US-GAAP to IFRS
is to be able to report in both standards for a defined period of time. Existing
Other SAP ERP customers also use results analysis-based revenue recognition (as solutions are not designed to handle the parallel accounting/reporting require-
seen in Figure 1.13). This method mainly is targeted to recognize revenue based ments. Currently, even with the new G/L, existing solutions such as classic SD-
on the percentage of completion of the planned revenue/cost. This approach is based revenue recognition will always post to the blank ledger group, which is
prominent with the make-to-order/professional services approach. With this applicable for all ledgers in that group.
application, the revenue can be recognized based on the planned revenue/cost or Lack cost recognition
actual revenue/cost. Although the existing solutions are capable of recognizing costs, they lack the
Both SD-based revenue recognition and results analysisbased revenue recogni- cost of goods sold synchronization with revenue. They can recognize the costs
tion are robust solutions, but they do have a few limitations, such as the follow- only at goods issue or at billing time.
ing: Lack disclosure capabilities
The new revenue standards require new comprehensive disclosures, especially
Lack multiple-element arrangement
in the areas of revenue reconciliation and contract balances. The current solu-
Allocation among different elements originating from different contracts isnt
tions are not capable of handling these complex requirements.
possible; recognition is only made on the specific order line item defined in the
pricing on the line item.
48 49
1 Introduction to IFRS 15 and SAP Revenue Accounting and Reporting Summary 1.3
Data Hub Approach There are multiple solutions available in the market to address the upcoming IFRS
Most telecommunications companies dont use either SD-based or result analysis- 15 requirements, but SAP offers SAP RAR as a standard add-on for no additional
based revenue recognition. They currently use the pass-through approach (i.e., license cost to comply with these regulations. The success of the project relies on
they recognize revenue as it comes through, with some manual adjustments at the vendor who is implementing the project.
month end for the deferred revenue and with unbilled receivables). Although In addition, the new SAP RAR solution can be integrated with your existing reve-
SAP RAR is decoupled from SD, most of the underlying structures are based on nue applications and can be leveraged to meet the existing compliance and disclo-
the SD-based architecture. sure requirements as well as new revenue guidelines.
To overcome such complexities these companies are adopting an intermediate In the next chapter, well discuss the execution steps from implementing the proj-
layer of processingthat is, using the Data Hub approach. ect using SAPs best practices and methodologies.
In the Data Hub approach, data is gathered from various source systems, staged,
and processed in an SAP RAR-compatible language to input the details into the
revenue engine directly. In a way, the Data Hub approach acts like a simulated SD
environment, in which data is processed when complete information is received
from all source systems.
SAP RAR is designed to address all the limitations of SD-based and results analy-
sisbased revenue recognition. This solution is also designed to provide flexibility
and user friendliness for recognizing revenue. Because the standards are evolv-
ing, the product will become more mature in future versions. The current version
of the product meets most of the requirements of the new standards, but there
are quite a few requirements still to be met. For example, IFRS 15 includes a spe-
cial disclosure requirement to distinguish long-term revenue (noncurrent reve-
nue; usually over twelve months) and costs, from short-term revenue (current
revenue; usually less than twelve months) and costs, from time value money rec-
ognition, and so on. Potentially, many of these requirements will be covered as
part of future releases.
1.3 Summary
In this chapter, we introduced you to both the IFRS 15 requirements and the SAP
RAR solution. As we discussed, the new revenue regulations impact not only
IFRS, but also US-GAAP as well. The new effective date of these regulations is the
beginning of the 2018 fiscal year. Although these standards impact most indus-
tries, only a handful of industries are heavily impacted. Unlike other regulations,
IFRS 15 is not just a reporting requirement; its implementation must be treated as
a separate project by nature.
50 51
Contents
Foreword ......................................................................................................... 13
1 Introduction to IFRS 15 and SAP Revenue Accounting

and Reporting .......................................................................... 15
1.1 Global Accounting Standards ........................................................ 16

1.1.1 New Accounting Guidelines ............................................ 16
1.1.2 Business Challenges ......................................................... 17
1.2 IFRS 15 ........................................................................................ 18
1.2.1 Five-Step Framework for Revenue Recognition ................ 19
1.2.2 Impact of the New Standards .......................................... 22
1.2.3 Existing Tools and Vendor Analysis Matrix ....................... 25
1.2.4 How SAP Is Addressing the New Requirements ............... 27
1.2.5 Functionality Overview ................................................... 28
1.2.6 Licensing Options ............................................................ 39
1.2.7 Architecture and Landscape ............................................ 39
1.2.8 Integration with Existing Revenue Applications ............... 45
1.3 Summary ...................................................................................... 50
2 Project Execution Approach ..................................................... 53
2.1 Project Management .................................................................... 53

2.1.1 Agile Methodologies ....................................................... 53
2.1.2 Traditional SAP Implementations (ASAP Methodology) ... 55
2.2 Project Preparation and Scope ...................................................... 57
2.2.1 Project Preparation ......................................................... 57
2.2.2 Defining the Scope .......................................................... 58
2.2.3 Project Organization ....................................................... 59
2.2.4 Project Timelines ............................................................. 61
2.2.5 Change Management Considerations .............................. 63
2.3 Project Blueprinting ...................................................................... 64
2.3.1 Plan and Collect or Develop Use Cases ............................ 64
2.3.2 Organize Business Requirements Workshops ................... 66
2.3.3 Create Business Requirements Document ........................ 67
2.3.4 Validate and Get BRD Sign-Off from Business .................. 68
2.4 Project Design and Build .............................................................. 69
2.4.1 Prototype Use Case Solution ........................................... 69
7
Contents Contents
2.4.2 Identify Solution Gaps .................................................... 71

2.4.3 Identify Master Data, Integration, Change Management,
4 Processing Revenue Accounting Contracts .............................. 151
and Migration Requirements .......................................... 72
4.1 Revenue Accounting Items ........................................................... 151
2.4.4 Key Design Decisions ..................................................... 74
4.1.1 Generating RAIs from SD and Non-SD Applications ........ 151
2.5 Project Testing and Go-Live ......................................................... 75
4.1.2 Stages or Status of RAI Processing ................................... 153
2.5.1 Test Strategy and Execution ............................................ 75
4.1.3 Processing RAIs through the Adapter Reuse Layer ........... 158
2.5.2 Outline Best Practices, Challenges, and Risk-Mitigation
4.1.4 Customizing and Enhancing RAI Items ............................. 159
Strategy .......................................................................... 78
4.2 Revenue Accounting Contracts ..................................................... 160
2.5.3 Cutover Planning ............................................................ 80
4.2.1 Contract Processing: Navigation, Revenue Schedule,
2.5.4 Go-Live and Post-Go-Live Considerations ....................... 81
Amortization, and POBs .................................................. 160
2.6 Summary ..................................................................................... 82
4.2.2 Price Allocation: Prorations, Standard Options,
and More ........................................................................ 171
3 Configuring SAP Revenue Accounting and Reporting ............. 83 4.2.3 Contract Combinations .................................................... 175
4.2.4 Contract Fulfillment ........................................................ 178
3.1 Understanding Your Configuration Options ................................. 83 4.2.5 Invoices in Revenue Accounting Contracts ...................... 182
3.2 Application Installation Process ................................................... 85 4.2.6 Contract Asset/Liability Postings ...................................... 184
3.2.1 System Requirements ..................................................... 85 4.2.7 Revenue Recognition Process and Postings to FI ............. 188
3.2.2 Installing SAP RAR ......................................................... 86 4.2.8 Reporting and Disclosures ............................................... 199
3.2.3 Setting Up Item Classes .................................................. 89 4.2.9 Archiving Revenue Contracts ........................................... 203
3.2.4 Setting Up SAP Business Client ....................................... 89 4.3 Best Practices ............................................................................... 203
3.2.5 Integrating with SAP Business Warehouse ...................... 90 4.4 Version 1.3 Functionality .............................................................. 204
3.3 Configuration .............................................................................. 94 4.4.1 Foreign Currency Exchange Processing ............................ 205
3.4 Step-By-Step Configuration Guide ............................................... 96 4.4.2 Simplifications for High Volume Invoice Processing ......... 209
3.4.1 Inbound Processing ........................................................ 97 4.4.3 End to End Consistency Checks ....................................... 211
3.4.2 Revenue Accounting Contracts ....................................... 105 4.5 Summary ...................................................................................... 213
3.4.3 Revenue Accounting Postings ......................................... 131
3.4.4 Integration with SD and Non-SD Applications ................ 136
3.4.5 Configure UI/Web Dynpro .............................................. 137
5 Migrating Current IFRS Contracts to IFRS 15 Using
3.4.6 Postconfiguration Requirements ..................................... 141 SAP RAR ................................................................................... 215
3.4.7 Best Practices for Configuration and Technical Settings ... 142
3.5 BRF+ Integration ......................................................................... 142 5.1 Migration Strategy and Planning ................................................... 215
3.5.1 Architecture and Features .............................................. 143 5.1.1 Migration Strategy .......................................................... 216
3.5.2 BRF+ Applications .......................................................... 145 5.1.2 Migration Plan ................................................................ 220
3.5.3 BRF+ Decision Tables ..................................................... 146 5.1.3 Migration Challenges ...................................................... 222
3.5.4 Account Determination in BRF+ ..................................... 146 5.1.4 Migration Timelines ........................................................ 223
3.5.5 Version and Transport BRF+ Applications ....................... 148 5.1.5 Migration Scenarios ........................................................ 224
3.6 Summary ..................................................................................... 149 5.1.6 Migration Risks and Plans for Contingencies .................... 225
5.2 Migration Process ......................................................................... 227
5.2.1 Migration Configuration .................................................. 227
5.2.2 Migrating SD-Based In-Process Contracts ........................ 232
5.2.3 Test Strategy and Considerations for Migration Process ... 248
5.2.4 Reconcile Migrated Contracts .......................................... 250
8 9
Contents Contents
5.2.5 Migration in Cutover Process .......................................... 250 7.2.4 Implementing SAP RAR in the High-Tech Industry .......... 328
5.2.6 Error Handling during Migration ..................................... 251 7.2.5 Best Practices and Lessons Learned ................................. 341
5.3 Best Practices in Migration .......................................................... 252 7.3 Summary ...................................................................................... 341
5.4 Summary ..................................................................................... 253
8 Conclusion ................................................................................ 343
6 Transition Strategy and Options .............................................. 255
8.1 Dont Take IFRS 15 Projects Lightly .............................................. 343
6.1 Possible Effects during Transition ................................................. 257 8.1.1 Implementation Date ...................................................... 344
6.1.1 The Black Hole Effect ..................................................... 257 8.1.2 Requirements .................................................................. 344
6.1.2 Recycling of Revenues .................................................... 260 8.1.3 Internalizing the Five-Step Model ................................... 345
6.1.3 Capitalization of Contract Costs ...................................... 263 8.2 Choose the Right Transition Method ............................................ 345
6.2 Full Retrospective Transition Approach ........................................ 266 8.2.1 Hybrid Model-I ............................................................... 346
6.3 Modified Retrospective or Cumulative Catch-up Transition 8.2.2 Migration Scenarios ........................................................ 347
Approach .................................................................................... 271 8.2.3 Third-Party Systems ......................................................... 348
6.4 Modified Retrospective Transition Approach with Retrospective 8.3 Good Project Management Makes for Successful
Pro Forma (Hybrid Transition Method 1) ..................................... 273 Implementation ............................................................................ 348
6.5 Modified Retrospective Transition Approach with Prospective 8.3.1 Scope and Milestones ..................................................... 348
Pro Forma (Hybrid Transition Method 2) ..................................... 274 8.3.2 Big Bang versus Agile ...................................................... 349
6.6 Parallel Accounting ...................................................................... 278 8.3.3 Resources ........................................................................ 349
6.6.1 Account-Based Solution ................................................. 278 8.3.4 Prototyping ..................................................................... 350
6.6.2 Ledger-Based Solution .................................................... 280 8.3.5 Focus .............................................................................. 350
6.6.3 Dual Reporting ............................................................... 282 8.3.6 Roles and Responsibilities in an IFRS 15 Project .............. 350
6.7 Transitioning Example (End-to-End Flow) .................................... 283 8.4 Choose the Best Design for Reporting ........................................... 352
6.7.1 Current Postings under IFRS (IAS 11/IAS 18) .................. 284 8.4.1 Considering Both GAAPs ................................................. 353
6.7.2 Transition Steps .............................................................. 284 8.4.2 Ledger versus Account Approach .................................... 353
6.8 Transactions Overview ................................................................. 294 8.4.3 Meeting Disclosure Reporting ......................................... 354
6.9 Best Practices .............................................................................. 296 8.4.4 Reconciliation ................................................................. 354
6.10 Summary ..................................................................................... 297 8.5 Overcome Technology Challenges ................................................ 355
8.5.1 Special Landscaping Requirements .................................. 356
7 Business Cases: Telecom and High-Tech ................................. 299 8.5.2 Testing ............................................................................ 358
8.6 Links and Additional Information .................................................. 359
7.1 Telecom Industry Business Case ................................................... 300
7.1.1 Use Case Overview ......................................................... 300 Appendices ...................................................................................... 361
7.1.2 Impact of IFRS 15 on the Telecom Industry .................... 300
7.1.3 Challenges for Many Telecom Companies ....................... 302 A SAP RAR Application FAQs ...................................................................... 361
7.1.4 Implementing SAP RAR in the Telecom Industry ............ 306 B The Authors ............................................................................................. 369
7.1.5 Best Practices and Lessons Learned ................................ 324
7.2 High-Tech Industry Business Case ................................................ 325 Index ............................................................................................................... 371
7.2.1 Use Case Overview ......................................................... 325
7.2.2 Impact of IFRS 15 on the High-Tech Industry ................. 326
7.2.3 Challenges for High-Tech Companies .............................. 327
10 11
Index
A BRF+ Rules Repository, 144

BRF+ Workbench, 143
Account approach, 353 Business case, 299
Accounting principles, company codes, 119 Business function, FIN-CO-COGM, 108
Accounting principle-specific settings, 115 Business Rules Management System, 143
Adapter reuse layer, 134
Agile, 53, 349
ALE RFC setup, 88 C
Allocation effect, 172
Allocation price, 171 Capitalization of contract costs effect, 264
Amortization, 163 Change management, 63
Application installation, 85 CO object setup, 109
Archival setup, 88 Commission asset, 36
ASAP methodology, 55 Comparative reports, 242
project organization, 59 Condition type, 124
project preparation, 57 roles, 126
scope, 58 Configuration, 94
ASC 606/IFRS 15, 18 Configuring SAP RAR, 83
Automotive industry, 23 Contract
shift to next period, 196
Contract asset/liability, 35, 332
B calculation, 186
postings, 184
BAdI, 185 Contract balance, 200
FARR_BADI_CONTRACT_COMBINATION, Contract categories, 121
295 Contract combination, 175
FARR_CHANGE_MODE_DETERMINATION, manual combination, 178
117 quick combine, 176
FARRIC_BADI_ORDER, 286, 295 Contract fulfillment, 178
gross posting, 185 event-based, 179
net posting, 185 manual spreading, 180
Black hole effect, 257 percentage of completion, 180
BRF+, 38, 41, 152 time-based, 179
account determination, 146 Contract management, 32
applications, 127 contract modification, 32
decision table, 104 Contract modification, 115, 231
decision tables, 146 Contracts, 20
integration, 142 completed, 268
transport applications, 148 open, 268
BRF+ applications Convergent accounting standard classes, 89
FARR_ACC_DETERMINE_TEMPLATE, 103 CO-PA integration, 198
FARR_AP_SD_PROCESS_TEMPLATE, 103 Cost object controlling, 113, 129
BRF+ Rules Engine, 144 integration, 107
371
Index Index
Cost of acquisition, 305 Extractor High-tech (Cont.) M

Cost recognition, 107 0FARR_RA_10, 91 implementation challenges, 328
Cost-based RA method, 111 0FARR_RA_20, 91 implementing SAP RAR, 328 Manual allocation, 173
Credit risk, 21 0FARR_RA_30, 92 overview, 325 Mass processing, 156
CRM-based item classes, 89 planning challenges, 327 Method, CLEAR_RELTYPE_FLAG, 286
Cumulative catch-up transition, 256 High-tech industry, 24 Migration, 215, 250
Cutover planning, 80 F Hybrid model-i, 346 challenges, 222
process, 227
Financial Accounting Standards Board (FASB), strategy, 216
D 15, 16, 22 I timelines, 223
First year invoicing and revenue postings, 331 Migration packages, 118, 229
Data archiving, 203 Five-step framework, 19, 20, 21 IFRS, 17, 227 Migration scenarios, 347
Data conversion, 216 Five-step model, 345 migration, 215 Modified retrospective approach, 271
Data source, 92 Fixed amounts, 21 IFRS 15, 15, 227 adoption date, 271
0FARR_CONTR_CAT_TEXT, 92 Foreign currency exchange processing, 205 adoption date, 22 application scope, 271
0FARR_CONTRACT_ATTR, 92 Fulfillment event type, 126 business challenges, 17 contract setup, 272
0FARR_DEF_S_IND_TEXT, 93 Full retrospective approach, 255 contracts, 20 GAAP results, 271
0FARR_DIST_TYP_TEXT, 93 completed contracts, 269 five-step framework, 19 open contracts, 271
0FARR_EVT_TYPE_TEXT, 92 disclosure of remaining POBs, 271 impact of new standards, 22 Modified retrospective transition approach,
0FARR_FULFILL_TYPE_TEXT, 92 hindsight, 270 Implementation date, 344 296
0FARR_OBJNR_ATTR, 92 modified contracts, 270 Inbound processing, 96, 152 Modified retrospective transition approach
0FARR_POB_ATTR, 92 Full retrospective transition approach, 266 Installation best practices, 87 with prospective pro forma, 274
0FARR_POB_ROLE_TEXT, 92 discounts, 267 International Accounting Standards Board adoption date, 275
0FARR_POB_STAT_TEXT, 92 foreign currency, 267 (IASB), 15, 22 cumulative effect calculation, 275
0FARR_POB_TYPE_TEXT, 92 go-live, 267 Invoice date-based calculation, 118 pro forma effect, 275
0FARR_POST_CAT_TEXT, 93 open contracts, 267 Invoice due date-based calculation, 117 Modified retrospective transition approach
0FARR_RECKEY_ATTR, 92 tracking, 267 Item classes, 89 with retrospective pro forma, 273
0FARR_RECKEY_STAT_TEXT, 92 Further data migration, 228 adoption date, 273
0FARR_REV_RSN_TEXT, 93 cumulative effect calculation, 273
0FARR_ST_DAT_TYP_TEXT, 93 J pro forma effect, 273
0FARR_VAL_RES_TEXT, 93 G Multiple-element arrangement, 31
Deferred costs, 36 Job monitor, 193
Deferred orders/contracts, 224 G/L accounts, 131
Dialog processing, 156, 157 G606, 227 O
Disaggregation of revenue, 199 Generally Accepted Accounting Principles K
Disclosures, 199 (GAAP), 15, 17, 22, 24, 233 Object
Dual reporting, 29, 282 Global accounting standards, 16 Key design decisions, 74 FARR_CONTR, 88
requirements, 282 Go-live, 75, 81, 219 Key performance indicators (KPIs), 15 FARR_RAI, 88
revenue, 282 On-premise contract, 331, 339
H L
E P
High volume invoice processing, 209 Ledger approach, 353
Enhancements, 133 High-tech, 299, 325 Licensing, 39 Package definition, 228
Error handling, 221 best practices, 341 Parallel accounting, 29, 278
impact of IFRS 15, 326 additional accounts approach, 29
parallel ledger approach, 29
372 373
Index Index
Parallel processing, 157 RAI class (Cont.) SAP RAR (Cont.) Telecom (Cont.)
configuration, 192 customer specific fields, 99 CO-PA integration, 106 historical data availability, 304
Parellel accounting modifiable fields, 100 five-step framework, 42 impact of IFRS 15/ASC 606, 300
account-based, 278 SD01, 97 installation, 86 Implementing SAP RAR, 306
ledger-based, 280 SD02, 97 integration, 45 prepaid services, 303
Performance obilgation, 20, 23, 36 SD03, 97 SAP BW integration, 90 second months invoice, 313
distinct and nondistinct, 20 sender component, 101 system requirements, 85 second month-end closing, 314
reference type, 102 upload rules, 100 UI configuration, 137 third month through sixteenth month invoic-
satisfaction, 21 RAI items, customizing, 159 Scenario modeling template, 69 ing, 315
transaction price allocation, 21 Reconciliation, 200, 221, 250, 354 SD-based revenue recognition process, 84 third through twentieth month-end closings,
types, 20 Recycling of revenues, 260 SD-based standard classes, 89 316
Performance obligation, 20, 152, 163 Reporting, 199 Securities and Exchange Commission (SEC), twenty-first month invoicing, 318
administration data, 169 Request for proposal (RFP), 27 15 twenty-first month-end closing, 319
allocation data, 165 Requirements, 344 Sell-in, 305 Test strategy, 75, 249
fulfillment data, 166 Residual approach, 173 Sell-through, 305 functional unit testing, 76
general data, 163 Results Analysis, 108 Standalone selling price, 21, 23, 102 technical unit testing, 75
number ranges, 120 Revenue accounting contract, 105, 151, 160 System development life cycle, 54 Testing, 219, 358
review reasons, 128 invoices, 182 Testing strategy
status data, 169 Revenue Accounting Engine, 37, 134 regression testing, 77
types, 122 Revenue accounting items, 151 T volume performance testing, 77
update mode, 129 Revenue accounting period, 120 Third-party systems, 348
Personal Object Work List, 137 Revenue accounting postings, 131 Table Time-based revenue, 188, 240
Posting, 184 Revenue automation tools, 25 DT_PROCESS_POB, 105 Transaction
Price allocation, 171 Revenue posting, 191 DT_PROCESS_POB_ADD, 105 CJ40, 111
Program FARR_REVERSE_LIAB_4_CHG_ Revenue recognition, 15 DT_PROCESS_POB, DT_PROCESS_POB_ CJ88, 113, 115
ACTPR, 238 five-step framework, 19 ADD, 104 FARR_CALC_TRANS_CATCHUP, 239
Project blueprinting, 64 process, 188 DT_PROCESS_SSP, 104 FARR_IL_CLEANUP, 226
business requirements document, 67 Revenue reversal, 195 FARR_BADI_COMP_TRAN_ADD_STRUC, FARR_LIABILITY_CALC, 295
business requirements workshops, 66 Revenue schedule, 163 296 FARR_NEWACP_CLEANUP, 287, 295
use case plan, 64 Revenue simulation, 189 FARR_D_COMP_TRAN, 293, 295 FARR_PREPARE_COMP, 293, 295
Project execution, 53 Revenue-based RA method, 111 FARR_D_Legacy, 286 FARR_RAI_MON, 235, 294
Project initiation document, 57 Right of return, 37, 72 FARR_D_LEGACYC, 286 FARR_RAI_PROC, 159, 295
Project management, 53 Run IDs, 121 FARR_D_MAPPING, 295 FARR_RAI_PROC_LOAD, 287, 294
Project roles, 350 FARR_D_MAPPING_M, 295 FARR_RAI_PROC_NEWACP, 294
Project testing, 75 FARR_D_POB, 296 FARR_RAI_TRANS, 156
Project timeline, 61 S FARR_D_POSTING, 287, 288, 295 FARR_REV_POST, 243, 295
Proration, 32 FARR_D_RECON_KEY, 295 FARR_TM_TRANSFER, 240
SAP Business Client Telecom, 22, 299 FARR_TRANS_CATCHUP, 295
roles, 89 activation fee, 303 FARR_TRANS_REV_URDR, 292
Q setup, 89 best practices, 324 FARR_TRANSREV_URDR, 295
SAP BusinessObjects BI, 38 billing systems, 304 FARRIC_OL, 226, 234, 294
Quantity-related invoice, 182 SAP ERP SD revenue recognition, 220 challenges, 302 KKA2, 113, 115
SAP RAR, 15, 16, 218 contract inception, 306 LPD_CUST, 140
components, 43 costs, 305 RSA5, 90
R configuration, 94 customer service promises, 303 RSA6, 90
configuration guide, 96 first month's invoice, 309 SARA, 88
RAI class, 97, 154 contract sync, 330 first months closing, 311 SE18, 135
BRF+ applications, 103 five-step model, 303
374 375
Index
Transaction (Cont.) V
SE38, 238
SE80, 137 Validation, 221
SICF, 88 Value-related invoice, 182
SLG1, 88 Variable amounts, 21
SLG2, 88 Vendor, 26
SM30, 108, 109 Vendor analysis, 26
VA03, 234 matrix, 25
VA43, 234 process, 26
WDY_APPLICATION, 160 Version 1.3, 204
Transaction price, 20
allocation, 21
Transition, 238, 255 W
cumulative effect, 268
example, 283 WBS hierarchy, 109
sttif, 284 Web Dynpro Floorplan Manager, 137, 159
Web Dynpro setup, 88
U
Unbilled orders/contracts, 224
Use case prototype, 69
376
First-hand knowledge.
Dayakar Domala is a senior manager for IT and enter-

prise applications at Service Now, where he has been
involved with ramp-up programs for implementing the
SAP RAR application with new technologies like SAP
S/4HANA. He presented on SAP RAR at the SAPPHIRE/
ASUG Annual Conference and the Finance Excellence
Forum in 2015.
Koti Tummuru is a platinum FICO consultant at SAP.

He has worked as a ramp-up coach for multiple clients
implementing SAP RAR to meet the new IFRS require-
ments, and was involved with the first SAP RAR go-live
for version 1.0.
Dayakar Domala, Koti Tummuru

SAP Revenue Accounting and Reporting and
IFRS 15
376 Pages, 2017, $99.95 We hope you have enjoyed this reading sample. You may recommend
ISBN 978-1-4932-1436-5 or pass it on to others, but only in its entirety, including all pages. This
reading sample and all its parts are protected by copyright law. All usage
www.sap-press.com/4206 and exploitation rights are reserved by the author and the publisher.

Reading Sample Sappress 1436 SAP Revenue Accounting and Reporting and IFRS 15 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Reading Sample Sappress 1436 SAP Revenue Accounting and Reporting and IFRS 15 PDF

Uploaded by

Copyright:

Available Formats

First-hand knowledge.

Introduction to IFRS 15 and SAP

Dayakar Domala, Koti Tummuru

and the software and hardware requirements needed to address it. We

1 Introduction to IFRS 15 and SAP Revenue

Automotive Example High-Tech Industry Example (On-premise Subscription)

Total recurring revenue: $15,090.00 Total SSP $18,834.00 Current GAAP:

Total recognized revenue $15,090.00 New GAAP:

New IFRS: Maintenance and upgraderevenue is separate POB

Maintenance revenue and warranty revenue are separate POBs

Figure 1.2 Impacted Industries: Automobile Example

1.2.4 How SAP Is Addressing the New Requirements

Account Dual Reporting Dual Reporting New Revenue

examples throughout the book.

Contract Asset/Contract Liability

presented as a contract liability.

Transaction Price Contract Asset Contract Liability

Rule: determine whether item is distinct

Rule: for combination of contracts

Rule: determine other clauses

Rule: derive additional POBs

(e.g., Right of Return)

Rule: derive POBs

Figure 1.6 Decoupled Architecture Business Rules Framework plus

into the BRF+ framework application.

POB Financial Accounting 1.2.8 Integration with Existing Revenue Applications

Integration with SAP Hybris Billing

Offer Order Pricing, Invoicing Credit Sales and Order

6.07 SP09 7.03 SP09 Hardware

Integration with Sales and Distribution-Based and Results Analysis-Based

Controlling Profitability Analysis

1 Introduction to IFRS 15 and SAP Revenue Accounting

1.1 Global Accounting Standards ........................................................ 16

2 Project Execution Approach ..................................................... 53

2.1 Project Management .................................................................... 53

2.4.2 Identify Solution Gaps .................................................... 71

A BRF+ Rules Repository, 144

Cost of acquisition, 305 Extractor High-tech (Cont.) M

Dayakar Domala is a senior manager for IT and enter-

Koti Tummuru is a platinum FICO consultant at SAP.

Dayakar Domala, Koti Tummuru

You might also like