Achieving Success with SAP RevRec, Part 3: Structured Approach

Wed, Jul 29, 2015 @ 11:30 AM / by Hans Christian Metz


It’s a joint effort – Part 3 - Using a Structured and Phased Approach

Revenue recognition projects will only succeed if they follow a solidly structured approach. At Bramasol, we have found that one of the aspects causing confusion – in addition to the already complex subject matter – is lack of understanding how to best introduce the SAP Revenue Accounting and Reporting module to an organization, how to prepare good decisions, and when to take those decisions.

Both for consultants, as well as for customers, it is necessary to develop, coordinate, and manage expectations to the benefit of the project.

Demonstrate the Capabilities

To understand the tool, it will be necessary to first look at the tool the way it is intended to work out of the box. This is necessary for many reasons – to understand its approach, simply gain more confidence in its functioning, start the fit-gap analysis, and more. At this earliest stage, it does not make sense to work with customer data already, as more likely than not, this would lead to a discussion of miniscule details of the current treatment of revenues, rather than the understanding of the intended perspective and scope of the solution.

We have found that multiple demos may be needed, to include other stakeholders in the project, and to add some more content (though still generic), or deepen discussions of aspects relevant to the organization. We have also found that this is a phase where the different stakeholders in the customer organization finally realize that they have to work together, and can already identify the project team members and think through resource assignments for the later phases.

During the demo phase, it will also become clear to the customers that they still have not fully evaluated the impact of the new guidelines on their organization. While it may be immediately clear if US-GAAP or IFRS or both are needed to be reported

After the demos have been conducted, the organization has to take the decision to either directly implement the solution, or to test out the applicability - the fit -, of the solution to the organization’s needs.

Proof-of-concept (PoC)

Due to the more generic nature of the demos, there has to be a first step into the actual customer data and processes. Typically, this will not be the direct commitment to a full-scope implementation of the module, but a pilot or prototype.

In our experience, we have found it most useful to start the process with a number of core business scenarios – anywhere from 4 to 8 – which cover the main revenue streams of an organization, and several typical variations of how products are sold and revenue is accounted for. The customer needs to be able to formulate these in the language of the new guidelines, and provide the step-order of the business process, the calculations required, and the expected postings, using the company’s own master data and transactions. These core use cases form the statement of work for the PoC. They should cover a significant percentage of a customer’s business, in terms of dollar or transaction volume.

While they should be realistic, the cases in the PoC should avoid numerous one-off manual steps or unpredictably wrong entries in the operational systems (eg SD) and subsequent corrections. The Revenue Recognition module is typical for SAP in that it follows the assumption that it is much easier to enter data correctly than to allow incorrect data to be forced into the system, and then expect automated error correction. In the end, while it is possible to manually correct contracts and revenue data in the module, widespread manual manipulations would contradict the idea of an automated, scalable solution.

In several of our projects, we noticed that customers had problems applying the new guidelines to their own business, or worse: were not even able to identify the relevant cases. In some cases we were asked to develop the cases for the customer. While this is possible, customers should realize that this understanding of their own business really needs to be developed internally, not outsourced. The organization has to learn to look at their business in the same way the guidelines and the module do, to be able to remain in compliance, maintaining and further developing the module.

At the end of a PoC, the decision has to be taken whether to go ahead with the implementation for the complete scope, implement partially or in phases, or select another solution altogether. However, at Bramasol, we have not yet encountered a PoC ending in the decision to not fully implement the new solution. The advantages of no additional license costs, significantly reduced integration issues, quality programming, and full support by SAP simply outweigh any other consideration.

Full Implementation

A full implementation adds several aspects of importance to the scope. For one, now all cases have to be covered in depth – more complex international ones, more complicated business process steps, more currencies, complete reporting on all cases. We have found that this often leads to uncovering many manual post-processing steps which do not easily lend themselves to automation, and weren’t covered in the minimum scope of a PoC.

Lastly, while in a PoC, existing data is being analyzed and understood better, only after the commitment to a full implementation has been made does it make sense to systematically explore the different layers of data which need to be replaced when revenue accounting data is migrated to the new solution. How difficult this legacy data migration in our experience depends a lot on the current situation of the customer: If revenue recognition was done outside of SAP, this can be a rather straightforward identification of performance obligations already fulfilled, and revenue amounts already recognized. If, however, the current revenue recognition is built heavily on SD customizations, data migration and cutover to the new solution will be a very complex and risky multi-step undertaking.

We at Bramasol have the depth of experience customers need to overcome these challenges and Go Live with SAP’s new Revenue Recognition and Reporting solution.

To gain a broader understanding of the overall challenges presented by the new RevRec standards, you can download one of the Bramasol ebooks on getting "RevRec Ready" or request a free consultation to discuss your specific requirements.

RevRec Ready eBook "Getting Ahead of the Curve" Read it Here

RevRec Ready "Checklist for Success"

Request RevRec Consulting Support

Topics: revenue recognition, SAP Revenue Accounting and Reporting

Hans Christian Metz

Hans Christian Metz

Over 15 years managing complex integration of accounting and SAP ERP software.Roles have included: Systems / Business Analyst, Configurator (Implementer), Lead Consultant, Support Analyst, Consultant, and Manager - at both major as well as mid-size organizations.

New eBook: How to Create a Treasury Environment  that is Integrated, Optimized  and Future Proof Download Now
Download eBook - Transitioning to ASC 842: Why Robust Analytical Reporting Tools will be a must for all Entities

Subscribe to Email Updates

Recent Posts