Devolve Performance Obligations in Revenue Management Cloud

The idea here is to devolve a single performance obligation into a series of performance obligations at contract inception. What does it mean to devolve? Let's think of it as converting one parent obligation into a series of smaller obligations. It allows you to convert that parent performance obligation into a series of obligations underneath children obligations.

An example would be a telecommunications company. They want to devolve or splitting or extending a year's commitment to provide services, and they want to devolve that commitment into 13 billing periods, instead of 12 periods.

Revenue Management will automatically devolve a performance obligation based on setup.

It devolves into a series of performance obligations by accounting period. So the methodology here is going to be the accounting period. And so we discussed a moment ago the example of the telecommunciations company wanting to stretch, extend, that obligation, that year commitment, into 13 billing periods. It creates an initial performance event on the obligation series-- in our case, the transaction price-- and recognizes and manages revenue on the obligation series.

Once that parent obligation is devolved, Revenue Management will go through the five steps to revenue recognition. And once that particular performance obligation is satisfied, the series of performance obligations are satisfied, that revenue is going to be recognized.

This is going to happen at contract inception. And so the identified customer contracts program will identify the performance obligation that needs to be devolved.

You have to tell Revenue Management which performance obligations need to be devolved so that it can capture that information and proceed to a split or to convert that one obligation into a series.

What is the business value of this new feature?

The idea is that these can be done automatically. Once you do the configurations, you don't have to do manual adjustments. There's nothing to do in GL where you have to enter a journal entry to make a correction. This is something that's going to be originated and taken care of in Revenue Management for each accounting period.

What happens in scenarios where you have returns and revisions if the performance obligation has been devolved?

When this happens, Revenue Management will recalculate amounts. What are those amounts that we are thinking about? We are thinking about our performance obligation amounts, Allocation, revenue recognition amounts

how is it going to recalculate? It's going to recalculate based on the revised amounts for the parent performance obligation. So it's going to look at this revised amount of the parent performance obligation.


Besides returns, the revision can be that a new line is being added to an existing contract in a material update or immaterial update. In both situations, Revenue Management is going to recalculate as safe as we've established here.

Setup Components

There are two key setup components: the performance obligation identification rules, and the implied performance obligation template (optional).

Manage performance obligation identification rules. there is an  attribute there called "devolved performance obligation". This is something that you specify on the rule level. These rules are specific to the identification of performance obligation.

Implied performance obligation templates. This allows you to capture performance obligations that might not be in your source system.

There is the flag all the way to the end there called, devolve performance obligation.

Revenue Recognition in Oracle Revenue Management Cloud

Revenue is Recognized when performance obligations are satisfied, either by Point In Time or Over Time. Together with the Satisfaction Measurement Model and Satisfaction Method, they drive when the revenue is recognized point int time or over time.

There are three options on how to recognize revenue:

1. Quantity - Usually used for Products
2. Period - Usually used for Products
3. Percent - Usually used for Services

You can see that you can go with the option "Require Complete" or "Allow Partial". If it's a service that we are providing, like a warranty service that's going to extend for a number of years, we measure that performance obligation over time. As time goes by, we recognize the revenue. If we deliver physical products, we measure that performance obligation point in time. 

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)

Reporting for Revenue Management Cloud

Oracle Fusion provides two predefined reporting tools for Revenue Management Cloud: Business Intelligence Publisher and Oracle Transactional Business Intelligence.

A Business Intelligence Publisher (BIP) is a reporting tool that you run by navigating to the Scheduled Processes page. These are usually business-specific reports are are either sent to external business contacts. 

Oracle Transactional Business Intelligence (OTBI) is a reporting and analysis tool used to create Analyses and Dashboards. These are usually used by internal teams rather than an actual report submitted externally such as auditors, governments etc. OTBI can also be used to create custom Infolets, which are miniature versions of dashboards. For more information on OTBI, check out a separate article: Overview of Oracle Transactional Business Intelligence in Oracle Fusion Applications.

Oracle Fusion provides two predefined reporting objects for Revenue Management Cloud:

1. Revenue Contract Account Activities Report (BI Publisher)
2. Standalone Selling Price Dashboard (OTBI Report)

Also, Oracle Fusion provides two predefined reporting Subject Areas than can be used by OTBI:

1. Revenue Management - Customer Contracts Real Time
2. Revenue Management - Standalone Selling Price Real Time

Below discusses the objects and subject areas in detail:

Revenue Contract Account Activities Report gives us account balances by performance obligation to support the audit process and perform detail analysis. This report shows information about revenue contract, performance obligation, customer name, source document references, period information, and most importantly account classes. 

Account classes are accounts that you're going to see in connection with activity for a customer contract. They correspond to contract liability, contract asset balances, contract revenue, etc. 

This is a BI Publisher report that is available to you out-of-the-box and you can run the report for a given ledger, and one or multiple periods, and you can also narrow down the results of the report by account class. It is defaulted to an Excel output. but it can also be data, or in CSV as well.

Standalone Selling Price Dashboard allows your organization to analyze standalone selling prices for a single period or a range of periods.

To Navigate to the Standalone Selling Price Dashboard, Click on the Navigator > More > under Tools, find Reports and Analytics. From Reports and Analytics > click on All Folders > Click on Shared Folders,> Financials > Revenue Management > Standalone Selling Price. Inside of this folder, find standalone selling price report.

Revenue Management - Customer Contracts Real Time. Provides real-time information on accounting contracts. Details for contracts, performance obligations, and promised details include related revenue prices for an effective period, satisfaction, billing, revenue distribution and accounting.

Revenue Management - Standalone Selling Price Real Time. Provides real-time information on Standalone Selling Prices and tolerance ranges for an item group, item or memo line by pricing dimension, item classification and effective period.

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)

Overview of Pricing Dimension Structure in Revenue Management Cloud

This article gives an overview about Pricing Dimension Structure in Revenue Management Cloud, including its components and importance. The diagram below shows the components of a Pricing Dimension Structure:

Pricing Dimension Structure Instance is the management structure of Pricing Dimensions. It provides additional settings here at the instance level of the Pricing Dimensions, such as enabling of the Creation of Dynamic Combinations. The relationship between the Pricing Dimension Structure and the instance is 1 to 1.

When the Creation of Dynamic Combinations is enabled, this means that combinations can be added dynamically, You don't have to pre-define the combinations because we are saying that they can be dynamically added when you are defining the Standalone Selling Price.

Pricing Dimension Structure acts like a Key Flexfield (KFF) and will allow your organization to depict its current pricing policies. Each structure is composed of segments, and a structure can have up to 30 segments. Each of these segments need a value set for each segment in your structure.  

Value Sets

A value set determines the data type that will be used by the segment and will validates and control the values and that are acceptable for that segment. Also, a Value Set dictates the Size and Numerical Precision of a Segment.

Each Value Set can have different types of validation such as Independent, Format Only, Table, Dependent, etc. It is the best practice to always use independent. More information can be found from the Oracle Official Documentation. 

In the example above, the Pricing Dimension "Hardware Products Discount Policy" is composed of three Pricing Dimension Segments (Geographical Region, Deal Size, Customer Type). 

The Segment "Customer Type" has the data type "Character" and the acceptable values are only "Government" and "Commercial". As for the segment "Deal Size", you can define the ranges of amounts that will be acceptable. 

Below is a quick video demonstration on how to create Pricing Dimension Instances, Structures and Value Sets in Revenue Management Cloud:

Pricing Bands

Price Bands are optional pricing configurations. Each segment in Pricing Dimension Structure can have a label. Price Bands Type can be Set, Quantity or Amount:

In the Example below, Quantity Band defines the price if the customer is purchasing between a certain number of units.  

We are looking at volume of the units purchased. The more units we sell, the lower the price is going to be for the customer. You want to give them a favorable price.

As for the Amount band, it is saying if the deal size is between a certain amount, it will correspond to a certain unit price. 

So you have the values high, medium, and low. And then these are the dollar ranges there. This means the more the customer buys, the lower the price will be.

The Set Band, on the other hand, uses criteria other than volume and deal size. This means that you can drive your pricing without looking at the size or volume of the deal. If you look at this example below, it uses the geographical information. 

We see here North America. And then we see here the countries within North America, the United States. Countries that belong to the European Union. And that might be a criteria that you want to use in your Pricing Dimension Structure.

The implementation task of creating Price Bands is "Manage Pricing Dimension Bands for Revenue Management".

Deploying the Pricing Dimension Structure

Once the structure has been finalized, you need to run a Deployment process for your structure to validate the structure and make it available to be used.

Below is a quick video demonstration on how to create Pricing Dimension Assignments in Revenue Management Cloud:

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)

Overview of the ASC 606 and IFRS 15 Revenue Management Standards

What is the ASC 606 and IFRS 15 Standards?

ASC 606 and IFRS 15 are two standards for Revenue Recognition. One was issued by the International Accounting Standards (IAS) Board, and the other standard was issued by the Financial Accounting Standards (FAS) Board, respectively. 

The core concept behind ASC 606, IFRS 15 is

An entity recognizes revenue to depict the transfer of promised goods or services to customers in an amount that reflects the consideration to which the entity expects to be entitled for those goods and services. 

ASC 606 and IFRS 15 replaces ASC 605 and IFRS 18, respectively with the following enhancements:

• Expected Consideration. One key principle in the new revenue principles is expected consideration. This means that we have one common revenue definition for all industries, regardless if it's a telecommunications industry, the software industry, it needs a revenue recognition standard.
• Performance Obligation. Introduced the concept of the performance obligation. The concept of the performance obligation replaces deferred revenue. 
• Deals are valued at inception. This doesn't necessarily mean deals are only valued when the billing happens.
• Point in Time and Over time Recognition of Revenue. Revenue is now recognized point in time and over time, depending on the product or service that's being provided. 
• Contract Revision Tracking. Enables tracking of corrections or modifications made to the contract 
• Seven Tests for the Transfer to Customers
• No Dependency on Billing

Who must adopt and when must you adopt the new revenue standard?

• Covers all commercial public companies in the USA and all the IFRS countries. If we look at IFRS countries, we can see that there are about 150 jurisdictions or countries that should comply with the International Financial Reporting Standards. 
• Covers all industries
• You must adopt the effective first day of the new fiscal year after January 1, 2018. In terms of date, you must adopt the effective first day of the new fiscal year after January 1, 2018. The actual adoption date depends on whether your organization is using a fiscal year versus a calendar year. If it is a calendar year, then that means you're looking at January 1, 2018, and if it's a fiscal year, then it depends when the fiscal year of your organization starts. For Example: Oracle Corporation uses a fiscal year that starts June 1. So June 1, 2018 will be the day that Oracle would have to comply with a new standard, because we are using a fiscal year to report our results, not a calendar year.

What has changed between the old and new standards?

Below are some key points that has changed between the new standard versus the former standard. 

Obsoleted Deferred Revenue Accounting	Adopted Performance Obligation Accounting
You defer that part of a sales invoice you can't recognize as revenue	You accrue for goods and services that you owe to customers because either you or they have relied in the contract. You no longer defer revenue.
You value the deferral at fair value and it is non-monetary	You value the accrual at estimated consideration and it is a monetary debt.
You Calculate and book liability when you issue invoices	You calculate the liability at inception and book it when either party acts. An "act" could be shipping or invoicing.
Liability is a list of invoices not yet posted to the Profit and Loss (P & L) in full or in part for future release to the P & L	Liability is a list of good and services you actually owe to customers for future satisfaction via a transfer.
You book the invoiced amount to the P & L when you meet the regulatory definition by industry	You book revenue to the P & L when you satisfy the customer with no industry-specific rules bill or not billed.

You defer revenue in the old standard you accrued for goods and services that you owe to the customer, because you haven't delivered the service/product yet. Under the new standard, you no longer defer revenue.

The third entry in the table is a major departure from the old standard. Under the old standard you calculate and book liability when you issue invoices. Under the new standard, you calculate the liability at inception. You calculate that liability at inception and book it when either party acts. An act could be shipping a product, invoice issuance or deploying a consultant to provide services to an organization.

Under the old standard, liability is a list of invoices that have not posted to the GL. Under the new standard, liability is the list of goods and services that you owe to your customers for future satisfaction. You haven't transferred that service or delivered the good yet, so you're not really at a list of invoices.

Example of Calculating Liability

Take the example below:

A sales consultant was deployed to assist customer X on May 10, 2019 and provide a demo of the product. Customer X has agreed to the purchase and a sales order was booked on May 15, 2019. The Product was shipped on May 18, 2019 and the Invoice was issued on May 19, 2019. When will liability start to be tracked? Will it be during the deployment of the consultant, or when Customer X has agreed to purchase the product?

According to the new Standard: "you calculate the liability on inception and book it when either party acts. An act could be shipping or invoicing. However, an act could also be deploying a consultant to provide services to an organization according to a contract."

In this use case, if the deployment of the sales consultant is not in a capacity to provide services that were offered as part of the contract, then you should not consider calculation of liability. In the provided example, the sales consultant was only providing a demonstration of the Product, and therefore, there was no "signed" agreement yet. This is not yet part of the contract and is not tracked as a liability.

However, if the deployment of a sales consultant IS part of a contractual agreement, then it is considered as a performance obligation, and therefore, will already be tracked as a liability.

Accounting Differences of the Performance Obligation between the old and new standard

A performance obligation is a promise in a contract with a customer. When you enter into a contract with a customer, then that means that you are obligated to provide a service or deliver goods. Below, we have also a comparison of Performance Obligations from an accounting perspective, showing you the debits and credits.

A Sales contract is initiated to deliver $1,000 of services over time at $100 per month. Billing occurs quarterly upon satisfaction in arrears. After initial Successful deliveries, customer agrees to pay $300 for delivered services, plus $300 in advance.

In the obsoleted accounting standards, nothing really happens until you bill. Everything starts with the billing process. We only recognize revenue by the end of the quarter. In the new, adopted accounting standards, Liability and Assets change as we satisfy the performance obligations over time.

Let's take a look at the April 4 entry. What we see here is that there is an obligation accrual, and there is basically the obligation accrual and the right to bill. So when we net these asset and liability balances, we get 0 because we haven't delivered anything yet.

If we go on and look at April 30 and May 30 entries, we can see here that things are moving along. The liability is being reduced independently of billing. When we get to May 30, we can see that the net asset amount is 200. If we net the 1,000 on the debit side, the 800 on the credit side, we get to the net number of 200.

By June 30, the organization then bills the customer for $300 and gets another $300 in receivable as mentioned in the scenario.

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)