Closing the AP Month - How it works and what to do when it doesnt!

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

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

Close/Open
Period

Reporting
& Balancing

Pre-Post Work

GL_INTERFACE

AP Data
GL Data
AP Transfer to
GL

Journal Import

AP Data

your invoices are ready to post, you should run

autoapproval and review the hold reports

Step 2 - Journal Import

Creates journals in the GL system

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.

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.

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.

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.
GL not yet
Updated

AP is Posted

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

ap_invoice_
distributions

AP Transfer to GL

gl_interface

ap_invoice_
payments
AP Journal Reports

4. After the process is complete, the AP Journal

reports are generated to display the results of the
posting selection. These reports are very important and
should be saved. They are generated directly from the
posting process and can not be rerun at a latter date.
Accounts Payable Journal Entry Audit Report
This report lists the details of the accounting
transactions that have been inserted into the
GL_INTERFACE table. It displays the AP
transaction, its corresponding debits and credits, the
GL accounts affected, and more.
Accounts Payable Journal Entry Exception Report
This report displays the transactions that encountered
an exception during the posting process. Each
transaction includes an exception code that explains
why it was prevented from posting. All transactions
appearing on this report will require some change in
order to be selected for posting the next time you run
the AP transfer process.
Once the AP Transfer to GL process has
finished, only the AP system will have
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
point. The transactions are now in the
GL_INTERFACE table waiting to be imported into the
GL, via the Journal Import process. If the
transactions are deleted from the GL_INTERFACE
table, the AP system will still show the transactions
as posted, even though the GL has not imported the
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,
NEVER DELETE the AP information from the
GL_INTERFACE table unless you do not want the
accounting transactions to be reflected in the GL.
Note!

Posting Options
While submitting the AP Transfer to GL process, there
are parameters that require input and each is important
to the results received from the posting. Each
parameter will be discussed, along with an example of
its impact on the posting transactions.
1. Post Thru Date
The GL_DATE attached to an invoice distribution or
payment determines in which accounting period the
transaction will be posted. All viable non-posted
transactions having a GL_DATE less than or equal to

the date entered in this field will be selected for

posting.
2. Posting in Detail or Summary
This parameter determines the level of detail
information recorded in the general ledger. Regardless
of what choice is made, the AP subledger maintains all
the detail information for each AP transaction.
Detail
Detailed posting implies that every invoice or payment
distribution will create a unique GL journal entry. For
example, 2 invoices with distributions charged to the
same expense account will create 2 journal entries, each
with a distinct debit and credit.

Example Invoices
Description
Invoice #ABC
Distribution #1
Invoice #XYZ
Distribution #1

(Liability Account 1-200)

Amount
Expense
Account
$50

1-500

$100

1-500

GL Journal created
Account
Description
1-200
Liability - #ABC
1-200
Liability - #XYZ
1-500
Expense - #ABC
1-500
Expense - #XYZ

Debit

Credit
$50
$100

$50
$100

Summary
Summary posting groups transactions with similar
accounting flexfield information together, and creates a
single GL journal for each grouping. Debits and
credits made to the same accounting flexfield are
grouped separately, they are not summed together and
net out.
Example Invoices
Description
Invoice #ABC
Distribution #1
Distribution #2
Invoice #XYZ
Distribution #1
Distribution #2

(Liability Account 1-200)

Amount
Expense
Account
$60
($10)

1-500
1-500

$100
$0

1-500
1-500

GL Journal Created
Account
Description
1-200
Liability Summary
1-200
Liability Summary
1-500
Expense Summary
1-500
Expense Summary

Debit
$10

Credit
$160

$160
$10

AP does not create accounting entries for zero amount

transactions. If you have an individual payment or
distribution line equal to zero, the transaction will not
appear on the Journal Entry Audit report or the posting
reports. However, the AP system will still flag the
transaction as posted.
3. Posting with Audit
Audit provides the information necessary to uniquely
identify the AP transaction that created a GL
accounting entry. (Information such as Invoice
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
in audit in order to utilize the following features:
Posting in detail
Zooming from GL to AP for transaction detail
Running the Posted Payment and Invoice reports
Audit is required in order to post in detail. If you
request detail information, but do not have audit
selected, you will not see detail, but summary
information in the GL_INTERFACE table.
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.
Cash and Expense Transactions
All transactions that affect a cash or expense
account require Audit information. You can not
change the default for these items.
Discount, Realized Gain/Loss, and Cash Clearing
(future payment) transactions.
You have the option to select Audit or No Audit.
Liability transactions
You have the option to select Audit, No Audit or
partial audit. Partial audit summarizes the liability
transactions per invoice or payment, instead of for
the entire posting batch. This provides enough
detail to know which invoice or payment a

transaction came from, but the individual

distribution detail for that item is summarized.
By using the detail/summary and audit options
together, you can get detail information for some
transactions and summary information for others.
Review the following examples to see how the options
work together.

Example Invoices
Description
Invoice #ABC
Distribution #1
Distribution #2
Invoice #XYZ
Distribution #1
Distribution #2

Example Payments
Description
Check #101
Pays Invoice #ABC
Supplier Payment
Discount Taken
Check #102
Pays Invoice #XYZ
Supplier Payment
Discount Taken

(Liability Account 1-200)

Amount Expense
Account
$50
$40
1-500
$10
1-500
$200
$125
1-500
$75
1-500

(Cash Account 1-100)

Amount Other
Account
$50
$45
$5
$100

1-200
1-700

$180
$20

1-200
1-700

Example #1: Post in detail

Audit for Expense, Liability, Cash, and Discounts
GL Journal created for invoices:
Account
Description
1-200
Liability - #ABC
1-200
Liability - #ABC
1-200
Liability - #XYZ
1-200
Liability - #XYZ
1-500
Expense - #ABC
1-500
Expense - #ABC
1-500
Expense - #XYZ
1-500
Expense - #XYZ

Debit

$10
$40
$75
$125

Credit
$10
$40
$75
$125

GL Journal created for Payments:

Account
Description
Debit
1-100
Cash - #101
1-100
Cash - #101
1-100
Cash - #102
1-100
Cash - #102
1-200
Liability - #101
$10
1-200
Liability - #101
$40
1-200
Liability - #102
$75
1-200
Liability - #102
$125
1-700
Discount - #101
1-700
Discount - #101
1-700
Discount - #102
1-700
Discount - #102

Credit
$9
$36
$67.50
$112.50

$1
$4
7.50
$12.50

Example #2: Post in detail

Audit for Expense and Cash
No Audit for Liabilities and Discounts

GL Journal created for invoices:

Account
Description
1-200
Cr Liability Summary
1-500
Expense - #ABC
1-500
Expense - #ABC
1-500
Expense - #XYZ
1-500
Expense - #XYZ

Debit

Credit
$250

$10
$40
$75
$125

GL Journal created for Payments:

Account
Description
Debit
1-100
Cash - #101
1-100
Cash - #101
1-100
Cash - #102
1-100
Cash - #102
1-200
Liability Summary
$250
1-700
Discount Summary

Credit
$9
$36
$67.50
$112.50
$25

Step 2 - Submit Journal Import

At this point, AP has completed its portion of the
posting process and the GL needs to complete the
second portion: importing the accounting transactions
into the GL system.
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
Journal Import" is equal to YES, once the AP transfer
is complete the Journal Import program is

automatically executed. If "Submit Journal Import" is

equal to NO, then you manually submit the Journal
Import process through the GL.
Character: /Navigate Journal Import run
GUI: Journal Import Run
When submitting the process manually, there are 2
additional options that must be selected: Source and
GROUP_ID. The source and GROUP_ID are used to
uniquely identify which transactions in the
GL_INTERFACE table you are requesting to import.
For AP, the source will always be equal to Payables.
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.
The purpose of the journal import is to extract the
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
accounting transactions in the GL journal tables
(GL_BATCHES, GL_HEADERS and GL_LINES).
During import, the audit information is removed from
the GL_INTERFACE table and inserted into the
GL_IMPORT_REFERENCES table. This table must
be populated in order to produce the Posted Payment
and Posted Invoice reports. This data is also used to
zoom from a GL journal line to the originating AP
transaction. The Audit information is the ONLY
stored data link between the GL and AP transactions.
If you do not post in audit, you can not perform these
functions.
GL is
Posted

AP is
Posted

gl_interface

gl_batches

gl_headers
Journal Import

gl_lines
gl_import_
references
Journal Import Reports

AP Posted

Even though you instruct AP to post in Audit, your GL

system must also be configured correctly in order to

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.

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

Character: /Navigate Setup Journal Sources

GUI: Setup Journal Sources
Import Journal References = YES

Note!

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.

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.

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 unposted transactions are simply displayed or displayed
AND SWEPT to the next open period. When a

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 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_
references

ap_trial_balance

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

Non-Posted Payments
Invoice

(Posted Items)
(Posted Invoice
Register Report)
(Posted Payment
Register Report)

Supplier Total

(On-line Inquiry)

Trial Balance Total

Non-Posted Invoices

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
Invoices
This Months Posted
Invoice
Payments

(Posted Invoice
Register Report)
(Posted Payment
Register Report

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,

the GL batch totals may be higher than the totals listed
on the AP Journal Entry Audit report. When posting a
GL batch, if transactions do not balance across
balancing segments, the GL system will automatically
create the entries necessary to balance the amounts in
each segment. These transactions will be displayed in
the posted GL batch, but will not be reflected in the AP
system. AP is not concerned with segment balances,
but with the overall balancing of debits and credits per
transaction. Since the transactions are NOT created
during the Journal Import process, you will not see the
intercompany transactions until you post the GL batch.

Example AP Invoice
Description
Invoice #ABC
Distribution #1
Distribution #2

(Liability Account 1-200)

Balancing Segments: 1 and 2
Amount Expense
Account
$40
$60

1-500
2-500

AP Transactions on AP Journal Entry Report

Account
Description
Debit
Credit
1-200
Liability - Dist. #1
$40
1-200
Liability - Dist. #2
$60
1-500
Expense - Dist. #1
$40
2-500
Expense - Dist. #2
$60
GL Batch: Transactions from GL Journal Import
Account
Description
Debit
Credit
1-200
Liability - Dist. #1
$40
1-200
Liability - Dist. #2
$60
1-500
Expense - Dist. #1
$40
2-500
Expense - Dist. #2
$60

GL Batch: Transactions after running GL Post

Account
Description
Debit
Credit
1-200
Liability - Dist. #1
$40
1-200
Liability - Dist. #2
$60
1-500
Expense - Dist. #1
$40
2-500
Expense - Dist. #2
$60
1-199
Intercompany
$60
Receivable Segment 1
2-299
Intercompany
$60
Payable Segment 2

As you can see, the difference between the posted GL

batch and the AP Journal Entry report is equal to the
amount of the intercompany transactions created during
the GL posting process.

Closing the Period

When you are comfortable that your system is in
balance, you are ready to close the period. To open or
close a period in the Payables system, use the period
control form.
Character: /Navigate - Control - Periods
GUI: Setup: Calendar - Accounting AP Accounting Periods
Although the AP periods mirror those defined in your
GL Set of Books, they are controlled independently.
Both the AP and GL systems are required to open and
close their own periods.
When attempting to close an AP period, if un-posted
transactions exist, a message will be displayed and the
period will not be closed. At that point, you need to
repeat the pre-post steps mentioned above in order to
identify and adjust, or sweep the un-posted
transactions.
You can re-open a closed period in AP as long as it is
not finally closed, and the corresponding GL period is
not closed. Once a final close has been done, the
period can never be reopened. It is recommended that
you final close a period only if it is from a prior year.

II. SOLUTIONS TO FREQUENTLY

ENCOUNTERED PROBLEMS
Even after you understand the fundamentals it is
possible to encounter a problem during your closing
process. The following entries describe some
frequently encountered issues, and provide proven
solutions for dealing with them.
1. My invoice was on hold, but it still posted.
All holds prevent invoices from being paid, but not all
holds prevent invoices from posting. The posting
option can be changed on most holds (with the
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
Invoice #ABC
Distribution #1
Distribution #2

Amount

GL_DATE

$40
$60

15-FEB-97
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 doesnt 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 havent
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.

Credit
$100

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.
GL Journal created for payment:
Account
Description
Debit
1-200
Invoice Liability
$100
1-150
Cash Clearing
GL Journal created for payment clearing:
Account
Description
Debit
1-150
Cash Clearing
$100
1-100
Cash Account

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.

Example: Pay a $100 Invoice utilizing accrual

accounting
GL Journal created for payment:
Account
Description
Debit
1-200
Invoice Liability
$100
1-100
Cash Account

errors and miscellaneous payments. The payables

system will then integrate all these transactions into the
standard posting and closing process.

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.

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.

$100

In addition, if you encounter a problem that requires

assistance, please remember to call Oracle Support.
They may have seen the issue before and may already
have a solution for the issue!

Credit

About the Author

$100

Deidre Figueroa is a Technical Specialist with the

Oracle Support financials group. She has 8 years of
experience implementing financial applications, both
nationally and internationally, including 1 1/2 years
with Oracle Consulting. She has implemented the
Oracle Payables system several times, and is currently a
member of the Accounts Payable support team.

Credit

When the payments are cleared or reconciled, the

transactions will be created and inserted into the
Payables system. (AP_RECON_DISTRIBUTIONS
table). During this time, other miscellaneous
transactions can be created, such as bank charges,