TAGS

Recent Posts

Archives

Customer Case Study: How to Implement Revenue Recognition in Oracle Hyperion Planning or PBCS
Posted on August 30, 2017
Author : Tony Tauro, Performance Architects

In a previous blog post, we took a high-level look at the basic principles behind the revenue recognition concept. In this post, we demonstrate how to implement revenue recognition in an Oracle Hyperion Planning or Oracle Planning and Budgeting Cloud Service (PBCS) solution.

Our customer’s planning application was used to analyze sales data from an external system. The results of this analysis fed into the enterprise resource planning (ERP) system as general ledger (GL) entries. That makes it a typical use case for a planning solution. However, part of this analysis included revenue numbers, including when to recognize this revenue. Thus, it made sense to build in limited revenue recognition functionality in the planning application, rather than try to implement a separate solution for just that functionality.

To create this solution, we had to store certain types of data in the planning solution.  The most critical was sales data, which came in as invoices; the goal of the revenue recognition exercise was to decide the date on which a particular line item of an invoice should be recognized.

Invoices are straightforward to import because the content in the invoices is easily divided into dimensions and facts. Customers, products and invoice numbers are obvious candidates for dimensions. Each customer number is a dimension member in the customer dimension, but we needed separate dimensions to account for the customer billing entity versus the delivery entity. Facts like quantities, amounts and related calculated values were all stored in the “Accounts” dimension as separate members. The “Currency,” “Year” and “Period” dimensions were implemented as standard dimensions.

The planning application allows us to maintain as many versions as needed, and we used two, “Actual”” and “Final.” Actual contains the “raw” data. Rules are applied and required adjustments are made. These edits are kept in members reserved for the edits, so that the actual data is not changed. After the review and edits are complete we transfer the “finalized” data into the Final version.

This brings us to the second item: we had to model and store the rules in our planning application. Luckily, the vast majority of the invoices could be recognized based on some basic rules.

The “Scenario” dimension was used to indicate the revenue recognition model that would apply to the invoice. The rules are stored at intersections not used by the invoices. To apply to the invoices, the corresponding intersection would be populated using a calculation rule.

Of course, all rules have exceptions. We also needed to store the exceptions to the rules. Exceptions were usually unique situations that did not fit into an existing rule, and were also not frequent enough to justify modifying an existing rule to accommodate.

Another interesting modeling issue was that sometimes the data from the external system would not arrive in time for the revenue recognition cutoff. This meant we had to provide the ability to manually override any rule-based recognition date.

To get user-initiated data into the system, we used web forms, which our customers seemed to prefer accessing in Excel via Smart View (especially forms that needed a fair bit of scrolling). Much of the processing was done using calculation rules.  However, in a few cases, we found it more convenient to use relational database queries. This was especially true when the data was already outside the cube (before loading into the application and while transferring it between applications) and involved date or date-based calculations.

We used an ASO cube for reporting. The Final version is synchronized into the reporting cube on a regular basis. The reporting cube aggregates the data at any and all levels possible. This allows us to keep the application cube speedy enough for data entry and edits, while the reporting cube can be used for reporting and analysis that feels rather speedy. Using Smart View on a fully aggregated cube is an absolute joy!

Hopefully this post provides a simple overview of an actual implementation of revenue recognition functionality in a planning application. It is necessary to justify including such a requirement in a planning application, but can be done using standard planning application functionality and project methodology.

Have questions about how to implement revenue recognition in your organization?  Contact us at sales@performancearchitects.com and we’d be happy to assist.

 

Share
© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.

Leave a Reply

Your email address will not be published. Required fields are marked *