The goal of Subledger Accounting is to generate journal entries for transactions that occur in subledgers. For users integrating subledger accounting into their applications, it is critical to have a clear and common definition of a subledger journal entry. A common definition ensures the validity of all journal entries generated by Subledger Accounting.
This chapter provides detailed information on the elements that make up a subledger journal entry and the validations enforced by Subledger Accounting. Where applicable, information is also provided on the default values stored in subledger accounting tables.
A valid subledger journal entry must satisfy all the rules and validations listed below. If any of these rules and validations are not applied successfully, the journal entry has an invalid status.
The subledger journal entry must have one header.
Actual and encumbrance journal entries must have at least two journal entry lines.
Actual and encumbrance journal entries must be balanced in both entered and ledger currencies. A journal entry need not be balanced if it is a STAT currency entry.
In addition, actual and encumbrance entries must be balanced by balancing segment.
Encumbrance journal entries can only be created for ledgers that are enabled for encumbrance accounting.
The subledger journal entry must have valid monetary amounts.
The actual journal entry must be created in an open or future open GL period.
Similarly, a budget journal entry must be created in an open budget year and an encumbrance journal entry created in an open encumbrance year.
All the lines on a subledger journal entry must have valid accounts.
Budget journal entries are not created for reporting currencies and secondary ledgers.
Header information for subledger journal entries is stored in the XLA_AE_HEADERS table.
For information on the XLA_AE_HEADERS table, see the Oracle Subledger Accounting eTRM.
This section provides detailed information on the validation rules for all subledger journal entry header attributes. Where applicable, the rules also describe whether a journal entry header is created if the validation fails and what values are stored in case of errors.
The header identifier uniquely identifies the subledger journal entry header. A unique header identifier is generated using the sequence XLA_AE_HEADERS_S.
A subledger journal entry belongs to one and only one subledger application. The application identifier is the standard identifier for each Oracle e-Business Suite application or custom application.
A subledger journal entry belongs to one and only one ledger. The ledger identifier is the standard identifier assigned to the ledger by the Accounting Setup Manager (ASM).
The transaction entity identifier identifies the source transaction associated with a subledger journal entry. It is always populated.
The following rule applies:
It exists in the XLA_TRANSACTION_ENTITIES table.
A subledger journal entry is attached to one and only one accounting event. However, an accounting event can be used to generate multiple subledger journal entries when using multiple accounting representations.
The event identifier (EVENT_ID) is the standard identifier for each event in Subledger Accounting. The event type code (EVENT_TYPE_CODE) is also stored in the journal entry header.
The following rules apply:
A journal entry header is not be created if an event type is not enabled.
A manual subledger journal entry has an event type of Manual automatically assigned by Subledger Accounting.
The GL date determines the accounting period (PERIOD_NAME) of the subledger journal entry and when the entry appears in fiscal reports and queries.
The following rules apply:
For actual journal entries, the GL date must be in an open or future enterable GL period.
For an encumbrance journal entry, the GL date must be in an open encumbrance year.
For a budget journal entry, the GL date must in an open budget year.
An entry is marked Invalid if it fails period validations. The Accounting Program continues to create lines even if the journal entry fails period validations.
For a multiperiod journal entry, the GL date may fall in a never opened period. In this case, the Transfer to GL process does not transfer the journal entry to General Ledger until the GL period status is changed to either Open or Future Enterable.
The GL date has no time component. It is not subject to considerations related to timezone differences.
The reference date can be used as a basis for the reporting sequence. It is an optional attribute. When a subledger journal entry is created and completed, the reference date must belong to an open or future open period in General Ledger.
The following rules apply:
When a subledger journal entry is completed, the reference date must be in an open or future open accounting period.
Reference date is only stored for actual manual journal entries.
The reference date has no time component. It is not subject to considerations related to timezone differences.
The balance type of a subledger journal entry has one of the following values:
Actual
Budget
Encumbrance
The following rules apply:
For actual entries, the budget version identifier and encumbrance type identifier are null.
For budget entries, the budget version identifier is not null, and the encumbrance type identifier is null.
For encumbrance entries, the encumbrance type identifier is not null, and the budget version identifier is null.
This is the name of the General Ledger journal category.
The following rules apply:
For manual and upgrade journal entries, users must provide the journal category.
For standard and multiperiod journal entries, the journal category is derived from the category specified for an event class in the Subledger Accounting Options page of the Accounting Setups.
The GL transfer status code of the subledger journal entry has one of the following values:
Not transferred
Selected to transfer
Transferred
When a subledger journal entry is created and completed, the value of this column is Not transferred. The Transfer to GL process updates this column when the subledger journal entry is transferred to General Ledger.
A subledger journal entry can have a status of Draft, Final, Incomplete, Invalid or Invalid Related Entry.
Draft: The entry status is set to Draft when the following conditions are met:
The subledger journal entry is accounted in draft mode.
The subledger journal entry is valid.
The originating event has no errors. (All other subledger journal entries associated with the same event are valid.)
All prior events for the same document have been accounted.
Final: The entry status is set to Final when the following conditions are met:
The subledger journal entry is accounted in final mode.
The subledger journal entry is valid.
The originating event has no errors. (All other subledger journal entries associated with the same event are valid.)
All prior events for the same document have been accounted.
Incomplete: The entry status is set to Incomplete when the following condition is met:
The subledger journal entry is incomplete and subject to further changes. This status is applicable to manual and multiperiod journal entries.
Invalid: The entry status is set to Invalid when the following condition is met:
The subledger journal entry has errors.
Invalid Related Entry: The entry status is set to Invalid Related Entry when the following condition is met:
The subledger journal entry is valid, but one or more of the other subledger journal entries associated with the same accounting event are invalid.
The type of a subledger journal entry is one of the following:
Standard
Upgrade
Manual
Multiperiod
The application accounting definition type code, code and version store information about the application accounting definition used by the Accounting Program to create the journal entry.
The following rule applies to these identifiers:
They are not populated for manual, upgrade, or third party merge entries.
This is the description of the subledger journal entry header. For standard, upgrade, and third party merge journal entries, the description is always in the language of the ledger.
The following rule applies to a subledger journal entry description:
A header description is required for manual journal entries. It is optional for other journal entry types.
This is the identifier of the document sequence category used to derive the document sequence of the subledger transaction.
These are the sequence identifiers and values that correspond to a valid document sequence at the time the journal entry is created.
This is the identifier of the batch in which the subledger journal entry has been created.
The following rule applies:
This column is null for manual, third party merge, and upgrade subledger journal entries.
These are the sequence versions, identifiers, and values assigned to the completed subledger journal entry.
These are the sequence versions, identifiers, and values assigned to the subledger journal entry at period close.
This is the identifier of the budget version.
The following rules apply:
It is populated only for budget entries.
The budget must exist, it must not be frozen or inactive, and it must be associated with a ledger.
No budget subledger journal entries are created if it is created with a status or Error.
This is the identifier for the encumbrance type.
The following rules apply:
It is populated only for encumbrance entries.
The encumbrance type must exist and be enabled.
No encumbrance subledger journal entries are created if any of the above validations fail.
The funds status code of the subledger journal entry is one of the following:
Passed
Failed
In Progress
This is an optional column. The following rule applies to the funds status code:
If funds checking is enabled for a ledger, then there must be available funds for each line. If this condition is not met, the status of the subledger journal entry is set to Invalid and the funds status is set to Failed.
Users are not allowed to complete a manual subledger journal entry with a funds status Failed.
This is the identifier of the budgetary control packet in the GL_BC_PACKETS table. It is used to implement budgetary control.
The following rule applies:
It is populated only for manual journal entries.
The group identifier is used by the journal import to identify journal import batches.
The completion date is the date a valid journal entry is accounted for in final mode.
The completion date has a time component. It is subject to considerations related to timezone differences.
Line information for subledger journal entries is stored in the XLA_AE_LINES table.
For information on the XLA_AE_LINES table, see the Oracle Subledger Accounting eTRM.
This section provides detailed information on the validation rules for all subledger journal entry line attributes.
This is the identifier of the subledger journal entry header. All lines of a given subledger journal entry share the same header identifier.
This is a sequential number that identifies each line within a subledger journal entry. AE_HEADER_ID and AE_LINE_NUM constitute the unique key for a subledger journal entry line. There is a one-to-many relationship between a subledger journal entry header and subledger journal entry lines.
This is a sequential number that identifies each subledger journal entry line within a subledger journal entry. It is an updateable value when creating a manual subledger journal entry.
This is the code combination identifier that identifies the General Ledger account to which the subledger journal entry line is posted.
The following rules apply:
It must be a valid code combination. For performance reasons, the following validation is performed:
The Accounting Program checks whether the code combination exists in the table GL_CODE_COMBINATIONS. The Accounting Program assumes that compliance with General Ledger cross validation rules has been met by the base product.
Instead of deriving the account from sources in the transaction objects, the code combination can also be derived from a constant value specified in an account derivation rule. In this case, it is also assumed that no General Ledger cross validation rules are violated.
If dynamic insertion is turned on and the code combination does not exist, then a new combination is created. In this case, Subledger Accounting calls the corresponding Applications Object Library APIs, which perform all needed validations including General Ledger cross validation rules.
It must be active as of the GL date.
If disabled and a substitute account is defined in General Ledger, Subledger Accounting uses the substitute account. If the substitute account is invalid and a suspense account is defined, Subledger Accounting uses the suspense account. An error message is displayed if a valid suspense account is not available.
It must not be a summary account.
For actual and encumbrance type entries, the Allow Posting option for the account code combination must be enabled.
For budget entries, the Allow Budgeting option for the account code combination must be enabled.
When using a suspense account, the suspense option must be enabled. (Suspense accounts are derived from the ledger setup in General Ledger.)
If it is a third party control account, then the party type on subledger application registration must match the party type on the line.
If it is a third party control account, then the party type on the line must match the party type on the account.
The user must have write access to the ledger; ledger or balancing segment value; or ledger or management segment value.
If the account code combination does not exist, a -1 must be stored in the CODE_COMBINATION_ID column.
This lookup code determines how subledger journal entry lines are transferred to General Ledger. The following rules apply:
It has a value of Detail or Summary.
For standard and deferred journal entry lines, the attribute value is derived from the journal line type setup in the AMB.
For manual journal entries, it is derived from the Subledger Accounting options entered for the ledger in the ASM.
These identifiers link subledger journal entry lines with GL journal entry lines.
For entries created by Subledger Accounting, GL_SL_LINK_TABLE always has the value XJAJEL. For upgraded entries, values map to values transferred to General Ledger in Release 11i.
GL_SL_LINK_ID is null when the subledger journal entry is completed. This column is populated by the Transfer to GL process when the subledger journal entry is transferred to the General Ledger.
This lookup code indicates the accounting class for a subledger journal line. The following rules apply:
The accounting class is derived from the journal line type.
It is not populated for third party merge subledger entries.
This party identifier is associated with the subledger transaction that generates the journal entry. As some subledger products do not have third parties, the column is optional.
The following rules apply:
If party site information is provided, it must be valid.
If the party identifier is provided, it must be a valid party identifier.
If party type information is provided, then party information must also be provided and vice versa. If party type information is not provided then party information must be null and vice versa.
If the journal entry line account is a third party control account, then party information must be provided.
The party identifier is null if any of the above validations fail. The journal entry is marked as Invalid if party information is not provided when required.
This is the party site identifier of the subledger transaction associated with the event. As some subledger products do not have third parties, this column is optional.
The following rules:
If party site information is provided, then party information must also be provided.
The party site must be null if any of the other validations fail.
This column identifies the type of third party associated with the subledger transaction. Currently, there are two valid values for this field as follows:
Customers
Suppliers
Since not all subledger products implement Oracle Trading Community Architecture at the same time, third party identifiers can be identical. It is therefore necessary to identify them based on third party type code.
The following rules apply:
It must be in the currency of the transaction.
It must be either a debit or a credit, but not both.
It must be on the same side as that of the accounted amount.
It must follow the precision of the entered currency.
If the entered currency is the same as the ledger currency and the accounting class of the journal line is not Rounding, then entered and accounted amounts must be the same.
The following rules apply to the accounted amount:
It must be in the functional currency of the ledger.
It must be either a debit or a credit but not both.
It must be on the same side as that of the entered amount.
It must follow the precision of the ledger currency.
If the entered currency is the same as the ledger currency and the accounting class of the journal line is not Rounding, then entered and accounted amounts must be the same.
This is the statistical amount of the subledger journal entry line. It is an optional column.
The following rule applies to statistical amount:
If the profile option Journals: Mix Statistical and Monetary is set to Yes, then statistical and monetary amounts can be entered on the same journal entry.
Statistical amount must be null if the entered currency is STAT.
A journal entry is invalid if it contains both statistical and monetary currency lines.
STAT currency is only used for Actual entries.
This is the entered currency. It is always populated. When the entered currency is the same as the ledger currency, this column is populated with the ledger currency.
A subledger journal entry can have lines with different entered currencies. In Payables, a payment can be made against invoices with different invoice currencies. In this case, the currency code can be different within a subledger journal entry.
The following rules apply:
It must be provided for each journal entry line.
If the currency code is STAT, then the entered amount is the same as the accounted amount. The statistical amount (STATISTICAL_AMOUNT) is null.
STAT currency and other currencies cannot coexist in a single subledger journal entry.
STAT journals need not be balanced.
STAT currency lines are not created for budget and encumbrance journals.
This is the conversion rate types, conversion dates, and conversion rates associated with the journal entry line.
The following rules apply:
When the entered and ledger currencies are the same, and the conversion rate and the conversion rate type are populated, then the conversion rate and conversion rate type values are ignored and not used.
When the entered currency is different from ledger currency, the conversion information is not required to be stored in a journal entry line. However, if conversion information is populated, the following conditions are considered errors:
Conversion type is User and conversion rate is blank.
Conversion type is not User and conversion date is blank.
This is the reconciliation reference value. This column is optional and no validation is applied.
This flag indicates whether the subledger journal entry line contributes to the control account balance calculation. The Control Balance flag can have the following values:
N: not eligible for balance calculation
P: balance calculation pending
Y: balance calculation complete
This flag indicates whether the subledger journal entry line contributes to the supporting reference balance calculation. The Analytical Balance flag can have the following values:
N: not eligible for balance calculation
P: balance calculation pending
Y: balance calculation complete
Note: Balancing rules apply to actual and encumbrance journal entries only. They do not apply to budget entries which can be unbalanced or even one-sided. Actual and encumbrance journal entries must satisfy all three balancing conditions.
The rules described in this section apply to any given subledger journal entry as a whole. Therefore, these conditions are not evaluated until the journal entry header and all the journal entry lines are generated.
A subledger journal entry must be balanced in the currency of the ledger. This means that the sum of the accounted debit amounts (ACCOUNTED_DR) must equal the sum of the accounted credit amounts (ACCOUNTED_CR). Since one journal entry line cannot have both debit and credit amounts, a journal entry must have at least two journal entry lines, one with a debit amount and another with a credit amount.
The Accounting Program balances subledger journal entries by creating balancing entries to the Ledger Currency Balancing Account specified in the ledger definition if the journal entry is not balanced by ledger currency. Select the Balance by Ledger Currency option to enable the assignment of a Ledger Currency Balancing Account. If Balance by Ledger Currency is not enabled, the Accounting Program raises an exception when a journal entry is out of balance by ledger currency.
The Entered Currency Balancing Account is used by Subledger Accounting to balance foreign currency subledger journals by the entered currency and balancing segment value. If you remove the balance account information from accounting setups, Subledger Accounting cannot derive the CCID for Balance by currency rows.
A subledger journal entry must be balanced in the entered currency. If a subledger journal entry has lines with different entered currencies, the subledger journal entry must be balanced for each currency. This means that for each entered currency (CURRENCY_CODE), the sum of the entered debit amounts (ENTERED_DR) must equal the sum of the entered credit amounts (ENTERED_CR).
The Accounting Program balances subledger journal entries by creating an additional line on the entry for each currency requiring balancing if the journal entry is not balanced by entered currency. Such lines use the Entered Currency Balancing Account specified in the ledger definition.
When a journal entry has lines whose code combination identifiers (CODE_COMBINATION_ID) belong to different balancing segments, the subledger journal entry must be balanced based on the accounted amount for each balancing segment. This means that for each balancing segment, the sum of the accounted debit amounts of the subledger journal entry lines (ACCOUNTED_DR) must equal the sum of the accounted credit amounts of the subledger journal entry lines (ACCOUNTED_CR).
The Accounting Program balances subledger journal entries unbalanced by balancing segment by creating debit and credit balancing segment lines. These lines use accounts defined for the ledger in the Intracompany Balancing Rules page in the Accounting Setup Manager (ASM). The Enable Intracompany Balancing option must be selected in the ledger definition in order to enable the application of the balancing rules. The Accounting Program does not provide an automatic balancing mechanism for manual subledger journal entries unbalanced by the balancing segment. Manual subledger journal entries must be balanced by balancing segment at the time of creation.
See: Intracompany Balancing Rules, Oracle Financials Implementation Guide
Intercompany balancing rules are not applied to encumbrance accounting entries.
The Accounting Program balances encumbrance balance type entries using the reserve for encumbrance account. Each encumbrance journal is balanced by balancing segment value (BSV), encumbrance type, and reserve for encumbrance (RFE) account.
Note: The reserve for encumbrance account is defined in General Ledger and is only required when budgetary control is enabled.
Note: The encumbrance type must be defined and enabled in General Ledger.
If you use normal non-encumbrance accounting for secondary ledger, then attach Non-Encumbrance Subledger Accounting method (Standard Cash or Standard Accrual) to secondary ledger with budgetary flag set to No. If you do not want any accounting for secondary ledger as in PO, then attach a Non-Encumbrance Subledger Accounting method (Standard Cash or Standard Accrual) to secondary ledger with no AAD. Payables does not provide any AAD for Standard Cash or Standard Accrual. Accounting ignores secondary ledger and accounts only for primary ledger in this case.
All subledger journal entries must have valid monetary amounts. A journal entry line has two types of monetary amounts, the entered amount and the accounted amount (also known as the ledger amount).
The accounted amount is always in the currency of the ledger, and the entered amount is always in the currency of the transaction. The transaction currency is stored in each subledger journal entry line.
Both entered and accounted amounts have a side. The side is either a debit or credit. In the Subledger Accounting data model, the side of the amount is not treated as an independent column. The side of the amount is included in the name of the column; entered_dr and entered_cr for the entered amount, and accounted_dr and accounted_cr for the accounted amount.
The following rules apply to subledger journal entry line monetary amounts:
They must be signed numbers (including zero).
They must have the same decimal precision as their associated currency.
For example, if the ledger currency has a decimal precision of two, the monetary amounts must have a decimal precision of two.
An amount must always be either a debit or a credit. Either the debit or the credit must have a value, including zero.
Both entered and accounted amounts must be on the same side. In other words, if an entered amount is a debit, then its associated accounted amount must also be a debit and vice versa.
However, the entered and accounted amounts can have different signs. For example, a journal entry line may have a debit rounding difference in the entered amount and a credit rounding difference in the accounted amount. In this case, one single rounding line is created with a positive entered debit amount and a negative accounted debit amount.
A journal entry whose entered currency is the same as the ledger currency should have the same entered and accounted amounts.
Note: This rule does not apply to a rounding line.
Validation of journals created via the accounting engine in budgetary control mode ensures that budgetary control is executed. Budgetary control validation includes Projects, Grants, Contract Commitments, and General Ledger budgetary control when required.
When journal validation is completed the accounting engine processes any budgetary control failures or warnings. Failures occur at line level and depending on the mode of budgetary control, the entire journal can be marked as Failed or individual lines can be marked as Failed and the header is marked with a warning. The table below describes the validation results messages.
| Message | Description |
|---|---|
| Successful Budgetary Control - PASS | All journal lines pass budgetary control and this should be reflected in a message on the journal header. The journal is valid. |
| Failed Budgetary Control - FAIL | One or more lines in the journal failed and budgetary control options indicate the whole transaction should fail. The journal is considered in error and this is reflected in a message on the header of the journal. A message is displayed for each line that fails budgetary control. The journal has errors and is therefore not valid. |
| Advisory Budgetary Control - ADVISORY FAIL | One or more lines in the journal failed and budgetary control options indicate an advisory message should be displayed but the journal is still valid. A message for the header of the journal entry indicates an advisory failure and an advisory budgetary control message is displayed for each line that failed. |
| Partial Failure Budgetary Control - PARTIAL | One or more lines in the journal failed and budgetary control options indicate individual lines should be processed separately and part of the transaction should pass. For the same transaction, this results in some lines passing budgetary control while others fail. The journal requires additional processing. This journal is valid. A warning message is shown on the header of the journal entry. The specific lines that failed contain a message indicating that they failed budgetary control and the amount for the line is set to zero. For encumbrance journals, the reserve for encumbrance account also needs to be adjusted to balance the journal against the failed lines reset to zero. |
| Budgetary Control Fatal/Unexpected Error | A system error was encountered during the budgetary control validation routine. The error may be related to the database, middle tier, or other underlying infrastructure errors. |
| No Budgetary Control Required | Budgetary control is enabled at ledger level but budgetary control options are set at the account code combination, Project, Grant, or Contract Commitment level. Budgetary control validation is automatically initiated in these cases. |
1. Entered currency and ledger currency are the same
The following table lists the details of revenue and receivable lines of a subledger journal entry where the entered currency is the same as the ledger currency.
| Account | Entered Dr (USD) | Entered Cr (USD) | Accounted Dr (USD) | Accounted Cr (USD) | Unrounded Entered DR | Unrounded Entered CR | Unrounded Accounted DR | Unrounded Accounted CR |
|---|---|---|---|---|---|---|---|---|
| 01-Receivable | 100.00 | Null | 100.00 | Null | 100.00 | Null | 100.00 | Null |
| 01-Revenue | Null | 0 | Null | 0 | Null | 0 | Null | 0 |
| 01-Revenue1 | Null | 33.33 | Null | 33.33 | Null | 33.33333 | Null | 33.33333 |
| 01-Rounding | Null | 0.01 | Null | 0.01 | Null | Null | Null | Null |
2. Entered currency is different from the ledger currency
The following table lists the details of revenue and receivable lines of a subledger journal entry where the entered and ledger currencies are different. A conversion rate of 1.1 is assumed.
| Account | Entered Dr (USD) | Entered Cr (USD) | Accounted Dr (EUR) | Accounted Cr (EUR) | Unrounded Entered DR | Unrounded Entered CR | Unrounded Accounted DR (EUR) | Unrounded Accounted CR (EUR) |
|---|---|---|---|---|---|---|---|---|
| 01-Receivable | 70.09 | Null | 56.77 | Null | 70.088 | Null | 56.77128 | Null |
| 01-Revenue | Null | 0 | Null | 0 | Null | 0 | Null | 0 |
| 01-Revenue2 | Null | 35.04 | Null | 28.39 | Null | 35.044 | Null | 28.38564 |
| 01-Rounding | <0.01> | Null | 0.01 | Null | Null | Null | Null | Null |
| 01-Exchange Gain/Loss | 0 | Null | 28.39 | Null | 0 | Null | 28.38564 | Null |
The following are examples of incorrect journal line debits and credits. These lines should never be created in Subledger Accounting.
Entered currency and ledger currency are the same
| Account | Entered Dr (USD) | Entered Cr (USD) | Accounted Dr (USD) | Accounted Cr (USD) | Reason |
|---|---|---|---|---|---|
| 01-Revenue | 100 | 200 | 100 | 200 | The debit and credit cannot be populated at the same time for the same amount. |
| 01-Revenue | 0 | 0 | 100 | Null | The entered amount is populated on both debit and credit sides. |
| 01-Revenue | Null | Null | Null | Null | The amounts cannot be null simultaneously. |
| 01-Revenue | 100 | Null | Null | 100 | The entered and accounted amounts must be on the same side (either debit or credit). |
| 01-Revenue | 100 | Null | Null | -100 | The entered and accounted amounts must be on the same side (either debit or credit). |
| 01-Revenue | 0 | Null | Null | Null | An accounted amount must be populated for every entered amount, even when the amount is zero. |
| 01-Revenue | Null | Null | Null | 0 | The entered amount must be populated. |
| 01-Revenue | 0 | Null | 100 | Null | If the entered currency is same as the ledger currency, then entered and accounted amounts cannot be different. |
Entered currency is different from the ledger currency
| Account | Entered Dr (USD) | Entered Cr (USD) | Accounted Dr (EUR) | Accounted Cr (EUR) | Reason |
|---|---|---|---|---|---|
| 01-Revenue | Null | Null | 100 | Null | Both entered and accounted amounts must be populated. |