Subledger Accounting

Why SLA?
Oracle Sub Ledger accounting (SLA) is accounting hub in Oracle Application
Release 12 (R12). It is used to derive all attributes required to account a transaction
in Oracle General Ledger. In R12, SLA is used to derive the very basic accounting
attributes like entered amount, accounted amount, Date, Currency code etc and the
complex attributes like Ledger, Code Combination ID, Periods etc. After deriving
these accounting attributes the transactions are then interfaced to GL from SLA.
Thus in R12 no sub ledgers (AP, PO, PA etc) interfaces the transactions directly to
GL, but all the transactions are interfaced to GL in following 2 steps:
1. Sub ledgers interface the data to SLA.
2. SLA derives the accounting information and interfaces the data to GL.
SLA gives the flexibility to manage the entire accounting rule at one place, which
acts as a single source of truth for GL.
Note: There is no separate responsibility to access SLA setup or the view the
transactions generated by SLA. Rather we can access SLA setup and review
accounted transactions with extended menus attached to each sub ledger module.
Menu to access the SLA accounted transactions

Menu to access the SLA Setup

what exactly does SLA do?

SLA is a module which now sits between the SubLedgers like AP/AR etc and the
General Ledger. Have a look at this diagram below. As you will notice, SLA can
act as a mediator between the subledgers and Oracle General Ledger.

Before we progress, some terminologies of R12 must be revisited. In 11i we had

set of books, and in R12 we call them Ledgers. Likewise in R12 we also have
secondary ledgers and reporting ledgers. Hence from 11i perspective think of
Ledger as Set of Books. As for Subledger, a Subledger is nothing but a module like
AP/AR/PO/Inventory etc.
In the diagram below, the second scenario is explained whereby let's say that
payables module generates a charge account segment combination for an invoice
distribution line as A.B.C.D. In such case, if SLA module is not customized, then
the very same A.B.C.D combination will be passed to Oracle General Ledger via
the SLA. And before you wonder... Yes, SLA module has its own set of tables to
capture these accounting entries.

Please see the image below.

In the image above, SLA passes to GL whatever value is fed by the Subledger, in
this case A.B.C.D
There are cases where SLA module can alter or massage the CCID or code
combination that is generated in Subledger before transferring the same to Oracle
General Leger. This scenario is explained whereby let's say that payables module
generates a charge account segment combination for an invoice distribution line as
A.B.C.D. In such case, if SLA module is customized, then the A.B.C.D code
combination of Payables can be passed to Oracle General Ledger via the SLA as
A.B1.C1.D instead.

The most important application however of the SLA is its ability to create shadow
journals that contain different values or differing credit/debit entries for the
transactions. This is the main reason why SLA module was invented/designed. Let
us take an example. For company "Apps2Fusion UK", it might have operations in
France, which is "Apps2Fusion France". With UK being the parent company, the
French company has to do accounting journals in formats that can be reported as
per French legislation and also as per UK legislation. For example, in France an
inventory item is accounted as expense, whereas in UK the inventory item is
accounted as an asset. In the example below, A.B.C.D is never passed to the GL.
Instead to GL A.B1.C1.D is passed to the Primary Ledger FRANCE and
A2.B2.C.D is passed to the Secondary Ledger UK. The picture below shows the
role that SLA plays in such scenario.

Therefore in this article you have learnt the different usages of Subledger
accounting.
How does SLA works?
1.

Register sub ledger transactions in SLA.

After validating / approving / costing the transaction in the respective
module, 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. For example Oracle
Projects call this API from concurrent program PRC: Generate Cost
Accounting Events and Oracle Payables calls this API while user creates
accounting for the Invoice.

While calling xla_events_pub_pkg.create_events, oracle passes a unique id

and event class (Will discuss in next step). Unique ID can be an invoice id or
a po_distribution id or an expenditure_item_id etc. As soon as the sub ledger
generates event in SLA, SLA returns unique event_id. This event_id will
then act as a reference to all the accounting entries generated by the SLA.
Once event is successfully created in SLA, means that the transaction is
registered in SLA for accounting.
Taking the example of Oracle Projects in 11i where after costing the
transaction user need to run the PRC: Interface Cost to General Ledger
followed by Journal Import followed by PRC: Tieback process. But in
R12 user only need to run PRC: Generate Cost Accounting Events which
will register events in SLA and thereafter SLA will take care of accounting
the transaction and interfacing it to GL. There is no tieback process in R12,
as there is one to one reference of event id between SLA and sub ledger
tables.
2. How does SLA understand whether unique id is invoice id or a
po_distribution id or an expenditure_item_id as SLA uses same table to
store all the identifier?
In step 1 we discussed that while creating the event we also need to pass
event class. This event class is used to distinguish between the types of
transaction passed for processing. To understand this better we will go thru
the seeded oracle information.
Navigation:
Responsibility: Projects, Vision Services (USA)
Menu: Setup > Subledger Accounting > Accounting Methods Builder >
Events > Event Model

This screen shows the hierarchical structure of different transactions that can
be interfaced to SLA. Because the above screen shot is from Oracle Projects
responsibility thus it shows only the projects related transactions. In the
entity screen we see only those transactions that can be interfaced to the GL,
thats why we do not see Invoice as one of the entity as Invoices are not
directly interfaced to GL from PA but they are routed thru AR.
Identifiers are the unique ID that is passed to SLA from sub ledgers. Per the
screenshot Oracle is passing expenditure_Item_id for entity
EXPENDITURE. Identifier Column field under Identifier window tells
what column in SLA table should store expenditure_item_id. The identifier
columns that can be used are SOURCE_ID_INT_1 to 4,

SOURCE_ID_DATE_1 to 4, SOURCE_ID_CHAR_1 to 4 these values and

columns are present in table XLA_TRANSACTION_ENTITIES.
Event Class window displays the different kind of expenditure transactions
that can be interfaced to GL. This level of hierarchy is known as Event class,
which is further classified into Event Types. In PA we have different event
types like Labor Cost, Misc Cost, Usage Cost, Supplier Cost etc. Further we
could classify Supplier Cost as Expense Report and Invoices as Oracle
Projects can interfaces only these 2 transactions from AP.
3. Based on the identifiers and event class, how SLA creates accounting
lines?
After registering the event in SLA, 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 are uses the same executable for example
in Projects it is used with name PRC: Create Accounting. 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.

Entities - Event Class - Event Types

In this section you understand some of the basics fabrics/terminology used in SLA,
i.e. Entities, Event Classes and Event Types. It is important for you to understand
the variables within SLA engine which influence whether an accounting entry
needs to be generated for a specific event within subledger like Payables or
Receivables. For example in Procurement, there may be a need to generate
accounting whenever a Purchase Order is encumbered. In case of SLA, the activity
of "Encumbrance" against a Purchase Order is known as Event Type.
Likewise when a Payables Invoice is Validated, then you may want to create an
accounting entry. In this case the "Invoice Validation" is an "Event Type". And
your accounting rules for Invoice Validation will be attached against this specific
"Event Type".
For Payables, an INVOICE transaction and a PAYMENT transactions are known
as Entities within SLA.
Entities can be subdivided into various "Event Classes", for example Credit Memo,
Debit Memo, Expense Reports, Invoices etc. Further to this, against the Event
classes we define Event Types, for example, whenever your Invoice is validated or
cancelled or adjusted, you may want some specific accounts in the General Ledger
to be impacted. Event types are therefore the types/list of events against
transactions which you wish to account for in General Ledger.
This is explained in the diagram below.

Each entity is identified by unique identifier or primary key from the underlying

tables.

Journal Line Definition

The Journal Line Definition "defines" how the entire journal is built. To create any
journal, one of the key things is to get the CCID or the code combination of
segments. SLA needs to know where this CCID will be coming from. You also
need to know whether this CCID will be debit or this CCID will go into credit.
Therefore you not just require the CCID, but you also need to decide whether a

specific CCID will be debited or credited. In SLA, the "Journal Line Type" will
specify whether the accounting entry is credit or debit. Also, you can then "attach
something called an ADR to this Journal Line Type". The ADR returns the final
code combination. Therefore Journal Line type will leverage the JLT+ADR to
know which CCID is crediting and which CCID is debiting in the journal.

For each and every application there is a combination of event class and event
type. Depending upon the combination of event class and event type the
accounting gets triggered. The standard SLA out of the box from Oracle meets
your requirement by 90%. For example you can fetch the standard accounting from
payables or receivables options. However where these standard seeded accounting
do not suffice, you can go and modify SLA to meet your business needs.
There is something called as Journal Entry Description. When a transaction is
transferred as a journal, then every journal has credit/debit and description. The
journal has description at header and also at line level. The JED allows you to
generate the description of the Journal at both header and line level. For example
you may want Customer Name or Customer Number in the journal description for
a journal that is initiated from Oracle Receivables module. Using JED in SLA you
can build header or line level descriptions.
The image below describes the end result journal that is produced by SLA

In JLT Journal Line Type, you can specify whether the entry is for credit or debit
side. The Journal Line Type also provides options to do accounting for Gain/Loss
of Foreign currency transactions. Further to that you can specify if SLA should
merge the journal lines that have same CCID.

ADR - We specify how the account combination must be generated. We tell the
system how we want the CCID should be built and transferred to the general
ledger. You can either transfer the standard account as calculated within
Subledger(AP or AR or PA etc) or the account generated from Subledger can be
modified or replaced via ADR configuration within SLA.

Further to this, when defining ADR, you can specify the conditions under which a
specific segment or CCID is returned. These conditions are like IF Conditions.
It is good to remember that the "Journal Line Definition=JED+JLT+ADR"
This is visible from the screenshot as shown below

You will notice that two "Journal Line Types" have been attached to this Journal
Line Definition. The first journal line type assignment creates a credit line in the
journal and the second journal line type assignment creates a debit line in the
journal.
By now you would have understood the significance of Journal Line Definition.
However you might be wondering how this Journal Line Definition gets associated
with a Subledger transaction. For example, how does Oracle E-Business Suite
decide which specific Journal Line Definition should be used when a specific event
takes place against an invoice in Oracle Payables. In other words, how will SLA
decide how the Journal will be constructed when an invoice is validated within
Payables. We will learn this via AAD in next part of the article using Application
Accounting Definitions.
As we have seen in the Part 4 of SLA, the Application Accounting definition is
used to decide two things
a. When a specific event within Subledger example Payables or Receivables
becomes eligible for Accounting
b. How the journal is constructed.
However, each Primary Ledger [11i equivalent of primary set of book] and also
each secondary ledger should be able to generate Journals as per their respective
legislator requirements for all the modules implemented. This is where "Subledger
Accounting Method" [SLAM] comes into the play. If you recollect from previous
article, Application Accounting Definition is connected to only one module like
Payables or Receivables etc. However a Ledger[11i SOB equivalent] needs
accounting entries to be processed across many modules. Hence SLAM provides
an umbrella to join accounting entries from various modules so that they can be
channelled through to Oracle General Ledger. In other words a SLAM is a

collection of accounting definitions for various modules in Oracle Apps. A SLAM

is then attached to the Ledger[11i equivalent of Set Of Books].
Therefore

the

flow

of

accounting

entries

appears

as

shown

below

The

flow

represented

in

simple

equation

appears

as

below

Ledger Defined in GL-->SLAM-->AAD--> [Event Class and Event Type]->Liability Lines-->[JED+JLT+ADR]

Ledger Defined in GL-->SLAM-->AAD--> [Event Class and Event Type]->Expense Lines-->[JED+JLT+ADR]
In order to assign the SLAM to a ledger, go to the General Ledger Super User
responsibility and click on menu as shown below.

Click on update against the ledger

Attach the SLAM to this ledger

You can also modify the SLA accounting options using the two screenshots as
shown below

Overall SLA Diagram

The overall flow of the SLA can therefore be depicted as shown in image below.

Overall, when you create new definitions in SLA, you can follow the bottom up
model. The parallel flow on top, as shown in image below is to ensure both a
Credit and Debit line gets created for a Journal.

Creating Journal Line Definition

In this section we will create a Journal Line Definition. You will basically apply
the steps learnt thus far into practical implementation.
However to create a Journal Line Definition, we need to create the following
1. Journal Entry Description for journal line description
2. Journal Line Type to mainly define credit or debit
3. Account Derivation Rules for CCID used in journal line
Therefore typically, two set of JED,JLT and ADRs are required, with one set each
for Credit line, and the other set for the debit line.

In this article, we will create these three components.

Go to a subledger like Payables and within the SLA menu as shown below, you
can open the Journal Enty Description screen. Click on New to create a new JED.

Create a new Journal Entry Description named ANIL_JED. We will use this for
generating the Journal Line Description for both the credit and the debit lines.

The journal line description can be constructed by clicking on Details button. The
description of the journal line can be a static text or dynamic text based on
database sources within SLA or the combination of the two.

Here we are using the Supplier Name to construct the journal line description.

In addition to the dynamic journal line text, SLA allows you to put conditions.
For example IF CONDITION1=TRUE, then Journal Line Description should be
abcd ELSE IF CONDITION2=TRUE, then Journal Line Description should be
defg. Click on condition button to define the condition

After defining the Journal Entry description, now we can create Journal Line Type
named ANIL_JLT_CREDIT for the credit line of the journal.

Specify the Transfer to GL in Summary or Detail mode. Also specify Merge, as

explain in image below

Use the Payables setup option as source to build condition for JLT

In this example, we want to build a condition for Journal Line Type eligibility
depending upon whether in the Payables Options Screen has Automatic Offset
Method is set to None or Balancing or Account. In the above condition, we have
placed an OR condition.

You can for example also build a condition based on Invoice Distribution type as
shown below.

Next we need to define the Account Derivation Rule

Here we are creating an account derivation rule for the credit line.

An ADR can either return a full CCID or a specific segment. The values can be
sourced either statically or from existing seeded dynamic sources in SLA. These
seeded sources are mapped to database tables.

We are stating that this specific ADR named ANIL_LIABILITY_ADR will return
a constant value in company segment

In the above image you will see that the value for Company segment can be
derived from the corresponding value set.

As below, it is also possible for the specific ADR to return a full segment
combination. In fact you can specify conditions within an ADR. When
CONDITION1=TRUE then segment combonation a.b.c.d is returned or when
CONDITION2=TRUE then d.e.f.g combination is returned for your account.

For the debit side, we are saying that the Account segment must always be 7450

The conditions can be defined. But conditions as evaluated as per the priority.

Finally we create a Journal Line Definition.

Here

everything

hangs

together,

JLTJLD,ADR=Journal

Line

Defnition

As shown below, we are saying that the CCID for the Credit Line of the journal
will be calculated from ANIL_LIABILITY_ADR

And the CCID for the debit line will be calculated by the CCID value in Invoice
Distribution line, with the specific segment from Account segment being replaced
as per ANIL_EXPENSE_ADR.

For

example,

if

the CCID in AP_INVOICE_DISTRIBUTION

equates

A.B.C.D.E.F then your journal line debit entry will be A.B.7450.D.E.F

Creating Application Accounting Definition - AAD

In the previous section of this SLA, you have learnt creation of the Journal Line
Definition. Now it is time to create AAD, which is "Application Accounting
Definition".
The purpose of AAD in SLA is to dictate which "Journal Line Definition" must be
used when a specific event takes place against a specific type of transaction in a
specific module like Payables or Receivables. If you recollect, the "Journal Line
Definition" definition creates a Credit Line and the Debit Line of a Journal.
Oracle ships out of the box an AAD for every simply module/application that uses
SLA. Hence for each application like AP,AR,PA,PO etc there will exist an existing
AAD in the Subledger Modules. However, for this example we will create a new
AAD for Payables.
In the previous article you created a Journal Line Definition that is responsible for
constructing a Journal. However, in AAD screen you will specify when the Journal
Line Definition will be used. In this case, as per the image below, we are stating
that journal line definition ANIL_JLD should be used for creating journal
whenever any event occurs against an Invoice in Payables.

You can also click on "Header Assignment" button in AAD to attached "Journal
Entry Description" [JED] which dictates how the Journal Header description will
be constructed. If you recollect, in Journal Entry Description, we concatenate static
text and dynamic content from SLA Sources[mapped to DB columns or pl/sql

functions] so as to construct a description for Journal Line or Journal header.

In this article we have seen that AAD is created for each module. However, in any
implementation there is a need to perform accounting for all the modules.
"APPS2FUSION UK" might be running Payables and Receivables and also Project
Accounting. Hence we need to create a SLAM-Subledger Accounting Method.

Using AAD we specify the Journal creation rules per module. In SLAM we specify
how the Journals must be built for the entire organization "APPS2FUSION UK"
across Payables and Receivables and Project Accounting. The company
"APPS2FUSION UK" will have a legal entity in UK, and hence the SLAM will be
attached to the UK Legal Entity.
Create Subledger Accounting Method
In previous section we have seen that in SLA, the "Application Accounting
Definition" is created for each module in E-Business Suite. However, in any
implementation there is a need to perform accounting across various different
modules. For example, a company named "APPS2FUSION UK" might be running
Payables and Receivables and also Project Accounting. Hence we need to create a
SLAM [Subledger Accounting Method] that will take care of generating the
Accounting journal lines for each of the module. Hence a SLAM is nothing but a
grouping of all the AAD's possibly for a given chart of account.
Using AAD we specify the Journal creation rules per module. In SLAM we specify
the applications/modules for which the Journals must be built for the entire
organization such as "APPS2FUSION UK" across Payables and Receivables and
Project Accounting. The decision of whether the journal must be created is
delegated to the AAD. As for how the journal is constructed and how the accounts
are derived is delegated to the Journal Line Definition.
The company such as "APPS2FUSION UK" will have a legal entity in UK, and
hence the SLAM will be attached to the UK Legal Entity.
In the image below we are creating a SLAM named ANIL_SLAM, and attaching
the AAD named ANIL_PAYABLES. This is a simplistic example, because in

reality you will have the AAD's of other applications like Receivables , Project
Accounting, Fixed Assets etc attached to the SLAM as well.

In the above image, click on Accounting Setups, and here you can attach

the SLAM to a Ledger. To remind you, in R12, the Ledger is equivalent

of set of books in 11i.

Testing and explaination of SLA Config

In this article, we will test the configuration to see the results of the configuration
performed. We will also explain the results of the test.

Our SLA setup was done for Payables, hence we will create an Invoice in Payables
and check the accounting entries to reconcile those against our SLA setup.
If you recollect, we created an AAD named ANIL_PAYBLES which is attached to
Oracle Payables module. This AAD will invoke JLD named ANIL_JLD to build
the journal lines when an event takes place against the Payables invoice.
In the image below we are creating an Invoice from Payables responsibility and
ensuring its invoice line distribution account is 01-110-6100-0000-000.
Next we click on Actions button and validate the invoice and create accounting
entries.

Now check the accounting generated by clicking on menu title Reports||View

Accounting as shown in the image below.

You will notice that the Debit entry of 1000 is charged to 01-110-7450-0000-000
instead of being charged to 01-110-6100-0000-000 in the Invoice Distribution Line
of Payables. Please note that the third segments value of 6100 from Invoice
Distribution has been replaced by 7450 from ADR named ANIL_EXPENSE_ADR
as shown below.
The complete logic is described after this image.

Now, let us revisit how the credit line in the journal has been built. Typically Code
Combination for the credit/liability accounting entry of the invoice line is picked
from Payables Options setup of the operating unit. However in this case, in SLA
we have hard coded the credit account to be 01.000.2220.0000.000. This was done
by defining ANIL_LIABILIY_ADR as shown below. In this case the ADR returns
the complete CCID because the Output Type radio button is set to Flexfield.

Hence, the SLA has generated the same Credit entry CCID for the invoice, as
shown in image below

Needless to say that the ANIL_LIABILITY_ADR was attached to the Journal Line
Type=ANIL_JLT_CREDIT.

Before we see the steps for customization of SLA, let us first do some
questions and answers
Question - I can customize the account generator in Procurement and Fixed
Assets. Do I really ever need to customize Subledger Accounting in such cases?
Answer- The pre-configured SLA by Oracle will use the accounts generated in
respective modules as the source. The seeded ADR's will in most cases return the
very same accounts that are generated in the respective modules. Effectively
"garbage in garbage out", or you can say "quality of the account that goes into
SLA, and the same quality accounts are then sent to General Ledger". The message
from seeded SLA in most cases is What you feed to SLA will also be fed into the
Oracle General Ledger. Therefore if you have already customized the account
generation workflow in the respective module then you do not require
customization in SLA. In fact, the customizations on the seeded SLA
configurations must be kept to bare minimum. Although SLA provides you with
ability to override accounting definition, however the main reason for creation of
SLA was to implement multiple shadow accountings against ledgers.
Question - If all the respective modules can generate accounting properly then
why is SLA really needed?
Answer - Well, the main reason behind creation of SLA itself was to create
shadow journals for secondary ledger. Please see the Part 1 in this series of articles.
Now let us take the example for customization of an existing SLA definition preseeded by Oracle in R12. In this example, a SLAM named
STANDARD_ACCRUAL is attached to the Ledger [Set Of Book equivalent of 11i
]. As you will notice from the image below, many modules such as Leasing, Loans,
Cash Management, Payables etc are attached to this SLAM. However we are
interested in modifying just the Payables piece of this SLAM. Create a copy of this
SLAM as shown in the image below. We will create a SLAM named
ANIL_SLAM__STANDARD_ACCRUAL which happens to be the exact copy of
SLAM named STANDARD_ACCRUAL.

Now create new entry for Payables within the copied SLAM, i.e. new SLAM will
be " ANIL_SLAM__STANDARD_ACCRUAL"

Now you have created a new SLAM. In this SLAM, end date the AAD assignment
of Payables and add a new entry for Payables. Note that we still have AAD named
"Accrual Basis" attached. However after we copy the "Accrual Basis" into a

custom AAD, we will then return to this screen in order to replace "Accrual Basis"
by custom AAD. Click on "Application Accounting Definition" button.

Now, click on copy, and this time we will copy the AAD definition named
Accrual Basis to create a new AAD named ANIL_STD_PAYABLES_STD.

The new AAD will be called ANIL_STD_PAYABLES_STD as shown below.

Click on button labelled Done to complete the Copy operation for the AAD.

Now this new AAD has been created. Before we customize this AAD, we need to
ensure that this AAD has been attached to the custom SLAM that we created in
Step 1 of this article.

Now, back to the SLAM screen, for the custom SLAM, for Payables AAD
assignment record, we attach the custom AAD to Payables. Please note that the
Payables entry that is attached to custom AAD named Accrual Basis has now
been end dated, as shown in image below.

Now go back to AAD, by clicking on Application Accounting Definition button as

per the image above.
Follow the instructions as per images below

Now copy the Journal Line Definition itself. The image below shows how the
custom/copied journal line definition will be modified. Our idea here is to attach a
custom ADR for the generation of an account.

The

name

of

the

copied

JLD

will

appear

as

below.

Attach the custom ADR as shown below

And now attach your custom Journal Line Definition to the custom AAD.

This completes the cycle for customization of the pre-seeded SLA configuration.