With the introduction of a new accounting standard for revenue accounting (IFRS 15) issued by the International Accounting Standard Board (IASB) and Financial Accounting Standard Board (FASB), SAP assessed how best to design a new solution to cover the new requirements. The end result is an application that automates the revenue recognition and accounting process SAP Revenue Accounting and Reporting manages revenue recognition from a finance point of view. It decouples operational transactions from accounting so that various operational transactions can be accounted together no matter where the operational data is processed. Before the introduction of SAP Revenue Accounting and Reporting, SAP had a solution in sales and distribution (SD) called revenue recognition that organizations used to focus on time-based, event-based, or percentage-based revenue recognition. The new solution, SAP Revenue Accounting and Reporting, brings in a lot of flexibility that I describe in later sections. The necessary details for SD revenue recognition with time-based revenue recognition can be found in Ajay Pande’s article “Revenue Recognition Configuration in SD Is a Key to Compliance.”

A Bird’s Eye View of SAP Revenue Accounting and Reporting

Figure 1 shows how data flows in the SAP system with respect to revenue recognition. It shows that the source module sends data in the adapter reuse layer, which converts it into a revenue accounting item (RAI). The RAI contains all the data from an operational item that is required by the revenue accounting engine. RAI is later converted into revenue contracts that further contain performance obligations. To place things in perspective, if the source module is SD, it sends the sales order data in the adapter reuse layer. There the data is converted into a container called RAI with all the relevant data, such as material, dates, condition information, customer, or other monetary information. RAI is converted into a revenue contract, which typically represents the operational document (for example, a sales order). Just as a sales order contains sales line items, a sales contract in revenue accounting contains performance obligations (POBs). So in the simplest form, one sales order with two line items has one sales contract with two POBs (there can be exceptions to this rule). At all necessary events or time schedules, the revenue accounting engine reads data from contracts and POBs to pass necessary entries in FI and Profitability Analysis (CO-PA) with respect to revenue recognition.

Key Definitions in IFRS and How They Are Represented in SAP Revenue Accounting and Reporting

To know how to maintain compliance with IFRS 15 using SAP Revenue Accounting and Reporting, you need to know the definitions of several key terms. I define these terms in this section.

Contracts

The International Financial Accounting Standards (IFRS) definition of a contract is an agreement between two or more parties that creates enforceable rights and obligations. It consists of one or many POBs. A POB is a promise in a contract with a customer to transfer the following:

• Goods and services that are distinct.
• A series of goods and services that are substantially the same and that have the same pattern of transfer to the customer.

SAP introduces both revenue contracts and POBs in SAP Revenue Accounting and Reporting (Figure 2).

Distinct Goods and Services

According to the IFRS, a material is considered distinct when:

1. The customer can benefit from the good or service on its own or in conjunction with other readily available resources.
2. The entity’s promise to transfer the good or service to the customer is separately identifiable from other promises in the contract.

Any material that does not suffice for the above requirements is considered a non-distinct material. In the SAP system you can define operational document line items as distinct or non-distinct via Business Rule Framework plus (BRFplus) rules.

Transaction Price (Contractual Price)

The IFRS definition of a transaction price is the amount of consideration decided on a contract in lieu of the goods or services. In the SAP system, a transaction price is usually the sales order value determined through condition types. This value appears as a contractual price in each POB as can be seen in Figure 3. These details can be accessed in contract details (BRFplus).

Standalone Selling Price (SSP)

The IFRS Foundation’s definition of an SSP is the price that the customer would have been charged had the good or service been sold individually at arm’s length. Sometimes the transaction price may include a discount. Any overall discount is allocated between the performance obligations on a relative standalone selling price basis. In some circumstances it may be appropriate to allocate the discount to some, but not all, the POBs. SAP uses the name SSP, which is the same name as used by the IFRS Foundation and the IASB. It can be delivered from a special condition from the operational document (sales order line item) or it can be maintained or uploaded in BRFplus in revenue accounting. SSP is maintained at the POB level (Figure 3).

The Step Model of Revenue Recognition in IFRS 15

The core principle of IFRS 15 is that an entity recognizes revenue to depict the transfer of promised goods or services to customers in an amount that reflects the consideration to which the entity expects to be entitled in exchange for those goods or services. This core principle is delivered in a five-step model framework: Step 1. Identify the contracts with a customer. Step 2. Identify the performance obligations in the contract. Step 3. Determine the transaction price. Step 4. Allocate the transaction price to the performance obligations in the contract (on the basis         of SSP). Step 5. Recognize revenue when (or as) the entity satisfies a performance obligation. These five steps can be better explained by considering the following scenario: A company (company code 1000) enters into a contract with a customer for sales of two materials (material 1 and 2). As per IFRS, material 1’s revenue can be recognized as soon as it is invoiced, whereas the material 2’s revenue can only be recognized by an event that cannot be recorded in the SAP system. In such a case you have two separate fulfilments for these materials. The fulfilment of material 1 is at the time of invoice and the fulfilment of material 2 is manual. A combined sales price of the package is 7,500 euros. However, if sold individually, materials 1 and 2 would have sales prices of 4,000 euros and 4,000 euros, respectively. You would be performing the goods issue and also the billing for both the materials immediately, even if material 2’s revenue should not be recognized yet as it would depend on an external event. The company code has two ledgers (two accounting principles), and IFRS 15 is applicable only on accounting principle 01 (IFRS). Table 1 lists examples of contract and SSP prices for two material types.

Material	Contractual price (transaction price)	Standalone selling price (SSP)
1	5000	4000
2	2500	4000

To help you understand this process better, I break up the process into a five-step model framework. This is the same framework the IFRS Foundation uses to recognize revenue.

Step 1. Identify the Contracts with a Customer

As soon as the sales order requires revenue recognition, a relevant order type or item category that has been marked as relevant for SAP Revenue Accounting and Reporting should be used. The configuration needs to be set up after executing transaction code SPRO under SD (Figure 4). The sales order shown in Figure 5 shows the details of line items and total value. This is an extract of sales order (transaction code VA03). Double-click individual line items and go to the billing tab to verify if the line item is relevant to revenue accounting. Refer to the Type field shown in Figure 6. After the sales order is created, it flows to the SAP Revenue Accounting and Reporting engine. This can be verified in SAP NetWeaver Business Client (NWBC) with the necessary authorizations in place. Figure 7 shows the search process. The revenue contract number is under the Re… (revenue accounting contract) column. The Com… column contains the company code. The number of POBs in the contract is under the No. of Perf. … (performance obligations) column. The transactional value of the contract is under the Transaction … column.

Step 2. Identify the Performance Obligations in the Contract

The revenue contract in my example has two POBs, as the sales order has two distinct units (materials 1 and 2). The POBs are determined based on rules set up in BRFplus. The determination of the POB is important as it determines the fulfilment type of distinct or non-distinct, the SSP, and the necessary dates. I have configured the POB as material 1 and 2 for simplicity and better understanding. Table 2 shows how one sales order with two materials makes one contract (per accounting principle) and two POBs.

Sales order	Material	Contract	Accounting principle	POB	Composition	Contractual price	Standalone selling price (SSP)
36622	1	20331	01	3079	Distinct	5000	4000
36622	2	20331	01	3080	Distinct	2500	4000

Note in Table 2 that the operational document is the sales order. The contract is the revenue accounting contract. The accounting principal helps in identifying which ledger it would influence. The contractual price is the price as per the sales order. The SSP is the price had the material been sold alone.

Step 3. Determine the Transaction Price

The IFRS Foundation uses the terminology transaction price, and SAP RAR 1.1 uses the name contractual price. Figure 8 shows the contractual price (transaction price). This price comes from the sales order line items.

Step 4. Allocate the Transaction Price to the Performance Obligations in the Contract (Based on SSP)

SSPs can be delivered by via BRFplus or by maintaining a special condition in the operational document. This delivered value can be changed with proper authorization in the NWBC screen. Figure 8 illustrates the allocated price.

Step 5. Recognize Revenue When (or as) the Entity Satisfies a Performance Obligation

The POB has the fulfilment type information as shown in Table 3. Taking the example forward I make the delivery, goods issue, and billing for both the materials. Thereafter, the financial impact is as shown in Figure 9. Ideally, only revenue relevant to material 1 (4,000 euros) should be recognized, but as per Figure 10, the revenue of both materials (7,500 euros) has been recognized. Let’s take a look at SAP Revenue Accounting and Reporting reports after the billing. The invoiced amount as highlighted in blue in Figure 10 is updated after the billing. Furthermore, as material 1 had its fulfilment as a customer invoice, the fulfilled progress (progress of fulfilment) and recognized amount (highlighted in red) have been updated. As a part of month-end step, you need to calculate the contract liabilities and assets. As the revenue recognition is only applicable for accounting principle 01, the screen parameters need to be selected for accounting Principle 01 (Figure 11). The results can be seen by clicking the Job Monitor button highlighted in Figure 11. The Calculate Contract Liabilities and Assets transaction in Figure 11 is available in NWBC and needs proper authorization to run. It just calculates the amount and does not post any financial entry.

Perform a Revenue Posting Run

The next step is to perform a revenue posting via BRFplus, as shown in Figure 12. This transaction (Revenue Posting Run) brings in the financial impact. Let’s discuss the financial entries (Figure 13) with the revenue posting from SAP Revenue Accounting and Reporting. The operation postings (in yellow and gray) are self-explanatory and are a result of the goods issue and billing as part of the usual SD process. The amounts highlighted in green are a result of revenue posting in SAP Revenue Accounting and Reporting, and the ultimate impact of the same is 4,000 euros on the P&L. A contract liability of 3,500 euros is created in the balance sheet for accounts receivable adjustment (Accts Recv Adj.). If CO-PA is active, a profitability document is also generated with the SAP Revenue Accounting and Reporting revenue posting entry. If there is a manual fulfilment during the next month, then during the revenue posting in SAP Revenue Accounting and Reporting the system calculates the necessary revenue and posts the same, reducing the A/R Adj.

Reporting

SAP Revenue Accounting and Reporting has extensive reporting capabilities, and it is also well integrated with Excel so that you can pull out reports in an Excel spreadsheet. Following is a list of some of the available reports in line with the IFRS requirements: •           Posted Amount: By Contract •           Posted Amount: By Performance Obligation Type •           Disaggregation of Revenue: By Customer •           Disaggregation of Revenue: By Customer Group •           Disaggregation of Revenue: By Performance Obligation Type •           FI Documents: By Contract •           Reconciliation Between Revenue Accounting and General Ledger