About Us Competencies Services Downloads
Whitepapers Featured Business Issue Newsletters


Oracle EBS - Education Series 2
Sub Ledger Accounting (SLA)

What is Sub Ledger Accounting?

“SLA is a robust, centralized accounting engine and a repository that facilitates true global accounting". R12 Sub Ledger Accounting is designed to offer global visibility into enterprise-wide accounting information with a single, global accounting repository and with user driven reporting.

By introducing SLA in EBS, Oracle has separated Accounting from Transaction.

It is to be noted that SLA is complementary to the existing account generation tools like Auto accounting or Work flow accounting generator. SLA streamlines these processes and facilitates management of accounting rules in a global manner.

Key Features of SLA:

  • Enables a single business transaction (Business Event as per new terminology) to create multiple
    journals using multiple accounting representations across multiple currencies
  • SLA serves as an intermediate layer between the sub-ledger products (AP, AR. Projects, FA etc) and the
    Oracle GL
  • SLA allows you to define multiple accounting rules (US GAAP, IFRS etc) for a single legal entity and apply
    them in different ledgers
  • SLA offers the flexibility to create accounting in draft or final mode

Some Terminologies in SLA:

Events (Business Transaction)
Event Entities (Sub Ledger type, usually 1 for AP, AR and so on)
Event Types (AP Invoice Validation, FA Depreciation, PO Creation)
Event Class (Payables Invoice, Assets Addition, Purchase Requisition)
Accounting Definition Model Account Derivation Rules
Application Accounting Definition
Accounting Methods Builder
Journal Line Definitions
Journal Line Types
Accounting Representation Combination of Sub Ledger Accounting Method and Ledger




Key Considerations regarding SLA during Upgrade

Before deciding on the upgrade path, it is imperative that the accounting/finance group understand the implications of this new feature. The amount of historical data to be migrated requires to be evaluated and signed off by the accounting group since the overall upgrade plan will be significantly impacted by this decision. Some of the some critical understanding areas are:

  • SLA is not a new module and is a “service” provided in Oracle applications. There are no SLA responsibilities and users do not login to SLA
  • Setting up of Accounting Methods is a critical setup. Users can copy seeded accounting methods and change wherever required instead of defining from the scratch. User Type "Oracle" represents seeded accounting methods and "User" represents user created accounting methods
  • AAD (Accounting Application Definition) loader enables export and import of accounting definitions and journal entry setups. Users can test the Accounting definitions in test instance and export to production instance once duly tested.
  • Extent of historical data to be migrated to SLA tables (by default Oracle upgrades six month of data)
  • Customization impact, specifically reconciliation reports between sub-ledgers and main ledgers get impacted in a major way and may require complete redesign.

A peep into the Technical Side of SLA:

Over 2000 objects have been added to EBS database due to SLA. It is evident that the core data model has undergone a change in the R12 Architecture. You may need to do a detailed analysis to understand the extent of impact SLA has had on the overall architecture and on the customizations done in your current EBS instance.

You can run this simple query to appreciate the pervasiveness of this new feature:

select object_type, count(*)
from dba_objects
where object_namelike '%XLA%'
group by object_type

The following explains the steps in SLA from a technical standpoint:


Step 1 Registering Sub-ledger Transactions in SLA:

After validating / approving / costing the transaction in the respective modules, the sub ledger calls “SLA API” to create a reference of the validated transaction in SLA. This reference is known as EVENT. Events are created by calling the public API “xla_events_pub_pkg.create_events” provided by SLA. It is up to the sub ledgers on how to call the API and each module / transactions have different triggers that call this API

While calling the SLA API, Oracle passes a unique id and an event class associated with it. Unique ID can be an invoice id or an expenditure_item_id etc. As soon as the sub ledger generates an event in SLA, SLA returns a unique event_id. This event_id will then act as a reference to all the accounting entries generated by the SLA and this unique id gets associated with the transaction entity, event class and event type to create a distinct record in the SLA Table. Once an event is successfully created in SLA, it means the transaction is registered in SLA for accounting


Step 2 Creation of Accounting Lines:

After step 1 above, we can create accounting entries by running executable XDODTEXE. This executable is provided by SLA and is used by all the sub ledgers with different concurrent program names. Around 160 concurrent programs use the same executable. This executable does the following:

a. Gather information from base tables in sub ledgers.
b. Derive the accounting attributes based on the data fetched from sub ledgers.
c. Derive code combination id based on the business rules.
d. Create journal lines based on the seeded Journal definition.
e. Create lines in XLA_AE_HEADERS and XLA_AE_LINES


Benefits of SLA:

SSLA offers a number of benefits like cost saving, flexibility in reporting, global model and so on.

For example with SLA:
The expense account for a payables invoice can be derived based on any attribute of that invoice including item, item type, or PO distribution. Similarly, the liability account can be based on the supplier, or even broken into multiple liability accounts by supplier site. You can even define conditional rules such as recording customer invoices to different receivables accounts based on the credit risk of a customer.

SLA provides the ability to define accounting rules that derive an entire account combination from various transaction attributes, or you can define separate rules to derive individual segment values of an account combination, or anything in between. One rule can be to derive an entire account combination and then additional rules to override one or more of the segment values ad so on. The permutations are countless.


How Thirdware can help?

SLA is a major change in EBS R12 and requires thorough impact analysis before you plan for an R12 Upgrade. Thirdware does this analysis as part of its R12 readiness assessment package to help companies appreciate the impact of SLA to their current business process and workflow models and more importantly its effect on customizations around Oracle.

Find a Thirdware location nearest to you
Locate Us

Disclaimer    |    Site Map    |    Bookmark and Share
2015 Thirdware Solution Ltd. All Rights Reserved.