Oracle Business Applications

Someone was frenetically searching for an API to create a credit memo in AR. Certainly there are APIs available to create a credit memo, but the issue is that all of them allow creating a credit memo only against an existing invoice and not on account credit. If you have read the Receivables reference guide it clearly tells you to that the AR_CREDIT_MEMO_API_PUB.create_request cannot be used to create on-account credit memos.

But you can always use AR Interface tables to create on-account credit memo. While there is no recommendation on which one is better, personally my choice is always based on the volume. If it is batch processing, I always prefer using ra_interface_lines_all, ra_interface_sales_credits_all and ra_interface_distributions_all. If it is unit transaction, I prefer API approach as the I can reduce unnecessary coding required to insert and then call the auto-invoice interface and then monitor it whether it is completed or not.

The API in focus here is ar_transaction_pub.create_transaction. Using this you can create all types of transactions that can be created in AR. 

Bad news is this can only be used till 11.5.10. In R12, this API has been obsoleted. From R12, the only way you can create on-account credit memos is using Auto Invoice Interface. 

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.

Before going into any detail, let me take you into accounting world for a brief moment. Fundamentally accounting is based on two methods : Cash Basis or Accrual Basis.

Accrual Basis Accounting

Under the accrual basis accounting, revenues and expenses are recognized as follows:

AR:

•  Revenue recognition: Revenue is recognized when both of the following conditions are met:
      a. Revenue is earned.
      b. Revenue is realized or realizable.
•  Revenue is earned when products are delivered or services are provided.
• Realized means cash is received.
• Realizable means it is reasonable to expect that cash will be received in the future.

AP:

• Expense recognition: Expense is recognized in the period in which related revenue is recognized (Matching Principle).

Cash Basis Accounting

Under the cash basis accounting, revenues and expenses are recognized as follows:

AR:

• Revenue recognition: Revenue is recognized when cash is received.

AP:

• Expense recognition: Expense is recognized when cash is paid.

 Timing differences in recognizing revenues and expenses:

1. Accrued Revenue: Revenue is recognized before cash is received.
2. Accrued Expense: Expense is recognized before cash is paid.
3. Deferred Revenue: Revenue is recognized after cash is received.
4. Deferred Expense: Expense is recognized after cash is paid.

                 Options in 11i                            To                                Options in 12

Till 11i the only way we represent this accounting method is by choosing accounting method in Payables Options in AP and System Options in AR. But in R12 you can see in that these options are gone from the system options of AP and AR. That is where subledger accounting comes in.

Part of the global release concept in R12, accounting methods have to be much more flexible and generation of accounting entries should be configurable.

As we know accounting is the end product of transctions and financial statements are end products of accounting. Also there is a need to seperate transaction from accounting. An accounting clerk who creates an invoice has nothing to do what accounting is behind that transaction. It is the duty of the management to decide accounting behind this transaction.  

Subledger Accounting is taking us in that direction.

Purpose of Subledger Accounting
The end product of Subledger Accounting Setups is a Subledger Accounting Method that can be assigned to one or more ledgers in GL. All accounting in different subledger applications is subject to the rules defined in this accounting method.

In 11i, as mentioned earlier, the only way to choose accounting method we chose is AR and AP system options setup (Cash Vs Accrual). We used start in GL setting up the Set of books and then define the organization information like Legal Entity and Operating units and so on. And then define these accounting methods for each operating unit. As you can see operations and accounting are so closely meshed with each other. But in R12 it is not the same. In this release it is now configurable in Subledger Accounting setups taking this away from system options of individual products.

Demystifying subledger accounting setups

Out of the box, Oracle seeds accounting rules for all applications. If you are satisfied with the Oracle’s seeded rules, there is no need to change any setup and you can use those existing rules (Accounting Method for Accrual is Standard Accrual and for Cash is Standard Cash). This screenshot here shows you the difference between the Accrual Basis of accounting and Cash Basis of Accounting. As you can see here, per rules, there is no accounting created when invoice is created under cash basis (no revenue is recognized until cash is received) but accounting is created when cash is realized. Invoice is accounted as soon it is completed under Accrual Method. This is configurable here where as in 11i we did not have a choice!.

If you choose this accounting method, accounting works exactly the way it works in previous releases.

Subledger Accounting as a gatekeeper of Reconciliation

       R11i Transfer to GL                                                                   R12 Transfer to GL

Starting R12 all accounting entries are generated and passed through subledger accounting application instead of directly going to GL. Hence reconciliation is already done between source to Subledger Accounting and Subledger Accounting to GL, reducing huge amount of time spent on reconciliation. Since these entries have to flow through the subledger accounting application, there is a need to map the source application accounting entries to subledger accounting. That is key for the setups.

Mapping a transaction to Subledger Accounting Setup

                                        AR Invoice Accounting

Let us take a simple example. Whenever you create an AR Invoice following accounting takes place.  

                             Invoice Accounting in AR

Taking a step back and thinking through, this transaction is happening in AR for the Invoice Creation event….                                             

                                            Subledger Accounting Setup Model

Now we map the source (AR Invoices) to Subledger Accounting as shown here. So to conclude

Journal Line Types are nothing but accounting line types (Receivable or Revenue).

Event Classes identify a transaction type (Invoice Vs Credit Memo).

These two are assembled using Accounting Derivation Rules and Sources.

All these together make up Application Accounting Definition for Receivables. 

Different Application Accounting Definitions together make up a Subledger Accounting Method.

This method can be attached to one or more Ledgers.