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 AccountingAdopted Performance Obligation Accounting
You defer that part of a sales invoice you can't recognize as revenueYou 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-monetaryYou value the accrual at estimated consideration and it is a monetary debt.
You Calculate and book liability when you issue invoicesYou 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 & LLiability 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 industryYou 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)

Key features of Oracle Financials Cloud

This article provides some Key features of Oracle Financials Cloud.




Multi-dimensional reporting. This is a key feature for general ledger. General ledger in the Financials Cloud integrates with Essbase, a multidimensional database that can generate financial statement reports. You can use the data from Essbase using Oracle Financial Studio reports, using Smart View, a spreadsheet tool so accountants can retrieve these reports in a very familiar environment, in Microsoft Excel.

Extensive spreadsheet integration. You can create quite a few transactions in different modules in an Excel spreadsheet template. So in receivables, you can create customer receipts. In AP, you can create supplier invoices from a spreadsheet template that Oracle provides. This extensive spreadsheet integration also defining setups, such as GL setups, banking setups, etc. 

Embedded Oracle Transactional Business Intelligence (OTBI). Oracle delivers OTBI reports, but you can also create your own OTBI objects to answer daily business questions. This would be a reporting tool available to all of the the subledger applications, like Revenue Management and receivables, payables, cash management, etc.

Infolets and Infotiles. They help our users see what needs to be done on a day-to-day basis. These mini dashboards improve efficiency and guides the end-users through the daily processes that need their attention. Check out a separate article for more information on this: Overview of Infolets and Infotiles in Oracle Fusion Applications.

Imaging integration for Payables. You can create a supplier invoice based on an image. So that image of that invoice, a PDF document or a document ending in an extension like JPEG, JPEG can be sent to an email account that Oracle provides, and then we use technology to read the images in that document and create a supplier invoice.

Role based dashboards. These are navigational components that allow a user to do a number of functions related to their jobs in one navigational component, multiple links, multiple sections in a page, and that increases efficiencies. It reduces the number of clicks are they have to do.

Below are some Oracle Financials Cloud modules:




A detailed description and function of each Oracle Financials Cloud modules can be found here: Overview of Oracle Financials Cloud modules.

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)

Standalone Selling Prices in Oracle Revenue Management Cloud

What is Standalone Selling Price?

Standalone Selling Price (SSP) is the price of a component of a contract if you purchase it separately. SSP is needed to allocate transaction price of a contract and that impacts the revenue recognition amounts. Previously, the term used was "Revenue Price", but was recently changed to Standalone Selling Price.

Standalone Selling Price Analysis
  1. Unit price. Think of a list price. For Example, you might have differences if you're selling software to resellers as compared to selling directly to customers.
  2. Discount Percentage of Unit list price. Depending on the volume, you might extend certain discounts. For example, a customer purchased 1000 units of a product, then the customer gets a discount.
  3. Gross Margin Percentage. You charge for certain services based on a target. For example, you base your price on a certain percentage margin, a quota that you would have to reach.
  4. Percentage of Base Unit Price. For example, you could price a service like software support at 15% of the license.
How are Standalone Selling Price configured? 

There are three methods to load SSPs. If you already have your pricing setups in place, then you can automatically calculate them based on historical data. When they're automatically calculated, we call them observed standalone selling prices (OSSP).


When you go with the spreadsheet approach, you call this estimated selling prices (ESP). ESPs have two others options in terms of using a spreadsheet template. You can upload SSPs using a standalone selling price profile

Generally SSP is calculated based on contracts (if data is available). If your product is new or you do not have enough contracts data then system uses ESP for allocation of contracts.

In such cases, you may try importing ESP values and run "Calculate Observed Standalone Selling Prices" process. You can setup SSP profiles to set the limits as well. Additional reference can be found here for more details on the SSP Profiles.

The other way to do it is by loading the standalone selling prices together with revenue basis data. If you do that, you are bypassing the pricing setups and just loading that along with the revenue data. 

What is a Standalone Selling Price Profile?

Standalone selling price profile is a configuration that allows you to put all of your pricing setups in one place. Inside the Standalone Selling Price Profile Task, the is a "Load SSP" button that allows you to load the SSPs manually through a spreadsheet template.




Pricing Dimension Assignments. This configuration allows you to map your Pricing Dimension Structure (including its segments) to a document type. Those Source Documents are the documents that will contain revenue data to be populated into Revenue Management Interface Tables. The idea here is that the pricing is going to be specific to a document.  More detailed information about Pricing Dimensions Structure, including Price Bands, Value Sets, Instances, can be found in Overview of Pricing Dimension Structure in Revenue Management Cloud.

Source Documents will be assigned to Pricing Dimensions. Source Document Types are used for integrating third-party applications and Revenue Management together. Examples of Source Documents are sales orders, warranty contracts, etc.

Performance satisfaction plan (also called Revenue Scheduling Rules) indicates how the revenue is going to be recognized. It dictates if we're going to recognize the revenue at a point in time at once, one period, or over time, multiple periods, etc.

Below is a Video Demonstration on Managing SSP Profiles:


Below is a Video Demonstration on Creating SSPs:




Below is a Video Demonstration on verifying created SSPs:


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)

Recent Posts

SQL Fundamentals

Introduction to SQL and Syntax What is SQL? SQL stands for Structured Query Language. is a standard programming language for accessing datab...

Top Posts