Professional Documents
Culture Documents
GL Reconciliation White Paper
GL Reconciliation White Paper
GL Reconciliation White Paper
Release 12 Functionality
Scope: Reconciliation functionality has always been available as a part Oracle Financials
Common County Applications (European Localizations). The functionality was later
incorporated as a part of Standard Release 12 application considering its advantages and
Business Applications.
The scope of this document is to describe the features of this functionality along with
Business Advantages it has to Offer. The document talks of the Setups required, Reporting,
Technical References and few of the Known Issues.
Overview ………………………………………………………………………….3
Application Setup…………………………………………………………….4
Populating References
Reconciliation Process
Manual Reconciliation…………………………………………………………..13
Automatic Reconciliation……………………………………………………...15
a) When you receive an Inventory item, Ideally the Journal entry would be –
Inventory…….Dr
AP Accrual account…….Cr
b) When you book the Invoice and Validate, the journal that gets generated is
AP Accrual account…….Dr
Control account/Party……...Cr
c) Which means, once the cycle completes, the Credit and Debit for Accrual Account
should ideally knock off, leaving a final journal as follows:
Inventory…….Dr
Control account/Party…….Cr
Hence, at any point of time, once the cycle completes, the net for the AP Accrual Account
should be zero. Also, to clear this AP Accrual account, you should be able to give the
breakup of invoices not booked for the material received.
This is where our Journal Line Reconciliation helps us. It allows you to knock of such related
debit and credit pieces and also helps in identifying which transactions still remain
incomplete. This type of reconciliation requires user’s business discipline that all the invoices
will matched to a receipt and not PO, else the reconciliation for this account might go for a
toss.
Journal Reconciliation is available for journals of the balance type of Actual and Journal type
of Standard only. The application allows the Reconciliation process to be performed
manually or even automatically by populating references. The details of the same have been
provided in the following pages.
To set the Reconciliation Flag segment qualifier, enter ‘Yes’ for Reconciliation Flag to
allow reconciliation for natural accounts that you would wish to use for this purpose.
You can enable or disable reconciliation for an account segment value or for specific
account code combinations as well.
The Release 11i Reconciliation feature did not have Reconciliation Qualifier existing. One
had to create the ‘GL Reconciliation Flag’ valueset with Values as Yes/No and then register the
same against the ‘Natural Account ‘Flexfield. (Ref Doc Id: 1041211.6)
If you are enabling the Reconciliation Reference for an already existing Natural Account,
please ensure to the ‘Program - Inherit Segment Value Attributes’ to ensure the Reconciliation Flag
enable is cascaded to the related code combinations as well.
Imagine the Application returning a whole lot of journal lines upon querying and you
are expected to choose the relevant ones that need to get reconciled. Can get
difficult in case of organizations that indulge in large number of transactions.
Please note that references are not mandatory. Journal lines can be reconciled even
if they have blank references.
References can also be imported for transactions coming in from the submodules like
payables, Receivables, Fixed Assets etc. A customization of ‘Subledger Accounting
Method’ (SLAM) may be needed to populate the logic.
Well …yes! While we have always been talking of reconciling Journal Lines, it is
possible to assign a Reconciliation Reference to the Journal Header as well. Once the
user enters a Reconciliation Reference for the Journal Header in the ‘Other
Information’ tab, all the lines entered into this journal, post addition of the reference,
shall automatically inherit the reference provided at the header level. Of course, if
any of the lines are created for a code combination not marked for reconciliation, no
reference shall be populated in this case.
Please note that any journal line that was entered before the Reference was provided
at the header, shall NOT inherit the reference. Which also means that if a Journal line
was entered prior to the Reconciliation Reference being provided for a code
combination marked for Reconciliation, it would automatically populate the
Reconciliation Reference as ‘Null’ for such lines.
Step1 : Create a New Journal and enter a Reconciliation Reference for the
Header
Header References can be created using Journal Enter form only. It is not possible to import
references for headers either from the third party tool, Web ADI or even using a standard
submodule, since the table gl_interface does not provide for it.
The main improvement of the R12 functionality is the ability to populate the
reconciliation reference automatically in the GL Interface from the subledgers. This
can be done by enabling the Reconciliation Reference in the respective Journal Line
Type, and requires a custom Subledger Accounting Method (SLAM).
Step1:
1. Query a seeded Journal Line Type and copy it by clicking on the Copy button at
the bottom left of the form
2. Give your Journal Line Type code, name, and description a meaningful name.
3. Ensure the “Transfer to GL” field is chosen as ‘Detail’
1. Click on the Accounting Attribute Assignments button at the bottom right of the
form
One could also choose source to be Invoice Description, Invoice Amount etc, based
on the Business Requirement.
3. Save.
Step3:
Navigation: Setup > Financials > Subledger Accounting > Accounting Methods
Builder > Methods and Definitions > Journal Line Definitions
1. Link the Journal Line Type just created to the Journal Line Definition. Copy a
seeded one and create your own if needed.
Ensure that the JLD is already linked to the Application Accounting Definition,
validate the Application Accounting Definition either in the form or via the concurrent
program 'Validate Application Accounting Definitions'.
Assuming also that the Application Accounting Definition is already linked to the
Subledger Accounting Method which in turn is already linked with the ledger, Create
Accounting can now be run.
Step5: Create a Transaction in the Submodule and run the Import Program
Step6: Journal gets populated in General Ledger with the Line References as per
the setup.
1. Manual Reconciliation
General Ledger allows you to reconcile transactions by choosing the relevant journal
lines manually. In the Reconciliation Lines window, you can query the transactions
that are available for reconciliation and select the transactions that you want to
reconcile with each other. If the sum total of the selected transactions is equal to
zero when you save the reconciliation, then General Ledger marks the journal lines
as reconciled. You can reconcile transactions by the entered debit or credit amounts.
Choose the desired parameters. Please note that its only the Ledger, Currency and
Period that is mandatory. Others could be left blank. Choosing the Reconciliation
Reference as blank shall list all the Journal lines – irrespective of them having a
reference value populated or not.
Hitting the Search button on the above form shall show up all the journal lines
matching the criteria provided for search. Select the lines you wish to pick up.
Step3: Reconcile
Once the required lines are selected, simply click on the ‘Reconcile’ button.
General Ledger assigns a unique ID to each reconciliation that you perform. You can
use this ‘Reconciliation ID’ to query the reconciliation in the Reverse Reconciled Lines
window, or to identify the reconciliation on the Reconciled Transactions report.
2. Automatic Reconciliation
Application also provides a feature to automatically reconcile the journal lines using a
concurrent Program. The Program ‘Reconciliation – Automatic Reconciliation’
takes similar parameters like the Manual Reconciliation form along the following:
a) Reconciliation Rule:
This parameter determines the logic to be used while reconciling the journal
lines.
Please note the difference between Option 1 and Option 4. While ‘Account’ in the
Option 1 refers to a Code Combination, the term ‘Natural Account’ in the Option 4 refers to
the Flexfield qualifier ‘Natural Account’
Reconciliation References flow through exactly like the Original Journal upon Reversal
or even when they get replicated in the Reporting Ledger
Reporting Ledgers
Original Journal:
If you notice, exactly the same reconciliation references get populated for the
Reporting Journal, once the original journal is posted in the Primary Ledger. In case
of Reporting ledgers set up at the ‘Subledger level’, the Submodule transfers the
same reconciliation reference to the Journal created at the Reporting ledger level as
well.
The Header level Reconciliations get replicated as well.
Original Journal:
Reversed Journal
Let us take an example. A business user buys an Asset for 1000 USD (which is the foreign
currency) at the rate of 2.0 and by the time the payment of this 1000 USD is made, the rate
changes from 2.0 to 3.0. Summing up, notice that though the accounted amounts for the
purchase and payments are different in the functional currency, the actual amount of
transaction in USD remains constant. Since a Purchase and its Payment ideally complete a
cycle, these two lines should be allowed to be reconciled.
Application allows reconciliation of transactions for a currency other than the Primary
currency as well. The reconciliation process expects the ‘Entered Currency’ to total up to
Zero irrespective of the Accounted Amounts matching or not. It is not possible to reconcile
journals lines of one currency with the other.
In the example below, we have tried reconciling transactions for the USD currency. If you
notice, the application creates Reconciliation Id successfully for Journal lines where Entered
Debit less Entered Credit is zero but the Accounted Debit less Accounted Credit is not.
Entered Debit : 10
Entered Credit : 10
Accounted Debit : 10
Accounted Credit : 20
Reconciliation Reversal can be used to disassociate transactions that that have been
previously reconciled with each other.
In the Reverse Reconciliations window, you can query transactions that you
previously reconciled and select the transactions that you want to disassociate from
each other. If the sum total of the selected transactions is equal to zero when you
save the reconciliation reversal, then General Ledger marks the journal lines as
unreconciled. These transactions then become available for reconciliation again.
Lets take the same example of Reconciliation Id 13021 that we manually reconciled
in the previous example:
Users who are planning to upgrade from 11i to R12 and have been using the
Reconciliation functionality in 11i, shall have to run ‘Program - Upgrade Journal
Lines For Reconciliation’ (GLRCNM) as part of the upgrade to ensure the
reconciliation relevant data is available in Release 12. This program should be run as
part of the upgrade from 11i. It takes the journals from release 11i and adds them
to the table GL_JE_LINES_RECON and thus makes them available on the
reconciliation form.
The program cannot be run more than once. If you try to run it again it will issue a
warning to say it has already been run and the upgrade is done. Also, It can only be
run as part of an upgrade from release 11i, as it uses the information in release 11i
tables to populate the table GL_JE_LINES_RECON.
This program is also known to work for post-upgrade journals. The program spawns
another program ‘Insert Journal Lines for Reconciliation’ (GLRCNINS) which
inserts into the gl_je_lines_recon table for every code combination that has
jgzz_recon_flag Y but the lines do not exists in gl_je_lines_recon.
It takes parameters like Ledger Name, Currency, Period, Start & End Dates and
the Account Range you wish to run the report for.
Similar to the above, the Unreconciled Transactions Report lists all the transactions
for a provided Account range that have not yet been reconciled. These shall be
basically the journal lines that exist in the table GL_JE_LINES_RECON with
Reconciliation Status as ‘U’ (Unreconciled). You can use this information to help you
decide whether to perform additional automatic or manual reconciliations for these
accounts.
This table can be called as the spinal cord for the entire Reconciliation Process. For a
user to be able to run reconciliation or reverse it, run any reports, data should exist
in this table.
2. Table GL_JE_LINES
Release 12 of the application does not populate any data in the table gl_je_lines
JGZZ_RECON_REF_11I
Please note the reconciliation reference is also stamped in the table GL_JE_LINES
_RECON for the journal lines that uses a Header Reference.
4. Table GL_INTERFACE
To Re-iterate, It is not possible to import references for headers either from the third
party tool, Web ADI or even using a standard submodule, since the table gl_interface
does not provide for it. Table gl_interface provides for storing Reconciliation
References at Journal Lines level only.
3. I donot see any concurrent Program getting fired upon clicking the
‘Reconcile’ button. Anything I am missing out on?
The Reconciliation Process does not fire any concurrent program as such. Click of
the ‘Reconcile’ or ‘Unreconcile’ button shall automatically launch the process.
Though the reconciliation reference field is displayed, the entry of this data is
optional. Enhancement request 7410862 has been raised to request for a
possibility of making this field as mandatory.
We are looking at the possibility of a profile option or some means when enabling
reconciliation references for specific accounts, by which entry of the references,
during journal entry can be made mandatory. Until then a form personalization
could make this field mandatory, while the enhancement is not
approved/released.
Currently this feature does not exist. Following Enhancement request has been
raised, Bug: 16566905 - GLXRCENT provide "Select All" Feature or Enable
"Edit -> Select All" On the Toolbar.
Only Actual lines can be reconciled. There was a bug with the code in initial
versions that returned Budget and Encumbrance lines for reconciliation as well.
A patch was later released to resolve the issue. Please refer the ‘Known Issues’
section.
2 JGZZ_RECON_REF Field in Cause: The issue was with the logic used
GL_JE_LINES_RECON is not getting in the code for Package
populated in Reporting Ledger lines_recon_pkg.insert_alc_recon_lines
which did not handle references for the
Journal created in Primary Ledger. Reporting Ledger. The Issue was
While entering Journal, identified with code of the Program over
Reconciliation field (JGZZ_REC_REF Bug Number 16890927.
field in GL_JE_LINES_RECON) is
populated. Solution : Apply Patch 16890927
The Primary Journal got posted and The Patch would Upgrade the file versions
the Journal Created in Reporting as follows:
Ledger. But JGZZ_RECON_REF
field is not populated for Reporting For R12.0:
Ledger Journal in glirclnb.pls 120.9.12000000.5
GL_JE_LINES_RECON Table glirclns.pls 120.4.12000000.1
For R12.1
glirclnb.pls 120.9.12010000.5
glirclns.pls 120.4.12010000.1
3 In Enter Journals form the Cause: The issue is due to Ledger setup -
Reconciliation Reference field appears Journal Reconciliation is not enabled.
grayed out and is not possible to
update. You need to enter a reference Solution :
in order to use Automatic 1. Navigate to Accounting Setup Manager
Reconciliation functionality in GL. 2. Query your Ledger
3. Select the Enable Journal
You already have the following Setup: Reconciliation checkbox for the ledger in
- account code value with appropriate the Ledger Options page.
segment qualifier (Reconciliation set to
Yes)
- enabled the code combination
For R12.0:
glujetxb.pls 120.6.12000000.3
glujetxs.pls 120.4.12000000.1
For R12.1:
glujetxb.pls 120.7.12010000.2
glujetxs.pls 120.4.12010000.1
Cause :
5 Reconciliation form returns The cause was identified as a code issue
Encumbrance and Budget Journal lines over Bug 8980612 : General Ledger
as well for Reconciliation. Reconciliation Showing Encumbrance and
Budget Entries
Solution :
Apply Patch 8980612. The Patch would
Upgrade the file versions as follows:
For R12.0:
glgvwreg.ldt 120.16.12000000.12
glgvw.odf 120.24.12000000.12
For R12.1:
glgvwreg.ldt 120.16.12010000.13
glgvw.odf 120.24.12010000.14
select rec.*
from gl_je_lines_recon rec
where rec.ledger_id = &ledger_id
and rec.jgzz_recon_status = 'R'
and rec.jgzz_recon_date is not null
and exists
(select 1 from gl_je_headers h
where h.ledger_id = rec.ledger_id
and h.je_header_id = rec.je_header_id
and h.actual_flag in ( 'E' , 'B' ));