Closing the AP Month - How it works and what to do when it doesn’t!
Deidre Figueroa
Oracle Corporation
Abstract
Improve your AP process by understanding the
fundamentals of closing the month in AP and learning
what to do when the unexpected occurs. This paper
provides an overview of the AP month-end process and
discusses proven solutions to frequently encountered
problems. Topics include new 10.7 and cash
management features.
Scope
I. Fundamentals of Closing
II. Solutions to Frequently Encountered Problems
III. Overview of the Cash Management Impact on AP
Please note that this paper does not discuss data entry,
but focuses on insuring that the transactions entered are
posted and balanced. The new 10.7 reporting features
are integrated with the closing process, while a
highlight of the Cash Management will be discussed
separately.
I. FUNDAMENTALS OF CLOSING
Month-end closing within the Oracle Payables system
Close/Open
Period
Pre-Post Work
GL_INTERFACE
AP Data
AP Transfer to
GL
is a simple process. You navigate to the close period
form, select close, commit, and if all is well, your
period will close and balance. Its that little phrase “if
all is well” that introduces the bulk of the work
required for the month end closing.
If you understand the concepts of what happens during
the closing and how your system setup affects the
process, you can insure that “all is well” for your period
to close and know that it is in balance.
The closing process will be divided into 5 main steps.
• Pre-post work
• Posting
• Reporting
• Balancing
• Closing
Pre-Post Work
Before you can post to the GL, you want to review both
your invoice and payment transactions to insure that
they are ready to post.
Insure invoices are ready to post:
An invoice must be approved and/or have no posting
holds in order to be selected for posting. To insure that
Reporting
& Balancing
GL Data AP Data
Journal Import
your invoices are ready to post, you should run
autoapproval and review the hold reports
1. Approve invoices
The approval process attempts to approve invoices and
remove any existing holds. If exceptions are found,
some invoices may be placed on hold and not approved.
If an invoice contains a system hold you need to
manually fix the invoice and then re-run the
autoapproval process to remove the hold. All user
defined holds must be manually removed as they are
not automatically removed by the autoapproval process.
Payables - Autoapproval report
2. Look for unapproved invoices
After running autoapproval, you want to look for
invoices containing holds and Oracle provides 3 reports
for this purpose. If an invoice appears on any of these
reports, you either need to adjust the invoice or
manually remove the hold.
Invoice Hold Report - displays all held invoices.
Posting Hold Report - only displays invoices with holds
that prevent posting.
Matching Hold Report - only displays invoices with
matching holds.
Insure Payments are made:
The pre-work for payments is limited to insuring that
the transactions you want recorded in this period have
been processed. You must insure that all your
payment batches have been completed: either
confirmed or canceled. A period will not close if there
are payment batches in a status other than confirmed or
canceled.
If an invoice is approved by will not pay, you should
insure that the invoice is due to be paid and that the
payment schedule is not on hold.
Posting
Once the pre-work is complete, you are ready to post.
The posting process selects and updates transactions in
the AP subledger and creates accounting transactions
for the general ledger. This process actually occurs in 2
distinct steps:
Step 1 - Transfer from AP to GL
Updates the AP system
Step 2 - Journal Import
Creates journals in the GL system
Step 1 - Transfer from AP to GL:
Posting begins in the AP system and can be started
from a form or report, depending on the version of the
applications you are using.
Character: /Navigate Task GLPost
Character (10.6 and 10.7) and GUI:
Payables Transfer to General Ledger Report
1. The transfer process selects the invoices and
payments that are ready to post to the general ledger.
2. The appropriate accounting transactions are created
and inserted into the GL_INTERFACE table.
This is the GL open interface used to import journals.
It is a temporary table that holds all the accounting
transactions received from AP until they are imported
into the GL system. Once a transaction has been
successfully imported into the GL system, it is deleted
from the GL_INTERFACE table.
3. Transactions successfully selected and inserted into
the GL_INTERFACE table are updated to "Posted" in
the AP system. Transactions that were selected but
encountered some exception are not inserted into the
GL_INTERFACE table nor are they updated to
“Posted”. (Exceptions can be an inactive accounting
flexfield value, a GL_DATE in an un-opened GL
period, exchange rate missing, etc.)
When an invoice or payment encounters an exception,
the distribution containing the exception will not post,
yet will not prevent the other distributions from
posting. For example, an invoice with 2 distributions
can have one distribution that posted and one that
encountered an exception. If you query the invoice, the
status will show as partially posted.
AP is Posted GL not yet
ap_invoice_ Updated
distributions
AP Transfer to GL gl_interface
ap_invoice_
payments
AP Journal Reports
4. After the process is complete, the AP Journal the date entered in this field will be selected for
reports are generated to display the results of the posting.
posting selection. These reports are very important and
should be saved. They are generated directly from the 2. Posting in Detail or Summary
posting process and can not be rerun at a latter date. This parameter determines the level of detail
information recorded in the general ledger. Regardless
Accounts Payable Journal Entry Audit Report of what choice is made, the AP subledger maintains all
This report lists the details of the accounting the detail information for each AP transaction.
transactions that have been inserted into the
GL_INTERFACE table. It displays the AP Detail
transaction, its corresponding debits and credits, the Detailed posting implies that every invoice or payment
GL accounts affected, and more. distribution will create a unique GL journal entry. For
example, 2 invoices with distributions charged to the
Accounts Payable Journal Entry Exception Report same expense account will create 2 journal entries, each
This report displays the transactions that encountered with a distinct debit and credit.
an exception during the posting process. Each
transaction includes an exception code that explains
why it was prevented from posting. All transactions Example Invoices (Liability Account 1-200)
appearing on this report will require some change in Description Amount Expense
order to be selected for posting the next time you run Account
the AP transfer process. Invoice #ABC
Distribution #1 $50 1-500
Note! Once the AP Transfer to GL process has Invoice #XYZ
finished, only the AP system will have Distribution #1 $100 1-500
completed its portion of the posting
process. As far as AP is concerned, posting is done and
complete. For AP, there is no turning back from this
GL Journal created
point. The transactions are now in the
GL_INTERFACE table waiting to be imported into the Account Description Debit Credit
GL, via the Journal Import process. If the 1-200 Liability - #ABC $50
transactions are deleted from the GL_INTERFACE 1-200 Liability - #XYZ $100
table, the AP system will still show the transactions 1-500 Expense - #ABC $50
as posted, even though the GL has not imported the 1-500 Expense - #XYZ $100
transactions. Once an AP transaction has been posted,
it can not be re-selected for posting again, and there is
no system process to un-post a transaction. Therefore, Summary
NEVER DELETE the AP information from the Summary posting groups transactions with similar
GL_INTERFACE table unless you do not want the accounting flexfield information together, and creates a
accounting transactions to be reflected in the GL. single GL journal for each grouping. Debits and
credits made to the same accounting flexfield are
Posting Options grouped separately, they are not summed together and
While submitting the AP Transfer to GL process, there net out.
are parameters that require input and each is important
to the results received from the posting. Each Example Invoices (Liability Account 1-200)
parameter will be discussed, along with an example of Description Amount Expense
its impact on the posting transactions. Account
Invoice #ABC
1. Post Thru Date Distribution #1 $60 1-500
The GL_DATE attached to an invoice distribution or Distribution #2 ($10) 1-500
payment determines in which accounting period the Invoice #XYZ
transaction will be posted. All viable non-posted Distribution #1 $100 1-500
transactions having a GL_DATE less than or equal to Distribution #2 $0 1-500
GL Journal Created transaction came from, but the individual
Account Description Debit Credit distribution detail for that item is summarized.
1-200 Liability Summary $10
1-200 Liability Summary $160 By using the detail/summary and audit options
1-500 Expense Summary $160 together, you can get detail information for some
1-500 Expense Summary $10 transactions and summary information for others.
Review the following examples to see how the options
work together.
AP does not create accounting entries for zero amount
transactions. If you have an individual payment or
Example Invoices (Liability Account 1-200)
distribution line equal to zero, the transaction will not
appear on the Journal Entry Audit report or the posting Description Amount Expense
reports. However, the AP system will still flag the Account
transaction as posted. Invoice #ABC $50
Distribution #1 $40 1-500
3. Posting with Audit Distribution #2 $10 1-500
Audit provides the information necessary to uniquely Invoice #XYZ $200
identify the AP transaction that created a GL Distribution #1 $125 1-500
accounting entry. (Information such as Invoice Distribution #2 $75 1-500
Number, Supplier Name, Check Number, etc.) Audit
works with the detail/summary option to provide the
information you desire to see in the GL. You must post Example Payments (Cash Account 1-100)
in audit in order to utilize the following features: Description Amount Other
• Posting in detail Account
• Zooming from GL to AP for transaction detail Check #101 $50
• Running the Posted Payment and Invoice reports Pays Invoice #ABC
Supplier Payment $45 1-200
Audit is required in order to post in detail. If you Discount Taken $5 1-700
request detail information, but do not have audit Check #102 $100
selected, you will not see detail, but summary Pays Invoice #XYZ
information in the GL_INTERFACE table.
Supplier Payment $180 1-200
Discount Taken $20 1-700
There are different types of accounting transactions that
can be inserted into the GL_INTERFACE table, and for
each type, you can determine whether to request audit
or not.
Example #1: Post in detail
• Cash and Expense Transactions Audit for Expense, Liability, Cash, and Discounts
All transactions that affect a cash or expense
account require Audit information. You can not
GL Journal created for invoices:
change the default for these items.
Account Description Debit Credit
• Discount, Realized Gain/Loss, and Cash Clearing 1-200 Liability - #ABC $10
(future payment) transactions. 1-200 Liability - #ABC $40
You have the option to select Audit or No Audit. 1-200 Liability - #XYZ $75
1-200 Liability - #XYZ $125
• Liability transactions 1-500 Expense - #ABC $10
You have the option to select Audit, No Audit or 1-500 Expense - #ABC $40
partial audit. Partial audit summarizes the liability 1-500 Expense - #XYZ $75
transactions per invoice or payment, instead of for 1-500 Expense - #XYZ $125
the entire posting batch. This provides enough
detail to know which invoice or payment a
GL Journal created for Payments: automatically executed. If "Submit Journal Import" is
Account Description Debit Credit equal to NO, then you manually submit the Journal
1-100 Cash - #101 $9 Import process through the GL.
1-100 Cash - #101 $36
1-100 Cash - #102 $67.50 Character: /Navigate Journal Import run
1-100 Cash - #102 $112.50 GUI: Journal Import Run
1-200 Liability - #101 $10
When submitting the process manually, there are 2
1-200 Liability - #101 $40
additional options that must be selected: Source and
1-200 Liability - #102 $75
GROUP_ID. The source and GROUP_ID are used to
1-200 Liability - #102 $125 uniquely identify which transactions in the
1-700 Discount - #101 $1 GL_INTERFACE table you are requesting to import.
1-700 Discount - #101 $4
1-700 Discount - #102 7.50 For AP, the source will always be equal to ‘Payables’.
1-700 Discount - #102 $12.50 The GROUP_ID will be unique for each posting batch
that is created. A unique GROUP_ID is generated
during the AP transfer process, and it identifies every
transaction that belongs to the posting batch.
Example #2: Post in detail
Audit for Expense and Cash The purpose of the journal import is to extract the
No Audit for Liabilities and Discounts accounting transactions and audit information from the
GL_INTERFACE table and populate the appropriate
GL tables. The transaction information in the
GL_INTERFACE table will generate the actual
GL Journal created for invoices: accounting transactions in the GL journal tables
Account Description Debit Credit (GL_BATCHES, GL_HEADERS and GL_LINES).
1-200 Cr Liability Summary $250
1-500 Expense - #ABC $10 During import, the audit information is removed from
1-500 Expense - #ABC $40 the GL_INTERFACE table and inserted into the
1-500 Expense - #XYZ $75 GL_IMPORT_REFERENCES table. This table must
1-500 Expense - #XYZ $125 be populated in order to produce the Posted Payment
and Posted Invoice reports. This data is also used to
GL Journal created for Payments: zoom from a GL journal line to the originating AP
transaction. The Audit information is the ONLY
Account Description Debit Credit
stored data link between the GL and AP transactions.
1-100 Cash - #101 $9
If you do not post in audit, you can not perform these
1-100 Cash - #101 $36 functions.
1-100 Cash - #102 $67.50
1-100 Cash - #102 $112.50
AP is GL is
1-200 Liability Summary $250 Posted gl_batches
Posted
1-700 Discount Summary $25

gl_headers
gl_interface Journal Import
Step 2 - Submit Journal Import
At this point, AP has completed its portion of the
posting process and the GL needs to complete the gl_lines
second portion: importing the accounting transactions gl_import_
into the GL system. references

Journal Import Reports AP Posted

When running the AP Transfer to GL process, the
Journal Import process can be initiated from either the
GL system or the AP system. If the option "Submit Even though you instruct AP to post in Audit, your GL
Journal Import" is equal to YES, once the AP transfer system must also be configured correctly in order to
is complete the Journal Import program is
import Audit information. This is handled via the
Journal Import Source form in GL, where the standard
install defaults to allow the import of Payables audit
data.
Character: /Navigate Setup Journal Sources
GUI: Setup Journal Sources
Import Journal References = YES
As with the AP process, it is possible that an exception
can occur while attempting to import a transaction.
The Journal Import Exception report displays
information about all the transactions that GL
attempted to import. The transactions are noted as
successful or containing exceptions. If an exception
occurred, a code is associated with the transaction and
an explanation for each code is displayed at the bottom
of the report. If a batch encounters an exception, unless
the exception can be posted to a suspense account, the
entire batch is left in the GL_INTERFACE table and
is not imported.
Note! When submitting the Journal Import
process from the GL, there is an option to
import descriptive flexfields. The AP
system does not currently send the information required
to populate the descriptive flexfields. Although this
option can be used for importing from other
applications, it does NOT work for AP journals. If you
require this feature, at this time you will need to
customize your AP system to insert the required
descriptive flexfield information into the
GL_INTERFACE table.
Reporting
Once the posting process is complete, you are ready to
run some key reports to insure that both your Payables
sub-ledger and the General Ledger are in balance.
Oracle provides numerous reports to assist you in
balancing.
1. Unposted Invoice Sweep Report
This report informs you about un-posted invoices and
payments in the current or previous open periods. If
un-posted transactions exist, you must decided if you
want to post them in the current period or sweep them
(move them) to the next open period.
The parameter, "Report Only", determines if the un-
posted transactions are simply displayed or displayed
AND SWEPT to the next open period. When a
transaction is swept, its GL_DATE is changed to the
first day of the next open period. (Remember that the
GL_DATE determines in which period a transaction is
posted).
Note! In report only mode, you can run the report
as often as you like. IN SWEEP MODE,
THE REPORT SHOULD ONLY BE RUN
AFTER ALL DESIRED TRANSACTIONS HAVE
BEEN POSTED IN THE CURRENT PERIOD. This is
very important, because the sweep report selects all
transactions that have NOT yet posted, and moves them
to the next open period. There is NO process to
"unsweep" transactions once they have been moved to
the next open period.
2. Accounts Payable Trial Balance Report
This report displays the individual liability for every
supplier that has an open balance. The report is
divided and summed by liability account, and should
balance to the respective AP Liability account in the
general ledger.
Only invoices and payments that have been POSTED in
AP will display on this report. (They need not be
posted in the GL).
3. Posted Invoice Report, Posted Payment Report
These reports display the invoices or payments that
have been posted to the general ledger in a given date
range. In order for a transaction to appear on these
reports, it must have been posted in audit in AP, and
imported into the general ledger.
4. Expense Distribution Report,
Payment Distribution Report
These reports display the accounting transactions that
will be created when you post your transactions. They
can be run before or after you post, as they analyze each
AP transaction and display what accounting
transactions will be created during the posting process.
They show accounting detail that you can not see by
viewing a transaction online.
5. Journal with GL Details Report
Transaction Reconciliation Report
These are new reports introduced in release 10.7, and
are used to review details of transactions posted from
AP and imported into the GL. The report is based on
data in the GL_IMPORT_REFERENCES table, which
is populated when you post in Audit. If you have not
posted in Audit, this information will not be available.
These reports are basically the same, but utilize
different parameters to select the information that is
displayed. The Journal with GL details report selects
data based upon GL entries created from AP
transactions, while the Transaction Reconciliation
report selects data based upon the AP transactions.
Therefore, if you have an AP transaction for which you
would like to see the accompanying GL transactions,
use the reconciliation report. If you have a GL journal
for which you would like to see the originating AP
transaction, run the GL details report.
Balancing
The reports described above will be used in the
balancing process. To determine if your system is in
balance, you need to insure that the amount reported in
AP matches the amount reported in the GL. In
addition, there are times when you want to see that the
AP system is in balance with itself. (i.e. Pilot testing,
checking the validity of converted data, or your AP and
GL systems don’t balance together).
Balancing AP
Every transaction that is posted from AP to the GL is
reflected in the Accounts Payable Trial Balance report.
If you want to test the data on this report against the
transactions entered for a supplier, you can spot check
individual suppliers. View the outstanding balance for
the individual supplier via the invoice inquiry form and
compare it to the data on the trial balance report. The
on-line balance inquiry includes all transactions, unlike
the trail balance report that only includes posted
transactions. Therefore, the on-line supplier balance
should match the data reported on the trial balance
report, +/- any non-posted transactions. If a supplier
does not appear on the trial balance report, that
indicates there is no outstanding posted liability for that
supplier.
Character: /Navigate Invoice Inquiry
Search Option: Balance by Supplier
GUI: Invoices Inquiry Invoices
Calculate Balance Owed
Trial Balance Total (Posted Items)
+ Non-Posted Invoices (Posted Invoice
Register Report)
- Non-Posted Payments (Posted Payment
Invoice Register Report)
= Supplier Total (On-line Inquiry)
Balancing AP to the GL
To balance the AP and GL systems together, the AP
Trial Balance report should agree with the GL liability
accounts and the posting reports.
AP GL
gl_import_
ap_trial_balance
references
AP Trial Balance AP Posted
1. GL posted transactions and AP trial balance
Utilizing the trial balance report and the posting
reports, you can insure that the transactions imported
into the GL system agree with those entered and posted
in the AP system. Although the posting reports are
run from the AP menu, they are based on data stored in
the GL system (GL_IMPORT_REFERENCES table).
If you did not post in audit or are using Cash based
accounting, you will not be able to perform this
balancing process.
To balance, you will need this months and last months
AP Trial Balance Report, and this months posting
reports. Last months trial balance, plus this months
transactions should equal this months trial balance.
Last Months Trial Balance
+ This Months Posted (Posted Invoice
Invoices Register Report)
- This Months Posted (Posted Payment
Invoice Register Report
Payments
= Current Trial Balance (On-line Inquiry)
2. Balance GL liability account to the trial balance
Verify that the GL liability accounts agree with the data
reported on the AP trial balance report.
3. Balance GL batch to the AP posting batch
When you post and import transactions from AP into
the GL system, a unique GL batch is created. You can
balance a GL batch against the AP Journal Entry Audit
report that was generated during the AP transfer
process.
If your set of books allows intercompany accounting, As you can see, the difference between the posted GL
the GL batch totals may be higher than the totals listed batch and the AP Journal Entry report is equal to the
on the AP Journal Entry Audit report. When posting a amount of the intercompany transactions created during
GL batch, if transactions do not balance across the GL posting process.
balancing segments, the GL system will automatically
create the entries necessary to balance the amounts in
each segment. These transactions will be displayed in Closing the Period
the posted GL batch, but will not be reflected in the AP
system. AP is not concerned with segment balances, When you are comfortable that your system is in
but with the overall balancing of debits and credits per balance, you are ready to close the period. To open or
transaction. Since the transactions are NOT created close a period in the Payables system, use the period
during the Journal Import process, you will not see the control form.
intercompany transactions until you post the GL batch.
Character: /Navigate - Control - Periods
GUI: Setup: Calendar - Accounting -
Example AP Invoice (Liability Account 1-200) AP Accounting Periods
Balancing Segments: 1 and 2
Description Amount Expense Although the AP periods mirror those defined in your
Account GL Set of Books, they are controlled independently.
Invoice #ABC Both the AP and GL systems are required to open and
Distribution #1 $40 1-500 close their own periods.
Distribution #2 $60 2-500
When attempting to close an AP period, if un-posted
transactions exist, a message will be displayed and the
AP Transactions on AP Journal Entry Report period will not be closed. At that point, you need to
Account Description Debit Credit repeat the pre-post steps mentioned above in order to
identify and adjust, or sweep the un-posted
1-200 Liability - Dist. #1 $40
transactions.
1-200 Liability - Dist. #2 $60
1-500 Expense - Dist. #1 $40
You can re-open a closed period in AP as long as it is
2-500 Expense - Dist. #2 $60 not finally closed, and the corresponding GL period is
not closed. Once a final close has been done, the
GL Batch: Transactions from GL Journal Import period can never be reopened. It is recommended that
Account Description Debit Credit you final close a period only if it is from a prior year.
1-200 Liability - Dist. #1 $40
1-200 Liability - Dist. #2 $60
1-500 Expense - Dist. #1 $40 II. SOLUTIONS TO FREQUENTLY
2-500 Expense - Dist. #2 $60 ENCOUNTERED PROBLEMS

Even after you understand the fundamentals it is

GL Batch: Transactions after running GL Post possible to encounter a problem during your closing
Account Description Debit Credit process. The following entries describe some
1-200 Liability - Dist. #1 $40 frequently encountered issues, and provide proven
1-200 Liability - Dist. #2 $60 solutions for dealing with them.
1-500 Expense - Dist. #1 $40
2-500 Expense - Dist. #2 $60 1. My invoice was on hold, but it still posted.
1-199 Intercompany $60 All holds prevent invoices from being paid, but not all
Receivable Segment 1 holds prevent invoices from posting. The posting
2-299 Intercompany $60 option can be changed on most holds (with the
Payable Segment 2 exception of the system holds).

To change the posting options of a hold, use the Define

Invoice Approval form.
Character: /Navigate Setup Invoices Approvals
GUI: Navigate Setup Invoices Approvals
Unfortunately, once an invoice has been posted, there is
no un-post option. You will have to create manual GL
journal entries if you want to back out the posting.
2. Someone deleted the AP data from the
GL_INTERFACE table before we imported to the
GL!
Although there is no standard process to re-post your
AP transactions, there are times when it is necessary to
do so.
Oracle Support does have some pre-defined scripts to
help you with this situation. These scripts will go into
the database and manually "un-post" your transactions.
You can then re-run the AP transfer to GL process, and
the transactions will be re-selected for posting, inserted
into the GL_INTERFACE table, re-flagged as posted,
and will be ready to import into the GL system.
Should you run into a situation requiring re-posting,
please contact Oracle support. They need to work with
you to analyze your situation and determine what
changes your system requires and which scripts will be
needed.
Although Oracle can provide help in fixing the
transactions, it is up to you to determine WHICH
transactions need to be adjusted. This process can be
greatly simplified if you retain the AP Journal Entry
Audit report generated from the AP Transfer to GL
process. If you do not maintain the report, it will be
difficult to identify the problem transactions.
3. My invoice displays a different date from the
period in which it posted.
The GL_DATE associated with an invoice distribution
determines the posting period, not the GL-DATE
associated with the invoice.
The GL_DATE at the invoice level is used for display
purposes only. If you query a posted invoice, the
GL_DATE at the invoice level will default to the latest
GL_DATE from your distributions, or the first day in
the next open period. Do not worry that the
distributions posted in one period and now the invoice
shows a different date. The invoice GL_DATE is
display only, purely intended to help make your input
of distributions easier.
Example:
Description Amount GL_DATE
Invoice #ABC
Distribution #1 $40 15-FEB-97
Distribution #2 $60 25-FEB-97
Example #1: Query invoice on 26-FEB-97
The invoice GL_DATE will display 25-FEB-97
Example #2: Query invoice in April, when
FEBRUARY is already closed.
The invoice GL_DATE will display 01-APR-97
4. I am trying to run the Journal import process
from the GL system, but no transactions are being
imported.
When running the Journal Import process from GL,
you must select source = Payables, and select a
GROUP_ID. If you do not select a GROUP_ID, the
process will run, but no transactions will be imported.
If you have more than one GROUP_ID to choose from,
you may not know which one to select. Unfortunately,
there is no report that you can run to get this ID. If
needed, you can run the following select statement from
sqlplus to identify the GROUP_ID associated with your
AP Posting Batch.
col batchname format a15;
col trans_type format a15;
select distinct reference1 batchname, GROUP_ID,
reference26 trans_type
from GL_INTERFACE
where reference26 like 'AP%'
group by group_iD,reference1, reference26
order by GROUP_ID, reference26;
5. My trial balance is wrong.
First, insure that you have posted all your invoices and
payments. Remember that non-posted transactions do
not show up on the trial balance report. This is the
number one culprit for trial balance issues.
If it is actually determined that the data listed in the
report is incorrect, a script can be used to rebuild the
trial balance report. The script will backup your
current trial balance table, delete the existing data, and
then use the data stored for your invoices
(AP_INVOICE_DISTRIBUTIONS) and payments
(AP_INVOICE_PAYMENTS) to rebuild the data.
Should you need to rebuild your trial balance, please
call Oracle Support and request the rebuild script. This
information is documented in Bug #375496.
6. I have paid invoices that continue to show up on
the trial balance report!
In order for an invoice to be removed from the trial
balance report, it must have a corresponding
payment… even if the invoice was for a total of zero
dollars. Therefore, you must issue zero dollar
payments for these invoices in order to mark them as
paid, and thus remove them from the trial balance
report.
7. My canceled invoices continue to show up on the
trial balance report!
This occurs if you are using Automatic Offsets.
When the trial balance report is generated, it groups all
the entries for a supplier, and sums them by
INVOICE_ID. If an invoice is paid, summing the
invoice and payment together should net to zero. If the
amounts sum to zero, all transactions associated with
the invoice are removed from the report. Hence, you
only see suppliers where the sum of their payments do
not equal the sum of their invoices, indicating that they
have an outstanding liability, credit, or un-posted
transaction.
Because automatic offsets records a unique liability
account for each distribution line, the trial balance
sums transactions by INVOICE_ID and
DISTRIBUTION_LINE_NUMBER. Under most
circumstances, the trial balance looks the same,
whether you are using automatic offsets or not.
However, reversed distribution lines work differently.
When canceling an invoice, each distribution that
currently exists on the invoice must be reversed. A
reversal entry is created for each distribution being
reversed. The reversal line shares the same
INVOICE_ID as the original distribution, but has its
own unique DISTRIBUTION_LINE_NUMBER. When
the trial balance report attempts to group and sum the
transactions by INVOICE_ID and
DISTRIBUTION_LINE_NUMBER, it does not net
these items together and omit them from the trial
balance report.
Although Oracle development is working on an
enhancement for a future release, there currently is no
patch for this issue. If your report is too large and you
need the zero amount transactions removed, you can
contact Oracle Support and they will help you resolve
this issue.
They will help you update the AP_TRIAL_BALANCE
table through sqlplus and enable the invoices and
payments to net together and thus be removed from the
report. However, this is only a temporary solution,
because the next time you post, the same situation will
occur.
8. My GL liability account doesn’t agree with the
AP trial balance report. Where can I look for help?
1. Run the GL Account Analysis report for the liability
account and for the date range in question. Look for
transactions with a source other than Payables. This
can quickly pinpoint any transactions incorrectly
charged to the account.
2. Are there still transactions in the GL_INTERFACE
table that need to be imported? Those transactions
would be displayed in the trial balance report, but
would not yet display in the GL accounts.
3. Have the transactions been posted within the GL?
The GL account balance is not updated until the GL
journals are posted.
4. Are you still in pilot testing? Perhaps you haven’t
converted your outstanding invoices yet but the GL
shows an up-to-date liability total. In this case, you
would need to account for the converted GL amounts
when balancing.
III. CASH MANAGEMENT
INTEGRATION
If you are running the 10SC product, you have the
ability to use the Cash Management application and
integrate it with your Accounts Payable system. Cash
Management will help you reconcile your bank
statements, create miscellaneous transactions, and
manage your cash flow.
When defining the Payables system, you can decide
whether or not you want the cash management
application to create accounting transactions when it
processes the bank transactions. This option is called
"Allow Reconciliation Accounting", and it can be
defined in the payables setup option. If you enable this
option, Cash Management will create accounting
transactions. If the option is not enabled, you can still
use the Cash Management application, but it will not
create accounting transactions.
Char: /Navigate - Setup - System - Options
GUI: Setup - Options - Payables Options
Accounting Impact
When using the standard Payables system, the cash
account is credited when issuing a payment. This holds
true for both accrual and cash based accounting.
Example: Pay a $100 Invoice utilizing accrual
accounting
GL Journal created for payment:
Account Description Debit Credit
1-200 Invoice Liability $100
1-100 Cash Account $100
errors and miscellaneous payments. The payables
system will then integrate all these transactions into the
standard posting and closing process.
Closing Impact
Utilizing the Cash Management application will not
alter the standard AP closing process, but will change
the some accounting transactions. In the standard
closing process, the invoice and payment transactions
were discussed. If you are using autoreconciliation
accounting, your closing reports will still look the
same, but will contain an additional section that
contains the reconciliation transactions.
For Example:
The AP transfer to GL process will include the
reconciliation transactions, and the data will be
displayed in a separate section on the AP Journal Entry
Audit reports.
The Un-posted Invoice Sweep report will also display a
separate section for the reconciliation transactions.
This allows the un-posted transactions to be reported or
swept to the next period.

When utilizing reconciliation accounting, a cash

clearing account will be charged instead of the cash
account. When the payment document is reconciled or
cleared within the Cash Management application,
additional transactions will be created and charged
against the cash clearing account.
Example: Pay a $100 Invoice utilizing accrual
accounting. Then, clear the check in the Cash
Management application.
Conclusions
It is my desire that this paper has helped you
understand the fundamental process of closing a period
in AP. Breaking the process into the 5 main categories
should help you understand the "state" of your system.
If something appears incorrect in the posting or
balancing process, I hope that you are now better
equipped to troubleshoot the problem and determine
what needs to be done to resolve the issue.

GL Journal created for payment: In addition, if you encounter a problem that requires
Account Description Debit Credit assistance, please remember to call Oracle Support.
1-200 Invoice Liability $100 They may have seen the issue before and may already
1-150 Cash Clearing $100 have a solution for the issue!

GL Journal created for payment clearing:

Account Description Debit Credit About the Author
1-150 Cash Clearing $100
1-100 Cash Account $100 Deidre Figueroa is a Technical Specialist with the
Oracle Support financials group. She has 8 years of
When the payments are cleared or reconciled, the experience implementing financial applications, both
transactions will be created and inserted into the nationally and internationally, including 1 1/2 years
Payables system. (AP_RECON_DISTRIBUTIONS with Oracle Consulting. She has implemented the
table). During this time, other miscellaneous Oracle Payables system several times, and is currently a
transactions can be created, such as bank charges, member of the Accounts Payable support team.