What is Revenue Management?
Oracle Revenue Management complies with accounting standards that tell the organization to recognize the revenue later after the invoice has been sent. A sample of this would be a multi-period Mobile contract for Voice and Data Subscription, or Streaming Subscription, or a Software Support Contract.
The concept of Revenue Management is that your organization sells a service or product to your customer, but have not fully delivered that service, we cannot fully recognize the whole revenue for that invoice at once because we have to follow an accounting standard. What Revenue Management does is we prorate our revenue from the start and end of the contract. For Example, the contract was for a 12-month period, that's the bill will be pro-rated for 12 months.
An example we can use for this whole article would be a support service provided by Oracle Corporation for a period of 12 months for $100,000.00. The Support fees would be pro-rated in a 12-month accounting period, instead of having it only at one accounting period.
Depending on your Requirements, you may need to configure or update the following setups related to revenue:
- Setup Revenue Recognition
- Revenue Scheduling Rules
- Define Revenue Policies
- Define Revenue Contingencies
Each of these setups will be discussed in detail below.
Setup Revenue Recognition - It's a collection of defaults, options, functionality features that is broken down into two areas, billing-related and cash-processing system options and customer payment system options. Below are the setups for Revenue Recognition:
- Salesperson System Options - Allows an organization to require a Salesperson when you enter an invoice. The idea here is to assign sales credit to that person that sold the product or service so that they can receive commissions based on their sales.
It also has an implication in terms of revenue recognition, because if you make an adjustment to their revenue, the sales credit of that salesperson will be impacted. If the salesperson gets paid based on revenue, an adjustment will also be made to his or her commission.
In some cases, you compensate salespeople on revenue and non-revenue, so it doesn't have to equal 100%. You can strictly compensate a salesperson based on revenue. To do this, you can enter a value in the Sales Credit Percent Limit field.
- Revenue Adjustment Reason Lookup Type – If you create an invoice with revenue recognition rule that has the deferral option turned on, then you need to make sure that you track the reasons for revenue recognition. This Lookup just means you can add reasons to the seeded reasons list so that users can pick the value they need when they are about to recognize revenue manually.
- AutoAccounting based on a Standard Line - If AutoAccounting is based on standard line, the transaction line must either be an inventory item or a memo line, and not a user-entered line.
When you are entering lines for an invoice in receivables, those lines can be adhoc. If you enter an adhoc line, it's going to be difficult for receivables to generate the required revenue accounting information. It doesn't know how to generate the accounting distributions for that line.
However, if it's an inventory item that you are using in an invoice line, AutoAccounting can generate the accounting distribution. It can also can be a standard line, which means that you are defining products and services outside of the inventory module.
Revenue Scheduling Rules - You can create an invoice with revenue recognition rules. A scheduling rule is a rule that tells receivables how to allocate our revenue into the future. It can be that a revenue scheduling rule that tells receivables not to recognize revenue now, we are going to recognize the revenue manually in the future by processing a revenue adjustment. For more information about Managing Revenue Scheduling Rules, check out a separate article: Manage Revenue Scheduling Rules in Oracle Fusion Applications.
Revenue Policies - Revenue Policies allow your organization to make automatic revenue recognition decisions for manually entered and imported transactions. This works in connection with revenue contingencies.
To create Revenue Policies, go to the Functional Setup Manager, pick the Financials offering, select the Revenue Recognition functional area and choose the Task “Manage Revenue Policies”.
Revenue policies can be based on different criteria such as:
- Credit classification- When you create a customer, you can assign that customer a credit classification in the customer profile class setup. It can be excellent, average or poor credit. For example, the customer has excellent credit classification, then you might decide to recognize their revenue right away because they are good payers. Or on the other hand, you may want to recognize the revenue later on if the customers have poor credit, as you don’t want to recognize the revenue now and reverse it later on if the customer fails to pay.
- Refund Policy Threshold- You can use the refund policy threshold column to enter the standard refund period represented in days that you offer to your customers. When you enter or import the transaction, if a line is associated with a contract, receivables analyzes the contract and look at the refund period. And if the contract offers a refund period that exceeds their refund policy, then our contingency is going to be assigned to the line. This is commonly used when your organization might have a certain refund policy where you may allow an unhappy customer a refund within 30 or 45 days. If that's the case, you might want to wait after the refund period has passed to recognize your revenue.
- Payment Terms Threshold– Based on the Business Unit, payment terms and the transactions, receivables will identify that these are non-standard payment terms and therefore we are going to defer their revenue. This will dictate that we are only going to recognize the revenue after the removal event has happened, such as a customer payment, or after 60 days has passed, etc. For example, if there's an invoice created with these a non-standard NET 45 payment terms, it will be subject to a contingency and revenue will not be recognized unless the customer has already paid.
Revenue Contingencies - provides certain restrictions that you apply on revenue recognition that are going to be removed by an event. For example, the event can be payment, or the event can be that 30 days have passed, and now I feel comfortable that I can recognize the revenue.
How Does Revenue Contingencies Work?
You enter and complete the receivable transactions, either manually or automatically. Receivables will analyze the invoice and look at the contingencies and assignment rules that you have defined. If the customer specified in that invoice and the Business Unit matches the contingencies and assignment rules, it will proceed to determine if are there any restrictions for this invoice.
If there are no restrictions, then it can go on and recognize the revenue. If it does find contingencies, it will defer the revenue and wait until a removal event takes place. The removal event in this example is a payment. The system will not recognize revenue until the customer pays. Once the customer pays, it will automatically recognize the revenue for that particular invoice.
Removal Event – Removes the restriction based on an event such as a Payment, number of days passed, etc. For example, if a customer was billed with a non-standard payment term (NET 45), they will be assigned a revenue contingency, in which a payment will be the removal event. Once the customer pays, the restriction will be removed on the revenue, and we will recognize the revenue and report it because there's no risk anymore.
Revenue Contingency Assignment Rules - Defines a rule on how to apply that contingency. You can apply the rule to a given customer or a set of customers.
