Revenue Management Cloud Implementation Considerations

Below are some questions that you may have to answer before implementing Revenue Management Cloud for your organization:

1. Contract Identification Rules. What are the common links or attributes across all contract lines?

The keyword here is "common link". What is the attribute that is going to allow your organization to take transactional lines and group them into a customer contract? Is that a sales order number? Is that a purchase order number? These will allow you to define these rules and allow your organization to meet that first step of the new revenue recognition standard: Identify contracts with customers. Check out a separate article for more information on Contract Identification Rules.

2. Performance Obligation identification rules. Once you've identified the customer contract, then you need to identify performance obligation. Performance Obligations are the promises that you have made to the customer. Similar to Contract identification Rules, think about the common elements of the obligation. What are those attributes that I can use to identify the promises that I have made to the customer? It can be some inventory ID, or a product description, or things of that nature. That will clearly identify what is the promise that has been made to the customer. Check out a separate article for more information on Performance Obligation Identification Rules.

For Items 1 and 2, The goal is to have minimal manual intervention in the creation of these contracts. Oracle has predefined three Performance obligation identification rules and contract identification rules but you can define your own. You would need to understand your transactional data, your revenue data, so that you can then define these rules in a way that you will get to that minimum manual intervention that we are looking for.

3. Revenue Price effective periods or Standalone Selling Price (SSP) effective periods. The term "revenue prices" has been outdated and the latest and most updated terminology we use is "standalone selling price".

One of the five steps to revenue recognition involves allocating transaction price, with standalone selling price as a basis. So the question here is, how often are your pricing policies being updated? You would need to observer how frequently you need to update your pricing. Depending on how you answer that question, you're going to appropriately define those effective periods. Is it monthly? Is it quarterly?

4. Threshold Amounts. Another question would be, do you want to subject price changes to manual review? There's some threshold attributes there, and one of those has to do with manual review. Subject is customer contracts based on their amounts to manual review. That can be set in system options. What is the proper amount? Are contracts over $5,000 be subjected to manual review? It all depends on your organization or industry. You're going to come up with a threshold amount, and then any contracts exceeding that threshold amount are going to be reviewed by a human being.

5. Integrations. With regards to Integration with third-Party Applications (EBS and Non-Oracle Systems), below are some additional key implementation decisions:

1. Evaluate if you will continue using EBS or any other ERP versus implementing Financials Cloud. Although we allow that integration with E-Business Suite and other third-party non-Oracle systems, but this is something you might want to think about in terms of maintenance and complexity of the integrations.
2. If you continue to use EBS, you want to make sure you determine which document sources and receivables transactions need to integrate with Revenue Management. 
3. Determine the method that you will use to bring over customers and items to Revenue Management.

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/
Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)