Revenue Management Engine in Oracle EBS

Revenuerecognition.com reports that “One of the primary goals of Sarbanes-Oxley (Sarbox) is to ensure that companies are reporting accurate revenue numbers”. A new survey of 400 public, as reported, and private companies found that more than half (55%) of all public companies,have changed revenue recognition policies as a result of Sarbox and that many of these changes were “moderate”; to “significant”.

None of us can under estimate the importance of accurate revenue recognition in light of Enron episode.

Yet revenue recognition remains largely misunderstood and mismanaged in business world in general and oracle business world in particular. Until R12 we did not have a complete revenue recognizing solution that can accommodate a broad spectrum of industries. But in R12 (and in some releases of R11i) we have some great features supporting revenue recognition practices of companies.

When to recognize the revenue is a very big and complicated question. Different industries have different practices and different countries have different laws governing the same.

What Oracle EBS Offers?

In Oracle EBS we have basically three approaches to recognize the revenue for a transaction.

• Using Accounting Rules. We can define accounting rules with specified percentages of revenue to be recognized over the period of time as deferred revenue.
• Using Revenue Recognition policies and Contingency events: We can specifiy revenue recognition policies as global rules and default them in transactions to defer the revenue to be recognized later.
• Using public APIs we can extend revenue recognition approach as per the needs of an organization.

Revenue Management using Accounting Rules

Prior to the introduction of revenue management functionality, the only way to defer the revenue (to be recognized at an appropriate point of time) is using Accounting Rules. Once defined, these accounting rules can be used in Order Management, Service Contracts and other applications which create their invoices using auto invoice interface. Once the invoice is created for these sources, revenue is deferred based on the accounitng rule setup. Here I am taking a simple scenario of create manual invoice.

Revenue Management using Revenue Policies

Revenue policy simply dictates when the revenue should be recongnized at an operating unit level. Revenue policies are setup with the following options:

• Credit worthiness of the customer
• Non-standard payment terms
• Refund Policy

Creditworthiness

If customer’s credit worthiness is in doubt, we cannot recognize the revenue till the customer pays. In Revenue Management Super User we can setup three (max) possible credit classification profiles. If any of these three classifications are assigned to the customer’s profile classes (as shown in the screen shot), which in turn are assigned to customer accounts, revenue of the invoices created for this customer will get deferred using a contingency rule. Revenue will be recognized only when the customer pays up for this invoice.

Refund Policy

Also a number of companies do have refund policies. Customers can get refund with in some number of days if the product is returned. When we assign the refund contingency to the one of the criteria and if one or more criteria matches to invoice attributes, revenue will be automatically deferred.

Standard Payment Terms

If the company’s standard payment term policy is 30 days and if any customer is given extended payment terms (credit for more than standard number days), all invoices that have payment terms that are non-standard will be deferred. Revenue will not be recognized until the customer pays up.
On top of these three criteria, we can set up contigency rules and create assignment rules. Contingency rules decide under what circumstances invoice’s revenue should be deferred. Contingency rules also use revenue policies defined earler. Assignment Rules match the criteria to consider the invoice for deferral. They work in conjunction with each other.

Custom Contingecy Rules

We can create custom contingency rules with specific parameters or criteria. If the al or one of transaction attributes match this criteria, revenue will be deferred and recognized later at an appropriate time.

API approach

This is most flexible approach. You can find sample script of the ar_revenueadjust_pub API here and here. In this example I am deferring revenue for all the amount of the invoice for 12 months equally. If you are creating invoices all through the day (not in batch mode), you can create a subscription to a standard oracle business event oracle.apps.ar.transaction.Invoice.complete (as shown in this API). If it is in the batch mode, you can create a concurrent program and run that after invoices are created or imported but before accounting is created in Subledger Accounting to transfer to GL.

In continuation with the Revenue Management discussion here I am discussing the role of revenue contingencies in importing invoices using Auto-Invoice or ar_invoice_api_pub from external sources or partner systems.

Just to recap, if you have revenue policy enabled (as seen in the screen shot here, if one of the options is enabled, it means you have enabled revenue policy) revenue of all transactions that violate revenue policy will be automatically deferred. This logic applies to transactions coming from legacy or partner systems also (using either ar_invoice_api_pub or ra_interface tables). Additional qualification for this is that the revenue management should be installed (in R12 it is always installed, though, I predict this will be a separate product in coming releases).

Revenue policy can be violated in AR by using non-standard attributes in a transaction or creating a transaction for a customer whose profile has credit classification which is part of the revenue policy. There are two standard attributes: Refund or Payment Terms. If you specify 30 for Standard Payment term it means your revenue policy is to recognize the revenue (do not defer) as long as the payment terms are 30 or less number of days. If we use any other payment term (non-standard), it is violating the Revenue Policy hence revenue recognition should be deferred till the removal event occurs. On the other hand if you specify 14 days in Standard Refund, that means all the transactions that qualify for this contingency, can have revenue recognized only after 14 days (since in 14 days customer can reject the goods).

In addition to the revenue policy, Oracle has seeded some contingencies. Each contingency has a deferral reason removal event attached to it. This means, only when that removal event occurs, deferred revenue will be recognized. One example is payment of invoice is deferred removal reason for all the invoices that have non-standard payment terms (revenue will be recognized only when the receipt is applied). These removal events are seeded and there is no room for defining custom removal events. But you can create your own contingency rules and assign these seeded removal events.

So what this means for AR conversion? If the converted invoice violates the revenue policy will the revenue be deferred? Are there any options available not to defer the revenue though the revenue policy is violated? See this screen shot of interface lines in AR. This is what we are concentrating on.

These following simple cases are taken to test. In each case a SQL is used to insert into interface tables and ran Autoinvoice Import program.

Case1: A non-standard payment term is used to convert invoice. Just two tables are populated : ra_interface_lines_all and ra_interface_salescredits_all. As I have used non-standard payment term, revenue was automatically deferred which can only be recognized when the invoice is paid. Your can find the sql to test this case here.

Case2: A non-standard payment term is used to convert invoice. But three tables are populated: ra_interface_lines_all, ra_interface_salescredits_all and ra_interface_distributions_all. The last table was populated for Account class ‘REV’ which is for revenue for a specific account. Result was revenue got recognized instantly ignoring the non-standard payment term. The reason for this is this simple: if we are passing revenue line in the distribution, we are saying that the revenue is already recognized, hence do not defer again. Your can find the sql to test this case here.

Case3: Objective of this case was to not to defer the revenue though a non-standard payment term is used. A non-standard payment term is used with the following tables: ra_interface_lines_all and ra_interface_salescredits_all. In order to achieve the objective, we need to populate another column in the ra_interface_lines_all table: deferral_exclusion_flag. Once this column is populated as Y, revenue was not deferred. Your can find the sql to test this case here.

Case4: Finally used a contingency rule. In this case apart from populating ra_interface_lines_all, ra_interface_salescredits_all, I populated another table ar_interface_conts_all with contingency_id 4 (which is Doubtful Collectibility), taken from ar_deferral_reasons. Revenue was deferred as expected. Your can find the sql to test this casehere.

Apart from the standard destination tables which are populated by auto invoice program (ra_customer_trx_all, ra_customer_trx_lines_all ra_cust_trx_line_gl_dist_all and ra_cust_trx_line_salesreps_all), if there is contingency that defers the revenue, these two additional tables are populated : ar_deferred_lines_all and ar_cont_lines_all. Both these tables can be joined to the ra_customer_trx_lines_all using customer_trx_line_id.

So to conclude, starting R12, we have to remember contingencies also while converting AR invoices. If ignored, this will have some bad consequences. If you did not want to recognize the revenue because it is already recognized in the legacy, but only receivables, we usually use dummy revenue account while converting AR invoices. But if this gets deferred, (no revenue accounting is generated, but only unearned revenue ) upon the removal of this contingency, revenue will be posted to the account per the auto-accounting setup automatically which was not required.

If you do not want any revenue to be deferred when converting using autoinvoice, then you have to ensure that:

1. There are no revenue policy violations for the invoice or do not create any revenue policy.

2. Use deferral_exclusion_flag in ra_interface_lines_all.

3. Do not use contingencies table (ar_interface_conts_all).