Oracle eBusiness Release 12 introduces the concept of Subledger Accounting (SLA). Subledger Accounting provides an interim step to translate, and derive accounting logic, prior to recording GL entries. SLA is designed to provide an extremely flexible solution to facilitate the accounting needs of a corporation. Whilst SLA continues to be a buzz word, in the Oracle community, it’s regarded with both awe, and disdain.

In the old days, Oracle provided Auto-Accounting, and Account Generator as the options available for deriving accounts. Both were somewhat limited. Any accounting logic outside of a set of predefined rules required customization. Splitting a single accounting entry into multiple accounts required major customizations.

The transition from the individual sub-ledgers to the General Ledger was a single step process. Accounting entries were derived/recorded in the sub ledger, once the entries where completed, they were posted to the General Ledger.

The major concepts within SLA are :

• Rule Based Accounting Engine : With the introduction of SLA, an additional layer has been created. Accounting entries were derived/recorded in the sub ledger, once the entries where completed, they are posted to SLA. During the posting to SLA, the SLA engine derives the accounting entries based on the rules established within SLA. The SLA engine has the ability to derive each segment of the chart of account from any defined location with the Enterprise. The rules can be defined based on pre-populated data, or customized using PL*SQL hooks to the database.
• Multiple Representation : A Single accounting entry can be represented for multiple reporting requirement. Organizations are able to have a primary ledger to represent primary accounting requirements such as GAAP. Accounting representations can be created to represent additional/secondary reporting requirement such as IFRS. Each secondary ledger can have a different subledger accounting method.
• Straight Through accounting processing : Subledger Journal entries can be posted to the GL directly form the transactions screen

SLA whilst on the surface seems to be the holy grail for managing accounting processes, it does hold some drawbacks:

• Visibility of Accounts : Accounting entries generated via the rules engine are only visible in the SLA. The data in the sub ledgers (INV, RA, AP etc.) may not represent the same set of accounts as within SLA
• Debugging : Due to the flexibility of the rules engine, debugging accounting derivations can be a complex and involved process. The rules engine provides both configuration, and SQL based derivation rules. Requiring a combination of functional, and technical knowledge to debug issues.
• Adoption : Industry knowledge of SLA is still very limited, outside of the marketing and sales material. Educational, and professional services knowledge of SLA is sparse, making deployment of SLA a risk for many organizations.

As knowledge of SLA expands, and the continuing changes in accounting practices force more and more corporations to abide by Nations, and International accounting practice, SLA will prove a valuable asset. Oracle is well poised with SLA to meet the future reporting needs.

Deferred COGS is a new feature introduced in Release 12. The basic fundamental behind the enhancement is that the COGS is now directly matched to the Revenue.

Prior to this enhancement, the value of goods shipped from inventory were expensed to COGS upon ship confirm, despite the fact that revenue may not yet have been earned on that shipment. With this enhancement, the value of goods shipped from inventory will be put in a Deferred COGS account. As percentages of Revenue are recognized, a matching percentage of the value of goods shipped from inventory will be moved from the Deferred COGS account to the COGS account, thus synchronizing the recognition of revenue and COGS in accordance with the recommendations of generally accepted accounting principles.

Whist this helps solve some key accounting issues, There are some key issues one needs to be aware of:

• Currently Deferred COGS accounting cannot be turned off in release 12.

• The activity of recording COGS recognition is now a multi-step process

• Run AR Revenue Recognition, and Submit Accounting Processes

• Run a set of concurrent processes in Cost Manager to record Sales Order and revenue recognition transactions and to create and cost COGS recognition transactions. These COGS recognition transactions adjust deferred and earned COGS in an amount that synchronizes the % of earned COGS to earned revenue on Sales Order shipment lines.

• Record Order Management Transactions: records new sales order transaction activity such as shipments and RMA returns in Oracle Order Management.

• Collect Revenue Recognition Information: determines the percentage of recognized or earned revenue related to invoiced sales order shipment lines in Oracle Receivables.

• Generate COGS Recognition Events: creates and costs COGS recognition events for new sales order shipments/returns and changes in revenue recognition and credits for invoiced sales order shipment lines.

The end result of these activities is a series of COGS Recognition Material Distributions. However these distributions will not be visible on the Material Transaction screen, unless the ‘Include Logical Transaction’ checkbox is checked.