An entity might face different issues when it comes to revenue recognition.
Depending on the industry, this can be regarding fulfilling matching principle requests (reporting costs and revenue in the same period), allocating revenue to proper performance obligations (POBs), dealing with huge volumes of data, or constant contract modifications. In addition, changes in business models are occurring where more industries that were traditionally oriented to sales of goods are now trying to sell their products as services to ensure revenue flow over time.
The revenue accounting and reporting (RAR) solution from SAP can help entities in fulfilling these requirements. However, based on the recent SAP portfolio, RAR isn’t the only solution that can be used for this purpose.
With event-based revenue recognition (EBRR), costs and revenues are posted as they occur and are immediately matched and posted. Looking at the SAP portfolio (current as of time of writing), SAP offers three main tools for revenue recognition. The oldest, classic tool is results analysis, which has been on the market for a long time and was built to measure the progress of project execution and make appropriate financial postings. In that sense, it evolved over time, and, even now, it’s the go-to tool when it comes to projects and internal orders financial management of progress. Besides the variety of features available, results analysis is also very extendable: there are multiple enhancement points the customer can use to tailor it to the company’s specific needs. Finally, being on the market for a while means that a significant pool of people is now proficient and possesses the knowledge to work with results analysis.
However, the idea of results analysis was always to be a tool used while integrated with Project System or internal orders. Of course, if a customer decides to use WBS as the account assignment object for all of their sales, it could be applied outside the classic project systems environment. In reality, however, this would be too limiting an approach, so it isn’t used in practice. Even if this would be possible, when it comes to IFRS 15 and ASC 606, the results analysis key wouldn’t be able to satisfy the five-step model with creation of POBs or allocation of transaction price. In that sense, the tool can’t be used for IFRS 15 reporting.
The next tool, RAR, is now close to a decade on the market, but it still can’t be considered a veteran solution like results analysis. RAR was built as a tool to enable IFRS 15 reporting, so that’s definitely a strong point. In addition, irrespective of the industry undergoing an IFRS 15 implementation, we can claim with confidence that RAR can be used to provide valid IFRS 15 results. There are also many implementations where RAR was positioned as one segment in even non-SAP environments where the main role was to do IFRS 15 reporting. To add to the point, RAR wasn’t developed as a standalone tool, but as an upgrade to Transaction VF44, which essentially means the experience accumulated in an old revenue recognition tool was used in RAR and upgraded. Maybe the biggest advantage of RAR is that extensibility makes it very applicable in industries that are becoming more and more service oriented. If a company is thinking about switching business models where instead of selling machines as standalone units, they will merge them with some services (e.g., maintenance, operations) and bill them based on some measurements over a period of time, RAR supports these scenarios natively (keeping in mind that some modifications in business processes are performed to reflect business change).
But there are business scenarios that aren’t so easily integrated with RAR. When it comes to the professional services industry, RAR isn’t calculating the percentage of completion (POC) by itself: it’s being done by results analysis, and RAR is just taking over values. Even in this case, it’s limited to three results analysis key methods (cost-based method, revenue-based method, and CCM). Most customers won’t find this limiting because POC is mainly calculated on these methods, but there are business scenarios such as time and material that require adjustments and tweaks to be enabled in RAR. Even once they are enabled, there are limitations that businesses would need to respect when working with RAR. In addition, the extensibility that RAR offers is a burden in some cases: for some businesses, it might turn out to be complex and too lengthy of an implementation without providing tangible benefits.
Last, we come to EBRR, the newest of all tools for revenue recognition. As mentioned previously, natively, EBRR was developed on SAP S/4HANA Cloud, public edition and later ported to other versions of SAP S/4HANA. That makes it the most modern solution, but at same time, it comes with a number of predefined scenarios that reveal its main benefit: if the user can fit into those scenarios, then implementation is rapid without too much difficulty. In addition, some scenarios that are pain points to RAR are natively supported by EBRR, hence limiting the number of necessary extensions and enhancements. Being modern means EBRR also makes full use of the latest features from SAP S/4HANA, such as direct integration with the Universal Journal. This saves time used for reconciliation and makes the overall closing process much faster and transparent. With the implementation of EBRR, customers can achieve further simplifications: results analysis keys become obsolete. This means if the customer is able to fit into the standard scenarios offered by EBRR, they might achieve further reduction in total cost of ownership (TCO) by simplifying other modules that are used.
The biggest advantage is at same time the biggest limitation of EBRR. The solution isn’t (or better said, isn’t yet) extendable like RAR or results analysis. So, if some extensions are needed by nature of the business, it might turn out that without a specific business process design, requirements simply can’t be fulfilled. In addition, some areas are yet to be developed, such as support of different contract combinations, modifications of contracts, or integration with external systems. EBRR is simply not ready to take over tasks that are normally done by RAR. Again, EBRR is a very new tool, which means the number of people working with it isn’t as high. All these factors need to be taken into consideration before a company opts for this solution for revenue recognition reporting.
Explore the principles of EBRR in this blog post.
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.
Comments