
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. |