收入确认 SAP - RAR

最近和同事们在支持一个全球行业龙头客户的数字化转型项目，过程中涉及到了新收入准则下收入确认的一些话题，以及SAP针对这块需求推出的收入确认工具RAR。在和同事日常交流中顺便学习了下RAR（Revenue Recognition&Reporting)相关的一些知识，今天结合新收入准则下的五步法跟大家做一个分享。

背景：

国际会计准则理事会(IASB)于2014年5月28日发布了一项针对收入确认核算的新准则：《国际财务报告准则第15号——与客户之间的合同产生的收入》（IFRS15)。

IFRS15对自2018年1月1日或以后日期开始的期间生效，允许提前采用。这一新准则对与客户之间因合同产生的收入提出了一个全面的单一的模型进行会计处理，取代现有IFRS准则及解释对收入确认原则的交叉阐述。其核心原则是，企业在确认收入时，应当反映向客户交付所承诺的商品或服务，其金额应当反映企业预期在交换商品或服务中有权收回的对价。

这里提到的模型就是广为人知的收入确认五步法，下面结合一个业务场景以及新收入准则下收入确认的五步法展示下RAR所能实现的系统功能。

假设XX公司与客户签订了一个合同售卖一台设备A001，并购买了3年质保服务，售价一共10000元。（客户如果只买设备价格为8000，单独购买3年质保服务价格为4000。）

第一步：识别合同（Identify the contract with a customer）

在识别合同这步，可按照SO的标准流程执行，创建完SO后如果需要走RAR流程，会传至在RAR中生成合同数据。

第二步：区分履约义务（Identify all the individual performance obligations within the contract）

从合同上来看，涉及到的履约义务（POB）主要分为两块，第一个是设备交付，第二个是提供对应的安装调试服务。在RAR中可通过BRF+实现配置，假设销售订单传来的是物料A，则POB可以自动拆分出物料B，最终变成POB1为leading POB，POB2为关联的POB（Linked POB）。关联的POB是服务类别的物料。同样在RAR中通过BRF+可以维护每一项POB的单独售价（Standalone Selling Price，简称SSP）。在本文案例中POB1，设备的单独售价为8000，POB2：3年质保服务单独售价为4000。

第三步：确定交易价格（Determine the transaction price）

交易价格主要是读取销售订单中的条件类型作为交易价格，在本文的案例中交易价格就为10000.

第四步：分配交易价格（Allocate the price to the performance obligations）

获取到合同交易价格后，可根据不同POB的单独售价（SSP）占比实现收入的分摊，以便后续每一个POB得到满足时，只确认对应POB的收入。在本文的案例中设备POB1真的分配后的价格为8000/(8000+4000)*10000=6666.67。

第五步：确认收入（Recognize revenue as the performance obligations are fulfilled）

在RAR中最终收入的确认是根据合同中单项履约义务是否完成来执行的，如果履约义务有实现，则去确认对应的收入，生成相关收入凭证。这里提到的履约义务满足在RAR系统层面分为3类：（1）事件相关（Event-based），比如交货、POD等）

（2）时间相关（Time-based）（3）完工百分比（可与CO模块中的结果分析实现集成）。

在本文的场景中设备发货给客户后可以代表POB1的履约义务已完成，所以POB1的履约类型可以设置成Event-Based中的交货，一旦交货完成后RAR就可以确认POB1对应的收入6666.67.

*需要注意RAR不会去干预前段SD模块在SO开票后生成的相关凭证，而是单独在RAR端进行处理，确认的收入与SO中开票金额的差异会在RAR生成的凭证中中自动通过合同资产、合同负债在总账中进行调整。
 

https://blogs.sap.com/wp-content/uploads/2016/09/sd_revenue_recognition_1034511.jpghttps://blogs.sap.com/wp-content/uploads/2016/09/sd_revenue_recognition_1034511.jpg

SAP SD offers an integrated Revenue recognition based on SD Documents. With SD Revenue Recognition, invoices are posted to Deferred Revenue (depending on Previous Recognized Revenue Items) with recognized revenue also posting to COPA.

1. Introduction

This blog starts by providing a brief understanding of IFRS (International Financial Reporting Standard) 15 – Revenue from Contracts with Customers and then lays down how SAPs RAR (Revenue Accounting and Reporting) solution helps in complying with the same. Towards the end, lists down some important configurations in SAP RAR (Revenue Accounting and Reporting).

RAR is also used to comply with ASC 606 – Revenue from Contracts with Customers.

2. Audience

Consultants/Business Users.

3. Purpose

• Understand the concept of IFRS 15 – Revenue from Contracts with Customers
• Understand SAP’s Revenue Accounting and Reporting (RAR)
• Configuration in Revenue Accounting and Reporting (RAR)

4. IFRS – 15: Revenue from Contracts with Customers

Introduction to the Concept
Let’s start with an investment decision scenario. Here we decide which is the best company to invest in purely based on financial data provided by them.

Below is an excerpt of financial data of two companies in the same line of business;

By analyzing the above data, it is obvious that company B has a good ROI (Return on Investment) in fact 4.5 times that of company A and is the best place to invest in.

Now we will check some other facts and see if our decision to go with company B will change?

Other Facts;
• Both Companies had only one contract during the year.
• Company A’s contract is of 10,00,000 and to be delivered in 5 years. Fully invoiced and amount received upfront. The revenue is recognized only to the extent obligations are delivered, making it only 2,00,000 for the year.
• Company B’s contract is of 5,00,000 and to be delivered in 5 years. Fully invoiced and amount received upfront. Revenue is recognized based on the invoicing though the contract is not fully delivered.

With this new information, it reveals that company A is performing better than the company B, though the financial figures were misleading. The reason for getting mislead; company B did not follow the standard accounting principles while recognizing the revenue.

The main purpose why Accounting Standards got framed is to avoid such wrong decision making based on misleading data.

With Accounting Standards, comparison between two entities is possible when both maintain the same principle, otherwise proper comparison is not possible. As in our case both companies observed different accounting principles and the results were extremely misleading.

IFRS (International Financial Reporting Standard) 15 is one such standard which lays down the rule to recognize and report Revenue from Contracts with Customers. It specifies how and when to recognize revenue as well as requiring entities to provide users of financial statements with more informative, relevant disclosures.

Principles of IFRS 15
Though we will not get into the very details of IFRS 15 – Revenue from Contracts with Customers, we will understand the crux as SAP’s Revenue Accounting and Reporting (RAR) is a solution for IFRS 15 requirements.

The main objective of the new standard IFRS 15 is to provide a single, comprehensive revenue recognition model for all customer contracts, improving comparability within and across industries and across capital markets.

The principles in the standard will be applied using a five-step model:

• Identify the contract with a customer.
• Identify all the individual performance obligations within the contract.
• Determine the transaction price.
• Allocate the price to the performance obligations.
• Recognize revenue as the performance obligations are fulfilled.

Terminologies
It is also good to know some of the IFRS 15 specific words.

Performance Obligation; A promise to delivery good or service under a contract with a customer qualifies as a performance obligation if the good or service is ‘distinct’.

Standalone Selling Price; The price at which an entity would sell a good or service separately to a customer.

Contract Asset; Recognized Revenue is more than the Invoiced Amount.

Contract Liability; Invoiced Amount is more than Recognized Revenue.

Illustrations
Let’s try to understand this 5-step model with an illustration. We will take an example of a contract from a telecommunication industry, an industry heavily impacted by IFRS 15.

Step 1: Identify the Contract with a Customer
A contract is entered with a customer and following are the terms of the same;
• Device sold under contract at 13,000 INR, with 3 months free data subscription.
• Full amount settled at initiation of the contract.
• Device delivered immediately.
• Data service provided over the contracted period of 3 months.

Step 2: Identify all the individual performance obligations within the contract
This contract has two POBs (Performance Obligations) one delivery of device and the second one providing of data service over the period of 3 months.

Step 3: Determine the Transaction Price
In this the contract TP (Transaction Price) is 13,000 INR.

Step 4: Allocate the price to Performance Obligations
We have identified 2 POBs in this contract. The transaction price should be allocated between these 2 POBs in the ratio of their standalone selling price (SSP). As defined in IFRS 15, the SSP is the price at which an entity would sell a good or service separately to a customer. The SSP for device is 10,000 INR and for the 3 months subscription is 6,000 INR. Hence, the allocation amount for the Device will be 8,125 INR and for 3 months subscription will be 4,875 INR.

Step 5: Recognize revenue as the performance obligations are fulfilled
The revenue for the Device POB will be recognized as and when the device is delivered, which in our case is in the 1st month. Revenue relating to Subscription POB will be recognized over the period of 3 months equally as and when it gets fulfilled.
At the end of 1st month there will be a Contract Liability of 3,250 INR, as the contract amount is fully invoiced, and subscription for 2 months is yet to be provided.

Following is the pictorial representation of the illustration narrated above;

We also consider an illustration where in contact asset is ascertained.

5. Revenue Accounting and Reporting (RAR)

Overview
SAP Revenue Accounting and Reporting Component is based on the 5-step model of IFRS 15. In RAR system, data obtained from different source applications are processed to identify the POB and their recognizable revenue. During the period end, revenue as per IFRS 15 is recognized along with contract liability / contract asset if any and posted to accounting.

Architecture
Data flow to RAR system from different applications to calculate revenue, contract asset and contract liability as per IFRS 15. Data can flow to RAR with native integration from SD and Hybris, and from third party applications using BAdIs.

Following diagram depicts data flow architecture to and within RAR system.

Source Applications
SAP RAR is a standalone application and multiple applications (managing contracts) can be integrated directly into RAR through the ARL (Adapter Reuse Layer). RAR is compatible with SAP and Non-SAP applications.

Standard Integration Applications
1. SAP Hybris
2. Sales and Distribution

Third Party Applications
1. Data Hub Approach

In this approach data is gathered from various source systems, staged and processed in a SAP RAR compatible language before sending it to RAR.

The information flow from source applications to RAR provides details of Order, Fulfillment and Invoice of a contract. An order creates a contract in RAR, whereas fulfillment and invoice update an existing contract.

Adapter Reuse Layer
Data received from source applications generate RAIs (Revenue Accounting Items) to pass the contract information to RAR. SAP applications like SD can be configured to generate RAIs in ARL (Adapter Reuse Layer) automatically.

RAIs (Revenue Accounting Items) in simple terms can be referred to as common language understandable by RAR system. Data received from all the source applications generate RAIs (Revenue Accounting Items).

Once Revenue Accounting Items are created, they need to be processed to create/update RA Contract and POBs (Performance Obligations).

RAIs (Revenue Accounting Items) can be viewed and processed using RAI Monitor (Transaction FARR_RAI_MON).

There are typically 3 stages/status in RAI processing; Raw, Processable and Processed. However, few stages can be skipped with integrated approach.

Each stages/status mean;

Raw: No validation done
Processable: Validation like master data, company code and so on done
Processed: RAI is processed, and corresponding Revenue Accounting Contract is created or updated successfully.

A RAI is created for each line item (Main Item) and corresponding conditions (Condition Item) for order, fulfillment and invoice.

Successfully processed RAIs will create/update RA Contracts and POBs based on rules set in BRF+ (Business Rules Framework).

Once Order RAIs (Revenue Accounting Items) are processed, Contract No. and POB No. gets updated against each of the RAIs.

Business Rules Framework+
BRF+ is a standalone application and a prominent component in ARL (Adapter Reuse Layer). BRF+ is used to derive attributes of Revenue Accounting Contract and Account Determination with predefined business rules. BRF+ acts as an API as well as a User Interface to define and process business rules.

BRF+ as a standalone application, is not only integrated with RAR but can be integrated with other SAP applications like CRM, SRM and other custom applications also.

Following BRF+ application templates are delivered by SAP by default;
FARR_AP_SD_PROCESS_TEMPLATE
Template for revenue accounting item classes used for the integration with Sales and Distribution (SD).

FARR_AP_CA_PROCESS_TEMPLATE
Template for revenue accounting item classes used for the integration of SAP Hybris Billing (sender component CA).

FARR_AP_CRM_PROCESS_TEMPLATE
Template for revenue accounting item classes used for the integration of SAP Customer Relationship Management (CRM).

FARR_AP_PROCESS_TEMPLATE
Template for revenue accounting item classes used for the integration of any other sender component.

FARR_ACC_DETERMINE_TEMPLATE
Template for Account Determination.

Own BRFplus application can be created by copying the appropriate template application delivered by SAP and maintain installation-specific logic by maintaining the appropriate decision table entries.

BRF+ applications are assigned in the configuration for POB processing and Account Determination.

There are Decision Tables in each of these applications for specific purposes which contains condition columns and result columns. The result column data is identified and sent back to RAR based on condition columns data received from RAR system.

Following picture depicts input column (in blue) and output columns (in green);

Following are some of the decision tables provided in a BRFplus applications;
1. Updating POB Attributes
2. Getting SSP (Standalone Selling Price) for each POBs
3. Right of Return
4. Account determination for Contract Asset
5. Account determination for Contract Liability
6. Account determination for Recognized Revenue
7. Account determination for Rev. Adj. Allocation
8. Account determination for Deferred Cost

Revenue Accounting Contract and POBs
Revenue Accounting Contracts can be accessed by clicking contract number in RAI Monitor. Revenue Accounting Contract contains list of Performance Obligations under it along with detail status of each of the POBs.

Once Fulfillment or Invoicing is done, respective POBs gets updated.

Column ‘Invoiced Amount’ shows POB invoiced till date and column ‘Fulfilled Progress’ shows the status of fulfillment of the POB.

Column ‘Performance Obligation Status’, shows as ‘Completed’ once fully fulfilled and invoiced, otherwise ‘In Process’.

Calculation of revenue is based on multiple attributes of a POB, which gets partially filled up by BRF+. Following picture depicts attributes of a POB;Revenue Accounting Contracts also show Revenue Schedule for each POBs, especially for Time Based.Revenue Schedule provides the projection of revenue to be recognized over the period of contact. It also shows the status of revenue recognized in each period.

Period End Processing
In Revenue Accounting and Reporting (RAR), 3 step period end closing happens.

Step 1 – Transfer Revenue
Purpose: Identifies the revenue to be recognized at the end of the specified period. However, doesn’t post any accounting entries.

SAP Path: Revenue Accountant > Revenue Posting > Transfer Revenue

By clicking on Transfer, a background job gets created.
The status of the job can be checked using Revenue Posting Jobs Monitor.

SAP Path: Revenue Accountant > Revenue Posting > Revenue Posting Jobs Monitor

Step 2 – Calculate Contract Liabilities and Assets
Purpose: Calculates Contract Asset or Liability at the end of the specified period. However, doesn’t post any accounting entries.

SAP Path: Revenue Accountant > Revenue Posting > Calculate Contract Liabilities and Assets

By clicking on Transfer, a background job gets created.
The status of the job can be checked using Revenue Posting Jobs Monitor.

SAP Path: Revenue Accountant > Revenue Posting > Revenue Posting Jobs Monitor

Step 3 – Revenue Posting Run
Purpose: Posts accounting documents based on the calculation done in earlier steps.

SAP Path: Revenue Accountant > Revenue Posting > Revenue Posting Run

By clicking on Post, a background job gets created which will post accounting documents. Before posting, simulation can be done to verify the entries.

The status of the job can be checked using Revenue Posting Jobs Monitor.

SAP Path: Revenue Accountant > Revenue Posting > Revenue Posting Jobs Monitor

Accounting Entries
Accounting entries gets posted from RAR during the period end processing in step 3. We shall consider the following scenario as the basis to understand the accounting entries;

Step 1: Invoice Posting
Following will be the accounting entry posted during billing/invoicing. There is no role of RAR in this entry;

Step 2: Invoice Correction (RAR) (Reversal of Invoice)
This is an entry from RAR which reverses the revenue recognized in Step 1. By this it nullifies the revenue posted earlier and with subsequent entries RAR will post actual revenue as per IFRS 15;

Step 3: Recognize Revenue (RAR) (Upon Fulfillment)
With this set of entries, RAR recognizes revenue as per IFRS 15. However, it first posts the Transaction Price and then adjusts it with the allocation effect. The result is nothing but the allocation of the POB for the period;

Step 4: Contract Assets and Liabilities (RAR) (Balance in Receivable Adjustment)
With this entry Contract Asset/Liability is posted;

6. Configuration

IMG path for RAR configuration can be accessed by Transaction FARR_IMG.

In this section some of the important configurations are highlighted. Please note the configurations here mentioned are not exactly the way it is arranged in FARR_IMG but have been put in line with the concept/flow discussed in the earlier section.

Source Applications
Step 1: Sender Component
As discussed earlier, RAR can support multiple source applications. The source applications are defined as sender component.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Define Sender Components

Sender Component is assigned to logical system and source document item types.

Step 2: Logical System
Define logical systems from which revenue accounting retrieves source items.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Define Logical Systems

Step 3: Source Document Item Types
The information flow from source applications is in the form of Order, Fulfillment and Invoice of a contract. These are defined as Source Item Types.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Source Document Item Types

Adapter Reuse Layer
Step 1: Interface Components
This configuration activity provides access to the interface components that can be used when defining revenue accounting item classes.

SAP provides preconfigured interface components that can be used immediately. These include basic components, which are mandatory for each record type, as well as other optional components which can be added to a Revenue Accounting Item Class.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Items – Define Interface Components

Assign Structures, Prerequisite Components and Program Enhancements. Also define Key Fields and assign Components to Class Type and Record Type.

Step 2: Maintain Revenue Accounting Item Classes
Define revenue accounting item classes and their technical attributes. For each Revenue Accounting Item Class, it is required to define:
• The interface that you use to transfer revenue accounting item information to the system.
• The data store to be used for the revenue accounting items
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Items – Maintain Revenue Accounting Item Classes

Customer fields can be added to the RAI structures / Revenue Accounting Item Classes

Step 3: Generate Interfaces for Revenue Accounting Item Classes
Generate the runtime objects resulting from the Revenue Accounting Item configuration.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Items – Generate Interfaces for Revenue Accounting Item Classes

Step 4: Assign Upload Rules to Revenue Accounting Item Classes
Define behavior of revenue accounting item class during upload. It can be;
1. Create RAI as Processable Item. Consistent items are created as processable items and Erroneous items are created as raw revenue accounting items.
2. Create RAI as Raw Item. Consistent items and erroneous items are created as raw revenue accounting items.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Items – Assign Upload Rules to Revenue Accounting Item Classes

Step 5: Define Exemption Reasons for Revenue Accounting Items
We can exempt revenue accounting items from processing. In this configuration define the reasons for so and can specify whether the item can be restored or not.

This comes handy if there are issues with the Customizing or the item may be corrupt. The system then moves these items to a separate table which excludes them from ordinary processing.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Define Exemption Reasons for Revenue Accounting Items

Step 6: Define Restoration Reasons for Revenue Accounting Items
Define restoration reasons to restore Revenue Accounting Items that are exempted with an exemption reason. Once restored, they can be further processed in RAI monitor.
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Define Restoration Reasons for Revenue Accounting Items

The option to Exempt or Restore RAI is available in Revenue Accounting Items monitor.

Business Rules Framework+
Step 1: Revenue Accounting Item Classes
BRF+ applications assigned to RAI classes to add business rules while creating/updating RA Contract and POBs (Performance Obligations).
SPRO Path : Revenue Accounting – Inbound Processing – Revenue Accounting Item Management – Assign BRFplus Applications to Revenue Accounting Item Classes

Step 2: Account Determination
Assign BRF+ application for account determination and FI postings.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Assign BRF+ Applications to Revenue Accounting Processes

Revenue Accounting Contract and POBs
Step 1: Accounting Principle-Specific Settings
Maintain different accounting treatment and presentation specific to Accounting Principle.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Configure Accounting Principle-specific Settings

Assign Company Codes to Accounting Principles.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Assign Company Codes to Accounting Principles

Step 2: Open and Close Revenue Accounting Periods
Configure whether an accounting period is open for revenue accounting related transactions. The settings in this activity provide a revenue accounting perspective of period closing. This is more of a periodic activity.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Open and Close Revenue Accounting Periods

Step 3: Number Ranges
Number Ranges – Contracts
Maintain number ranges for Revenue Accounting Contracts.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Number Ranges – Define Number Ranges for Contracts

Number Ranges – Performance Obligations
Maintain number ranges for Performance Obligations (POBs).
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Number Ranges – Define Number Ranges for Performance Obligations

Number Ranges – Run IDs
Maintain number ranges for Performance Obligations (POBs). Run IDs are reference numbers that the system uses to track background jobs created for revenue postings.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Number Ranges – Define Number Ranges for Run IDs

Step 4: Define Contract Categories
Define contract categories and assign number ranges to them.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Define Contract Categories

Step 5: Define Performance Obligation Types
Define performance obligation types and their associated attributes. POBs can also derive their attributes using BRF+ application.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Define Performance Obligation Types

Step 6: Condition Types
Maintain settings relating to condition types.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Condition Types

Define Reserved Condition Types

Define Condition Types Not Requiring Allocation

Define Roles for Condition Types

Step 7: Define Fulfillment Event Types
Different event types can be defined to recognize fulfillment. As per IFRS 15, revenue is recognized upon fulfillment.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Define Fulfillment Event Types

Step 8: Change Message Control
Configure how the system handles certain messages for Revenue Accounting.
SPRO Path : Revenue Accounting – Revenue Accounting Contracts – Change Message Control

Period End Processing
Step 1: Define Posting Specifications for General Ledger Transfer
Maintain RAR posting related configuration like Posting Key, Document Type, Transfer Account for Document Splitting, Profit Center and so on. FI documents posted during period end processing will be based on this configuration.
SPRO Path : Revenue Accounting – Revenue Accounting Postings – Define Posting Specifications for General Ledger Transfer

Step 2: Configure Account Determination for Specific Transactions
This configuration allows to define rules that system uses to determine the accounts to make certain revenue-related postings. It can also be maintained in BRF+ application directly.
SPRO Path : Revenue Accounting – Revenue Accounting Postings – Configure Account Determination for Specific Transactions

Hope you find this blog helpful.

This blog does not cover full functionality of SAP RAR. Please refer SAP Help for more insights.

FollowLikeRSS Feed