How Does SAP Handle Revenue Recognition?

Revenue recognition tools have been available in SAP for a while.

Prior to IFRS 15, the tool for performing revenue recognition processes was also called revenue recognition in SAP ERP, but it was placed directly under SD as part of the SD-BIL-RR component. This solution was aimed at solving the main issues of timing of billing and revenue recognition before the introduction of IFRS 15. For that purpose, in SD-RR (i.e., revenue recognition), we had the following main methods for how revenue should be recognized:

• Revenue recognition at the same as billing
• Time-related revenue recognition (revenue recognition between a set of dates)
• Service-related revenue recognition (revenue is recognized based on some specific event)
• Credit/debit memo with reference to a preceding document
• SAP for Media–specific method related to service revenue recognition, but with more of a focus on royalties, for example

The setup of SD-RR was straightforward and because all data would be taken from SD; it was embedded in the standard SD setup, especially when considering the accounting impact.

However, with the introduction of IFRS 15, the concept of SD-RR was abandoned, and a new tool was introduced to meet the requirements from the new standard—SAP Revenue Accounting and Reporting. This new tool was designed to not only solve challenges that came with the new standard but also make significant improvements to the old solution:

• The order/invoice processing and revenue recognition processes were decoupled. This approach alone brought significant flexibility in environments where order management and billing processes are natively in non-SAP environments
• The second improvement came directly from the first one: SAP Revenue Accounting and Reporting is much easier to integrate with external systems.
• Native support for multiple reporting standards (IFRS/ASC 606/GAAP) was included.
• It was built around the five-step model of IFRS 15. This means that allocation was introduced as a concept because it didn’t exist in the old revenue recognition solution.

The functionality of the standalone SAP Revenue Accounting and Reporting solution has been included in SAP’s latest ERP suite, SAP S/4HANA. We’ll refer to it as RAR throughout this post.

However, SAP now positions two solutions in the market:

• RAR with classic and optimized contract management (CCM and OCM)
• Event-based revenue recognition (EBRR)

Let’s discuss both of the solutions at a high level to shed light on which solution is most appropriate for certain business cases.

Revenue Accounting and Reporting

RAR is the main tool for revenue recognition in both SAP S/4HANA and SAP ERP to satisfy IFRS 15/ASC 606 requirements. There was no single product available that would comprehensively deal with revenue reporting prior to RAR. When integrated with sales and distribution, SD-RR was the go-to solution, but mainly when companies needed to differentiate the timing of revenue recognition. Results analysis was a solution for calculating revenue recognition in complex project environments. As a solution, results analysis has been available on the market since mid-2014; it went through several iterations of changes to become ready to support customers moving to IFRS 15:

• SAP Revenue Accounting and Reporting 1.1 came with solutions that had full integration with sales and distribution. The Adapter Reuse Layer (ARL) concept was introduced together with the split between time-based revenue recognition and EBRR.
• SAP Revenue Accounting and Reporting 1.2 was briefly on the market and was quickly upgraded with the next versions. This version brought improvements in terms of account assignment options and integration with cost object controlling.
• SAP Revenue Accounting and Reporting 1.3 is the latest solution available for implementation. Further development is being done through support packs (SPs); at the moment, SP 15 is available. With different SPs, many additional features were introduced, such as new fulfillment types (proof of delivery, drop shipments, call-off orders), but the main advance was in terms of stability and an error correction capability.

As of SAP S/4HANA version 1809, RAR became an integral part of the SAP HANA foundation, which also includes software component version REVREC. Changes between the 1.3 version and the one on the SAP HANA foundation were significant in terms of additional features and improvements to the code, but the functionality itself remained mainly the same. The exception was the introduction of OCM and optimized inbound processing (OIP; with version 1909). Although some people are calling SAP HANA version 1.4 or even RAR 2.0, this naming convention is colloquial, not official from SAP.

NUMC to CHAR: One very important change that came with versions available for SAP S/4HANA is the change of data type for POB ID. Basically, until SAP HANA, the data type for POBs (FARR_D_POB-POB) was numerical. Due to performance improvements, this was changed to characters. No additional migration considerations are needed except to revise any custom code that might relate to the old data type. Details are given in SAP Note 2672794.

The figure below shows the high-level architecture of RAR.

As already mentioned, RAR is a flexible tool that can easily be integrated with different systems used as data sources. Native integration for RAR is available with some SAP products such as sales and distribution, SAP Billing and Revenue Innovation Management, and SAP Customer Relationship Management (SAP CRM). All these systems are used as a source for getting data which is later grouped into three categories: order items, fulfillment items, and invoices.

Order items will have all the information needed for contract creation:

• Basic data such as customer, start/end date of contract, and so on
• Conditions used to determine both the transactional price and the SSP, which will be used to allocate the transactional price 

RFC Integration: To integrate with sales and distribution and other components, RAR uses the remote function call (RFC) functionality as part of the inbound processing configuration. For proper integration, there are two options: either defining and using proper logical systems, or using logical destination NONE only after implementing SAP Note 2957643.

In addition to SAP tools, there is an option to integrate with third-party solutions. The requirements are the same as with SAP solutions, but special attention needs to be paid regarding data quality. The data coming to RAR must be in the same format and quality as if it was coming from an SAP solution.

Once data is sent from the source system, it reaches the ARL. However, once received, it’s not used immediately to create contracts and POBs. Instead, data is used to create revenue accounting items (RAIs), which are used as placeholders for data before the data can be used further. The reason for this is simple: once a contract is created, many of the standard RAR data tables are updated, and a revenue schedule is generated. In total, we’re talking about potentially more than a dozen tables being updated, and, for time-based POBs, potentially many lines being created for the revenue schedule. Not to mention that if the contract needs to be combined with some already existing contract, the modification process is also triggered. All of these reasons and more led SAP to this RAI approach, where an initial data quality check is performed before contracts can be created. Here, SAP offers different statuses that should enable even more control over data quality.

Once data is processed in ARL, it’s checked against rules in Business Rules Framework plus (BRFplus).

Business Rules Framework Plus: BRFplus is a tool used to define rules without needing to write ABAP code. It’s not a new tool and was first available with SAP S/4HANA release 1610. For example, if you think about writing validations or substitutions in finance, more often than not, you need to invite your ABAP programmer to write some code, followed by the whole substitution needing to be regenerated, which requires special transport methods. The idea of BRFplus is that the same can be achieved without writing a line of code by just using decision tables. Usage of BRFplus is gaining traction recently with the move to BRFplus for configuring output management in sales and distribution.

BRFplus comes with different applications that are used to do the following:

• Determine POBs and POB types
• Determine rules for changes in POB statuses
• Perform account determination

RAR comes with predelivered applications that are dependent on the type of integration the customer is performing (SAP Billing and Revenue Innovation Management, sales and distribution, or third party). To use these applications, they should be copied to the customer’s namespace and adjusted to fit the customer’s specific needs.

Once RAIs are processed, the main RAR objects are created or updated—depending on the RAI type.

If the order is created in sales and distribution and processed as an equivalent RAI type, a result contract and corresponding POBs are created. If we processed a fulfillment item or an invoice, tables maintaining such values will be updated together with tables maintaining data for revenue calculation.

So, we have contracts created/updated and that means we’re ready for the month-end closing process. In RAR, that refers to running ABC programs. There are three programs that need to be run so the results of RAR processing can be seen in financial accounting.

Running ABC Programs: Customers often have questions about how often programs for calculating and posting revenues should be run. Of course, if reporting of revenue needs to be made more often, then ABC programs should be run more often because data in finance will land only once and be calculated by RAR. Some customers are happy with running the programs once a month, but others opt for running more often. Month-end closing in RAR isn’t possible if contracts are in error (without moving them to the next period). So, running ABC programs once a month may not provide enough time for solving potential issues. On the other hand, running ABC programs in extremely short intervals can cause deadlocks between programs. So, each customer is unique (it’s not the same if contracts are made primarily of event-based or time-based POBs) and needs to determine the best option while considering the potential problems that come from running programs too often or not often enough.

Optimized Contract Management

As mentioned, RAR as a tool has been on the market for close to 10 years. Its flexibility and performance were really tested during the introduction of IFRS 15. For example, it was the first tool in SAP ERP that could be used for integration with external systems to perform revenue recognition. This caused a situation where the design of the solution needed to be adapted to fit new, changed requirements.

SAP S/4HANA brought improvements to RAR in two phases:

• With release 1909, optimized contract management (OCM) was introduced
• With release 2020, optimized inbound processing (OIP) was introduced

Both improvements are optional, meaning that the customer isn’t required to use them. This was done mainly to reduce the risk for customers who are already using RAR and have a significant number of enhancements.

As mentioned before, both OCM and OIP were primarily oriented toward solving different technical and performance issues noted by customers while using RAR.

The following main improvements came with OCM:

• Day-based contract modifications: In classic contract management (CCM), there is complex logic between the nominator/denominator that was used both for time-based and event-based POBs. In OCM, the system works with days for time-based POBs, allowing more precise calculation of modifications and proper triggering of prospective instead of retrospective modifications.
• Contract termination or impairment calculation: One of the biggest pain points in CCM occurs when the contract is terminated. In those cases, everything that was a contract asset should be reposted to profit and loss (P&L). However, SAP didn’t come up with a solution for this business scenario mainly due to the different variations of the process, which would need a lot of custom logic to be handled properly. In OCM, terminations are standard functionality.
• Contract acquisition costs at the contract level: In OCM, RAR supports recognition of acquisition costs as an asset and amortization of those costs to fit revenue recognition rules.

The following main improvements came with OIP:

• No batch processing for RAIs: This was the main improvement that came with OIP. In classic inbound processing, you needed to either schedule a job or run Transaction FARR_RAI_MON to process RAIs. This often caused deadlocks and errors that would leave RAIs in error. In OIP, there is an option to process RAIs in real time and avoid this problem.
• Redesigned and optimized technical architecture of tables: In classic inbound processing, tables and application programming interfaces (APIs) would be dynamically created depending on the structure and options the user activates. For example, if the user adds profitability analysis as an integration with RAR, characteristics would be added to table FARR_D_POB. In addition, /1RA tables would get generated once RAI classes were activated. In OIP, these activities aren’t needed anymore: RAR comes with a static set of tables that fit their defined purpose.

However, the introduction of OCM and OIP has a few limitations. For example, some functionalities that existed before aren’t available anymore, and a few business add-ins (BAdIs) that were available are replaced with new ones. This information is especially handy if the user is planning to upgrade from classic to optimized versions and considering inbound processing as well. In addition, when it comes to integration with the Project System module for project management, this can only be done with CCM.

Event-Based Revenue Recognition

With EBRR, costs and revenues are posted as they occur, meaning they are immediately matched and posted. EBRR is integrated with the general ledger in real time, meaning revenues are posted and can be found in the income statement and margin analysis (margin analysis is the new version of account-based profitability analysis). In reality, this means that unlike RAR, in EBRR, information about recognized revenue is available as soon as the revenue is posted. There are no jobs to be started or batch jobs to be run: revenue is posted and can be reported.

EBRR is focused on solving revenue reporting issues that are built around different scenarios. When published, EBRR was available only on the cloud, without options to perform allocation of revenue and no parallel reporting capabilities (thus the name event-based). However, with release 2022, the tool was made more advanced and comprehensive to fulfill complete IFRS 15/ASC 606 requirements. If companies have scenarios that are compatible with standard SAP delivery, EBRR can be seriously considered as the choice for tracking and recognizing revenue.

Editor’s note: This post has been adapted from a section of the book Revenue Accounting and Reporting with SAP S/4HANA by Sreten Milosavljević and Swayam Prabha Shankara.