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:
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 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:
Let’s discuss both of the solutions at a high level to shed light on which solution is most appropriate for certain business cases.
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:
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:
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:
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.
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:
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:
The following main improvements came with OIP:
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.
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.