How Do You Account for That?
- Oracle Payables 11i
Lauren Scott
Oracle Corporation
Introduction
In release 11i, Oracle Payables introduces a new
accounting model to support the creation and retention
of accounting entries in the Payables subledger. This
paper discusses why this change was made, and how it
affects the accounting and period close processes in
Payables. This paper is primarily an overview of the
new functionality, however, a review of the
functionality in previous releases is provided as a basis
for reference. Examples of the accounting entries
created by the new model in release 11i are provided. A
brief technical overview of the key data model changes
is provided at the end of this paper.
This paper should be most useful to current users of
Oracle Payables who are interested in understanding
the accounting changes made in release 11i and who
want to plan for their upgrade to the new release.
Scope of This Paper
This paper describes accounting in the Oracle Payables
subledger and integration with Oracle General Ledger.
Accounting transactions where Oracle Payables
integrates with other subledgers are not in the scope of
this paper. Transferring accounting data to non-Oracle
general ledgers is not in the scope of this paper. A good
familiarity with the Oracle Payables product is assumed
as features referenced are not described in detail unless
they are new to the accounting model.
This paper assumes accrual basis accounting for its
discussion. Where relevant, a mention of the
accounting impact for cash basis accounting is
included, but only where specifically noted.
Other features which have accounting impact but are
outside of the scope of this paper include:
. Encumbrance accounting
. Automatic Offsets
. Accrual on receipt
. Tax accounting
. Future dated payments
Where relevant, a mention of the accounting impact of
one of these features may be made, but only where
specifically noted.
© Copyright 2000, by Oracle Corporation
How Do You Account for That? - Business
Reasons Behind the Change
The new accounting architecture that Oracle Payables
has introduced with release 11i allows for more
flexibility as new features are introduced in future
releases. However, these changes in 11i were not made
just for the purpose of improving the product
architecture. There were many functional
enhancements in the area of accounting which Oracle
Payables development had been asked to make, and
many of them were not possible without this kind of
architectural foundation.
For example, there were desired enhancements in the
area of prepayment functionality that needed to be
made. Prior to release 11i, the application of a
prepayment created some less than desirable accounting
such as creating an accounting entry for the cash
account. This and other problems could be addressed
with the new accounting model.
Another area which needed enhancement was the
future dated payment functionality. Issues included the
inability to cleanly account for the maturity of a future
dated payment, and the inability to simultaneously use
the future dated payment feature and create accounting
when a payment was cleared or reconciled.
General improvements needed to be made to the
accounting that Payables created. For example, in
release 11i, there is now a single accounting entry
created to accounts such as liability, cash clearing,
cash, and discount (if system level). Prior to this
release, one accounting entry was created to these
accounts corresponding to each invoice distribution.
This was somewhat cumbersome and made
reconciliation more difficult for users.
Another business reason behind the change was the
support of improvements in accounting for currency
gains and losses. Some countries needed to be able to
account for gain or loss only at the time of payment
clearing. Prior to the new accounting model in release
11i, this would have been very difficult to support.
Another enhancement in this area is support for the
calculation of gain or loss at the desired level. Oracle
Payables can now support the calculation at the
payment level or the payment line level.
This is not an exhaustive overview of all the business
reasons for the introduction of this new accounting
architecture, but it should serve to point out that there
are some important benefits to users of the Oracle
Payables product. This change is also consistent with
the future direction of Oracle Financials. In future
releases all of the subledgers which create accounting
will move to this new subledger accounting model.
Oracle Payables development will also be doing more
work in this area to improve and enhance the
architecture it now has in release 11i.
Review of Accounting in Prior Releases
A review of the way accounting works in Payables prior
to release 11i is included here to serve as a basis for
understanding the new accounting model discussed in
the following sections. When there are references to
specific forms, fields, reports, or programs, they are the
release 11 names.
Before 11i, there is no accounting in the Payables
subledger. Accounting information is inherent in a
Payables document, but there is not always a way to see
the information (for example, an invoice price variance
for a purchase order matched invoice). Accounting for
Payables transactions is created by a concurrent process
- the Payables Transfer to General Ledger program.
This is a very complex program which pulls
information out of the transaction tables, creates
accounting entries, and places them in the gl interface.
From there the general ledger process Journal Import
creates journal entries and imports them as unposted
journal entries into Oracle General Ledger.
There are some setup options to point out which control
various aspects of the accounting which is created.
© Copyright 2000, by Oracle Corporation
In the Accounting region of the Payables Options setup
window there are two options in the Cash Clearing
region. The first is called “Allow Reconciliation
Accounting”. If this is enabled, it means that if Oracle
Cash Management is used to clear and/or reconcile
payments, accounting entries are created for those
reconciled payments.
The other is called “Allow Future Payment Method”. It
is not possible to select both of these options because
future dated payments use the account setup as the cash
clearing account. Although future dated payments are
outside the scope of this paper this is worth pointing
out since this is not the case in 11i. In 11i a separate
account is supported for future dated payments so this
option is not needed.
Also worth noting in this Accounting region is the
setup area called “Journal Entry Creation”. This setup
controls defaults for the submission of the Payables
Transfer to General Ledger process for how it creates
entries in the gl interface. For the accounts in this setup
region it is possible to specify an “Audit” or “No
Audit” option. The Audit option means that the
accounting information is created in detail in the gl
interface, and this in turn means that drill down is
available from the journal entries in Oracle General
Ledger back to the details in the Payables subledger.
The No Audit option creates summary entries, and drill
down is not available. (Note that there is a setup step in
Oracle General Ledger to enable drill down. The
Import Journal References option must be enabled in
the Journal Sources window for Payables.)
Although the drill down functionality provides some
good accounting detail there is not the opposite
functionality in Payables. That is, it is not possible to
inquire on a particular transaction and easily see the
accounting for that transaction.
The process to close an accounting period has also
changed in release 11i, so a review of that process is
also provided here. The rules to close a period in
Payables prior to release 11i are:
. All payment batches must be confirmed
. All invoices must be transferred to general ledger
. All payments must be transferred to general ledger
Before invoices can be transferred to general ledger
they must be approved by the Payables Approval
process. Before payments can be transferred to general
ledger they must pass through the Confirm process.
Typical steps to close a period in Payables are:
. Import all invoices and/or expense reports from in three regions: Accounting Methods, Transfer to GL,
interface tables and Payment Accounting.
. Run Approval
. Review the Posting Holds Report to identify invoices
which cannot be transferred to general ledger
. Correct the invoice transactions; rerun Approval
. Review the Expense Distribution Detail Report
(Some users review this report for particular accounts
before they close a period; they can identify and
correct any issues prior to their close) Accounting Methods
. Confirm any outstanding payment batches
. Run the Payables Transfer to General Ledger
program
. Optionally run the Unposted Invoice and Payment
Sweep (some accounting rules allow this - others do
not)
. Close the Payables period
. Reconcile

How Do You Account for That? -

Overview of New Accounting Model in 11i

Now in release 11i, Oracle Payables creates and stores

accounting entries in the subledger. Accounting entries
are created based on a particular accounting event, for
example, the creation of an invoice, or the payment of
an invoice. These accounting entries are available for
view and analysis even before they are transferred to
the general ledger. There is a new program to create
the accounting entries - the Payables Accounting
Process.
The Payables Transfer to General Ledger is a new
program. Although it retains the same name, it is a
new, much simpler program. It is now truly just a
transfer program. It takes the accounting entries created
in Payables and transfers them to the general ledger
interface, with the capability of doing summarization if
desired. The general ledger Journal Import process
remains the same.
This region corresponds to the Accounting region in
release 11. Notice that the section with the account
audit options has been removed. With the new
accounting model, these options are no longer needed.
When the accounting entries are transferred to the gl
interface, a link is automatically created. This means
that full drill down to the payables accounting entries is
always available from Oracle General Ledger, no
matter the level of summarization. (Note that the same
Import Journal References option in Oracle General
Ledger must be enabled to allow drill down.)
The upgrade from a prior release to 11i retains the
setup in place for the accounting method/s.
Transfer to GL

There is some new and some changed setup for how the
accounting controls and options work in release 11i.
New forms are provided to view the accounting in the
subledger and to correct accounting creation errors if
necessary. Details on all of these new and changed
features are provided in the following sections.

Setup

Oracle Payables has some new and some changed setup

which controls how accounting works in release 11i.
The core of the changes is in the Payables Options form

© Copyright 2000, by Oracle Corporation


This new region controls the default values for the
parameters of the Payables Transfer to General Ledger
program. This assists users in ensuring that they
consistently transfer their accounting entries to the
general ledger interface in the same way. If the “Allow
Override at Program Submission” parameter is
disabled, then an accounting manager can safely
delegate the submission and monitoring of this process
to staff while still ensuring control.
Also, those who use the MRC (Multiple Reporting
Currencies) feature in release 11i can transfer
accounting entries for the reporting sets of books and
the primary set of books at the same time.
Payment Accounting
This new region controls various options for the
accounting of payments. The Account for Payment
option controls the timing of when accounting is
created for a payment. There are three options
available:
. When Payment is Issued
. When Payment Clears
. or both can be selected
If both options are selected then the same functionality
is provided as in prior releases when the “Allow
Reconciliation Accounting” feature was enabled. That
is, accounting will be created at both the time the
payment is issued and at the time when the payment is
cleared and/or reconciled in Oracle Cash Management.
The upgrade from a prior release to 11i enables both of
these options if the “Allow Reconciliation Accounting”
feature was enabled.
The Account for Gain/Loss setup controls the timing of
when accounting is created for the recognition of gain
or loss on a payment transaction.
There are three options available:
© Copyright 2000, by Oracle Corporation
. When Payment is Issued
. When Payment Clears
. or both can be selected
This setup has dependencies on the Account for
Payment setup and vice versa. For example, if the
Account for Payment When Payment is Issued option is
not chosen then the Account for Gain/Loss When
Payment is Issued can not be chosen.
The Calculate Gain/Loss setup controls the calculation
level for the accounting entry for any gain or loss on a
payment transaction.
There are two options available:
. For Each Invoice
. For Total Payment
Prior to release 11i, Payables did not offer this choice.
Gain or loss was calculated for each invoice on a
payment. The upgrade from a prior release does not
automatically choose one of these options - it is left to
the user to determine what is appropriate for his or her
business.
A detailed discussion of the setup relevant to Future
Dated Payments is out of the scope of this paper.
Accounting Events
The 11i Payables accounting model uses the new
concept of accounting events. An accounting event is
an event that might require accounting for a
transaction, for example, a payment. The type of event
controls the accounting that is created for a transaction
and how that accounting appears in the subledger.
The eleven accounting events in Payables are divided
into two document classes, invoices and payments. You
can specify a document class when you create or view
accounting entries.
The accounting events for the invoice document class
are:
. Invoice Event
. Invoice Adjustment Event
. Invoice Cancellation Event
. Prepayment Application Event
. Prepayment Unapplication Event
The accounting events for the payment document class
are:
. Payment Event
. Payment Maturity Event
. Payment Adjustment Event
. Payment Cancellation Event
. Payment Clearing Event
. Payment Unclearing Event AP Liability 200 300

Invoice Event There are many other examples of accounting for an

invoice event, but one other to point out here is the
The invoice event occurs when a new, approved invoice accounting created for an invoice matched to a
is accounted. This event creates accounting entries for purchase order when accrual on receipt is used. The
each of the accounts associated with the invoice following example assumes an invoice for one item
distributions and to the liability account of the invoice. with an invoice price of 105 and a purchase order price
of 103:
The accounting entry created for a simple invoice with
one distribution in the functional (accounting) currency
is: Account Debit Credit
AP Accrual 103
Account Debit Credit Invoice Price Variance 2
Charge 100 AP Liability 105
AP Liability 100
Now with the ability to view the accounting for an
The accounting entry created for an invoice with invoice event online in Oracle Payables, users are able
multiple distributions in the functional currency is: to see this complete entry for their invoice transaction.

Account Debit Credit Invoice Adjustment Event

Charge 100
Charge 50 The invoice adjustment event typically occurs when an
Charge 50 accounted invoice is adjusted in some way. An
AP Liability 200 example of a common adjustment is reversing one
distribution line entered in error to an incorrect charge
Note the summarized entry to the liability account. This account and entering a correcting line. This event
is an enhancement in release 11i. This is different in creates accounting entries for the adjusting lines.
the case of using the automatic offsets feature. If the
automatic offsets feature is used, then the same invoice The accounting entry created for a simple invoice
example above yields the following accounting entry: adjustment in the functional currency is:

Account Debit Credit Account Debit Credit

Charge (Co 01) 100 Charge (in error) 100
Charge (Co 02) 50 Charge (correction) 100
Charge (Co 03) 50
AP Liability (Co 01) 100 Another example of an adjustment is the case where an
AP Liability (Co 02) 50 increase is needed to the amount of an invoice, and the
AP Liability (Co 03) 50 increase is charged to one or more associated charge
accounts. The accounting for an adjustment to increase
an invoice by 100 looks just like the accounting for an
If an invoice is entered in foreign currency, the
invoice event:
accounting entries for the invoice event are created in
both the foreign and functional currency. The following
example assumes an invoice for 200 foreign currency Account Debit Credit
units (FX) which converts to 300 in functional currency Charge 100
units (exchange rate of 1.5): AP Liability 100

Account Debit Credit Debit Credit The accounting date (GL date) is part of what controls
(FX) (FX) how events are accounted. If an invoice is entered with
Charge 100 150 multiple distribution lines, and some of the distribution
Charge 50 75 lines have different accounting dates, then the lines
with the earliest accounting date are accounted as an
Charge 50 75

© Copyright 2000, by Oracle Corporation

invoice event while the lines with the later accounting
date are accounted as an invoice adjustment event. The next event is the entry of the invoice to which the
prepayment is applied. The accounting process first
Invoice Cancellation Event creates the invoice event even if the prepayment has
already been applied:
The invoice cancellation event occurs when an
accounted invoice is cancelled. The cancellation Account Debit Credit
feature automatically adjusts the invoice amount to Charge 600
zero, and reverses all invoice distribution lines. If the Charge 200
invoice lines were matched to a purchase order, the Charge 200
match is also reversed. AP Liability 1000

The accounting entry created for the cancellation of a

simple invoice with one distribution in the functional
currency is: Next the prepayment application event is created:

Account Debit Credit Account Debit Credit

Charge 100 AP Liability 500
AP Liability 100 Prepaid Expense 500

To understand other examples of accounting for the
invoice cancellation event, the invoice event accounting
examples can be reviewed. Note that a corresponding
invoice cancellation event would effectively reverse the
accounting entries.
In cash basis accounting the three events just discussed,
invoice, invoice adjustment, and invoice cancellation,
do not exist. These are not cash events as no payment is
involved.
Prepayment Application Event
This event accounts for the application of a prepayment
to an invoice. It is helpful to provide the accounting
event sequence for a typical prepayment entry, invoice
entry, and then prepayment application to make the
events clear in this case. The following example is a
500 prepayment which is paid and then applied to a
1000 invoice as a partial payment.
The entry of a prepayment into Oracle Payables is
accounted as an invoice event since a prepayment is
modeled as a type of invoice.
Account Debit Credit
Prepaid Expense 500
AP Liability 500
Without discussing the payment event, note that the
payment of the prepayment relieves the liability in this
case so that 500 remains in the prepaid expense
account.
The prepayment application event relieves the liability
account for the amount of the applied prepayment, and
it credits the prepaid expense account for the amount
applied.
For anyone familiar with the accounting of prepayment
applications in prior releases, it is clear that the
accounting in release 11i is improved.
Note that although this event is modeled as part of the
document class of invoices, this event does exist in cash
basis accounting. The reason for this is that the
prepayment application is effectively a payment (partial
or full) of the invoice to which it is applied.
Prepayment Unapplication Event
This event accounts for the unapplication of a
prepayment to an invoice. Just as a prepayment can be
applied to an invoice, there is also a way to unapply
that prepayment. If this is done, then accounting entries
are created to reverse the accounting of the prepayment
application.
The accounting for the unapplication of the prepayment
applied in the example above is:
Account Debit Credit
Prepaid Expense 500
AP Liability 500
Payment Event

© Copyright 2000, by Oracle Corporation

 Discount Taken 18
The payment event occurs when a new payment is
issued and accounted. This event creates accounting Note the summarized entries to the cash clearing and
entries to relieve the liability of the invoice and to discount accounts. This is an enhancement in release
charge the cash clearing or cash account, depending on 11i. This is different in the case of using the automatic
the system setup options. offsets feature. If the automatic offsets feature is used,
then a similar payment event yields the following
This event occurs when the Payment Accounting option accounting entry:
“Account for Payment When Payment is Issued” is
enabled. If the system is set up to account for any gains Account Debit Credit
or losses at the time of payment issue, this accounting AP Liability (Co 01) 100
event also creates those accounting entries. For the AP Liability (Co 02) 100
following examples, assume that the setup used is to Cash Clearing (Co 01) 91
account for payments at both issue and clearing, and to
Cash Clearing (Co 02) 91
account for gain or loss at the same time.
Discount Taken (Co 9
01)
The accounting entry created for the payment of a
Discount Taken (Co 9
simple invoice in the functional (accounting) currency
02)
is:
There are many other examples of accounting for a
payment event, but one other to point out here is the
Account Debit Credit
accounting created for multiple payments made for the
AP Liability 100
same foreign currency invoice. When the final payment
Cash Clearing 100
is made on an invoice, Payables ensures that the
liability is fully relieved, even if the sum of the
If an invoice is entered and paid in foreign currency, functional currency amounts of the payments does not
there may be a currency gain or loss realized at the time add up to the functional currency amount of the
of accounting for the payment event. In the foreign liability. This is handled by creating the necessary entry
currency example in the invoice event section, the to the rounding account. This example is for an invoice
invoice was for 200 foreign currency units (FX) which in the amount of 20.08 foreign currency units (FX)
converted to 300 in functional currency units (exchange converted to 2.01 functional currency units. So the
rate of 1.5). Using the same example, now the payment liability for the invoice was booked as 2.01.
is made for 200 foreign currency units (FX) which
converted to 340 in functional currency units (exchange A first payment is made for the invoice in the amount
rate of 1.7). The accounting entries are created in both of 10.04 foreign currency units (FX) converted to 1.00
currencies by the payment event: functional currency units and accounted as follows
(assume no gain or loss for simplicity):
Account Debit Credit Debit Credit
(FX) (FX) Account Debit Credit Debit Credit
AP Liability 200 300 (FX) (FX)
Realized Loss 40 AP Liability 10.04 1.00
Cash Clearing 200 340 Cash Clearing 10.04 1.00

Accounting for discounts is also handled by this event. A second payment is made for the invoice in the
This example assumes that the discount method is the amount of 10.04 foreign currency units (FX) converted
system account. This is an example of a payment for an to 1.00 functional currency units and accounted as
invoice in the functional currency, where the invoice follows:
amount is 200 and a discount of 18 is taken. This
example is for the payment of an invoice which has Account Debit Credit Debit Credit
multiple invoice distributions. (FX) (FX)
AP Liability 10.04 1.00
Account Debit Credit Cash Clearing 10.04 1.00
AP Liability 200 AP Liability .01
Cash Clearing 182

© Copyright 2000, by Oracle Corporation

 Rounding .01
Payables creates the last two entries when it finds that
the second payment is the final payment and yet the full
2.01 of the liability is not relieved.
Payment Maturity Event
The payment maturity event occurs only for future
dated payments and if the system setup is to account for
payments at issue time. When future dated payments
are issued, they are accounted by the payment event,
just as for standard payments. The payment maturity
event happens when the future dated payments reach
their maturity - that is, they become negotiable
documents.
To understand the accounting created by the payment
maturity event, first an example is needed of the
accounting for the payment event of a future dated
payment. Here is the accounting for a simple 100
payment in the functional currency:
Account Debit Credit
AP Liability 100
Future Dated Payment 100
Note that rather than hitting a cash clearing or cash
account, the accounting for the issue of a future dated
payment is entered to the designated future dated
payment account. The amount is held in this account
until the payment becomes negotiable.
When the payment status changes from “Issued” to
“Negotiable” then the payment maturity event occurs
and is accounted as follows:
Account Debit Credit
Future Dated Payment 100
Cash Clearing 100
accounted. This includes any gains or losses, discounts,
etc. Then the event creates new payment accounting for
the newly paid invoice or invoices.
The following illustrates the accounting that takes place
during a payment adjustment event. The starting point
is the existing accounting created when an invoice was
recorded paid by a manual payment. This example uses
the same foreign currency invoice and payment from
the sections on the invoice and payment events.
The invoice was for 200 foreign currency units (FX)
which converted to 300 in functional currency units
(exchange rate of 1.5). The payment was made for 200
foreign currency units (FX) which converted to 340 in
functional currency units (exchange rate of 1.7). The
accounting entries were created in both currencies by
the payment event:
Account Debit Credit Debit Credit
(FX) (FX)
AP Liability 200 300
Realized Loss 40
Cash Clearing 200 340
Now it is realized that the invoice recorded by this
manual payment was recorded in error. It happened
that the invoice selected was for the same 200 amount
as the invoice that should have been recorded. Using
the Payables adjustment functionality, the incorrect
invoice (1) is selected to be returned to unpaid status,
and the invoice which should have been recorded as
paid (2) is now correctly recorded. The accounting for
the event is:

Now that the future dated payment is negotiable, the Account Debit Credi Debit Credit
future dated payment account is relieved and the (FX) t (FX)
appropriate entry is made to the cash clearing account. AP Liability (1) 200 300
Realized Loss (1) 40
Cash Clearing 200 340
Payment Adjustment Event
(1)
AP Liability (2) 200 300
A payment adjustment event occurs when any of the
invoices recorded as paid by a manual payment are Realized Loss (2) 40
changed. Payables has a feature which allows this type Cash Clearing 200 340
of adjustment. If an adjustment like this is made, then (2)
the accounting event creates reversals of the accounting
done when the original payment of the invoices was Payment Cancellation Event

© Copyright 2000, by Oracle Corporation

This event creates accounting entries for the void of a
payment. A void of a payment cancels the payment This accounting event may also handle any accounting
document and sets the invoices on the payment back to for currency gains or losses. If setup is such that there
unpaid status. The accounting entries generated are the is no accounting for gain or loss at the time a payment
opposite of what are created for a payment event. is issued, but rather only at the time a payment clears,
then the accounting for the payment clearing event
Here is the example of a 182 payment and 18 discount creates the necessary accounting entries.
taken (discount charged to a system account):
In the foreign currency example in the invoice event
Account Debit Credit section, the invoice was for 200 foreign currency units
AP Liability 200 (FX) which converted to 300 in functional currency
Cash Clearing 182 units (exchange rate of 1.5). Using the same example,
Discount Taken 18 now the payment is made for 200 foreign currency
units (FX) at the same conversion rate since no gain or
If this payment is voided, and then accounting is loss will be calculated until the payment clears. The
created, the accounting for the payment cancellation accounting entries are created in both currencies by the
event appears as follows: payment event:

Account Debit Credit Account Debit Credit Debit Credit

AP Liability 200 (FX) (FX)
Cash Clearing 182 AP Liability 200 300
Discount Taken 18 Cash Clearing 200 300

Payment Clearing Event When the payment clears, the 200 foreign currency
units are converted to 340 in functional currency units
The payment clearing event occurs when a payment is (exchange rate of 1.7). The accounting entries are
cleared or reconciled in Oracle Cash Management, and created in both currencies by the payment clearing
the system is set up to account for payments when they event:
clear (one of the payment accounting options reviewed
in the Setup section). Account Debit Credit Debit Credit
(FX) (FX)
Here is an example of the accounting created at both Cash Clearing 200 300
payment issue and payment clearing. Accounting at Realized Loss 40
payment issue for a 182 payment with a 18 discount Cash 200 340
taken (discount charged to a system account):
Payment Unclearing Event
Account Debit Credit
AP Liability 200 The payment unclearing event occurs when a cleared or
Cash Clearing 182 reconciled payment is reversed in Oracle Cash
Discount Taken 18 Management - in effect the payment is “uncleared”.
The accounting entries created simply back out the
Now at the time of payment clearing the accounting accounting created by the payment clearing event.
entry created is: If at the time of payment clearing the accounting entry
created was:
Account Debit Credit
Cash Clearing 182 Account Debit Credit
Cash 182 Cash Clearing 182
Cash 182
Effectively this accounting moves the cleared or
reconciled payment out of the cash clearing account Now at the time of the payment unclearing the
and debits the cash account now that the cash has been accounting created is:
issued by the bank.

© Copyright 2000, by Oracle Corporation

 Account Debit Credit
Cash Clearing 182
Cash 182
Payables Accounting Process
Oracle Payables has introduced a new concurrent
program in release 11i to create the accounting entries
for the subledger transactions. It is called the Payables
Accounting Process. The process creates accounting
entries in all sets of books. When the program runs, it
produces an output report that has two sections - an
audit and an exceptions section. The audit section
shows the detail of all accounting entries created by the
process. The exception section shows the detail of any
accounting entries that were created with errors. This
might happen if the process finds that an account has
been de-activated in general ledger after the time it was
entered in the payables subledger.
Program parameters include a date range of
transactions to be accounted, and the document class to
be accounted (invoices, payments, or both). An optional
Validate Accounts parameter can be selected. If this
parameter is selected and if an accounting entry has an
account that is no longer valid in the general ledger,
then the accounting entry will receive an “accounted
with error” status. It is a good idea to select this option
because accounting entries with errors can be reviewed
and corrected before submitting the Payables Transfer
to General Ledger process. Another optional parameter
can summarize the audit section of the report. This is
useful when accounting for large volumes of data that
does not need to be reviewed in detail.
The process works as follows. First it checks the
accounting rules in the setup options. Then it locks the
transaction data to be accounted, based on the
parameters submitted to the concurrent program. The
next step is the creation of the accounting events for
each transaction to be accounted. Once the events are
created then the accounting for the events is created.
There is a sequencing to the accounting that is
managed by the program. For example, before a
payment can be accounted, the invoices on the payment
must be accounted. After the accounting entries are
created, they are validated against general ledger
accounts if that option was chosen. Then the
transactions are updated as accounted and the process
is complete.
One other thing to mention about the process is that
when it creates the accounting entries it assigns a
© Copyright 2000, by Oracle Corporation
journal category to each entry. When the Payables
Transfer to General Ledger is run it works by
transferring journal categories. The details are
explained in the section about transferring accounting
entries to gl.
Like other concurrent programs, the Payables
Accounting Process can be setup to run on a periodic
basis. The business needs of the accounting department
should be reviewed to determine how frequently to run
this process. Now that the Payables Transfer to General
Ledger simply transfers created accounting entries, the
Payables Accounting Process must be run before the
transfer can be run. This means that as often as the
transfer was run before, now both the accounting
process and the transfer need to be run. (The need to
account and transfer more often is likely if other Oracle
products like Assets and Projects are used. They require
that Payables data be transferred to general ledger
before it can flow to their interfaces).
There are two ways to link these processes to simplify
their submission. One way is within the Payables
Accounting Process. Two parameters can be used:
Submit Transfer to GL and Submit Journal Import. If
Yes is chosen for the Submit Transfer to GL parameter,
then the options set up in the Transfer to GL region of
the Payables Options window are called for this
submission. Based on those options it may or may not
be possible to choose to submit Journal Import. (See the
Setup section of this paper for detail). The second way
is to create a Request Set using standard Oracle
Applications functionality.
Oracle Payables also provides the option to create
accounting for a single transaction online from the
Invoices and Payments windows, or for an invoice or
payment batch from the Invoice Batches and Payment
Batches window. This option may be helpful when in a
testing phase or if a specific transaction needs special
processing.
New Accounting Inquiry and Update Forms
Now that Oracle Payables creates and stores accounting
in the subledger it is also possible to inquire on and
view the accounting created for payables transactions.
There is a new form provided in release 11i which
shows a variation of accounting information depending
on where the form is accessed.
A new main menu heading has been added to the
Oracle Payables navigator called “Accounting”. One of
the options in this menu is “View Accounting Lines”.
When this is chosen, the new View Accounting Lines
window opens. When called from the navigator it is
possible to inquire on any range of accounting data,
such as across documents, periods or accounts.
transferred to the general ledger interface. It did not
truly mean that the accounting had been posted. In
release 11i, Oracle Payables has tried to move away
from using the terms “post” or “posted” whenever
possible and instead refers to accounting as transferred
to general ledger. This has been done in order to be
more precise about what has happened with the
Payables transaction data.

Now in both the Invoices and Payments windows there

is a new field called “Accounted”. The value in this
field shows as “Yes”, “No”, or “Partial”. This helps
indicate that there is accounting available for view on a
transaction. Along with this the “Posted” field in the
Distributions subwindow of the main Invoices window
has been renamed “Accounted”. Most rules in prior
releases about whether or not a “posted” invoice or
payment could be adjusted now apply to an accounted
invoice or payment.
The data retrieved is displayed in the form of a
As covered in the section on the Payables Accounting
balanced accounting entry. It can also be viewed in a T-
Process, sometimes an accounting entry can be created
account format or in an alternate currency if using
with an accounting status of “Error”. In this case there
reporting sets of books.
is a new form available to allow correction of the error.
The form can be accessed from the navigator under the
Versions of this same window are available in the main
new Accounting menu heading. The menu path and
Payables transactions windows - Invoices and
window name are the same - Update Accounting
Payments. If opened in the Invoices window to see the
Entries.
accounting for an invoice transaction, the window title
is “View Invoice Accounting”. If opened in the
Typically this form is used when the Payables
Payments window to see the accounting for a payment
Accounting Process is run with the option to “Validate
transaction, the window title is “View Payment
Accounts”. If the process finds that any of the accounts
Accounting”. All of these windows use the standard
are not valid in general ledger then the accounting
Oracle Applications folder functionality, allowing them
entries are created with an error status, and appear on
to be easily modified to best suit the typical inquiry
the exceptions report. The report is reviewed and
needs of a business.
decisions are made as to how to correct the accounts.
There are a few fields to point out on the screenshot of
Then this new form is opened and the correct account
this inquiry window. In the lower right hand region
information is entered in the blank account field.
there is a field called “Event Type”. This displays the
accounting event that generated the particular
accounting line being viewed. Also in that same area is
a field called “Transferred to GL”. This displays a Yes
or No value depending on whether or not the
accounting line has been transferred to the general
ledger interface.

This last field is useful to point out because this

information is no longer found on the main Invoices
window. In prior releases there was a field in the
Invoices window called “Posted”. It would display Yes,
No, or Partial (if part of the invoice had been
transferred to general ledger). This terminology was a
bit problematic because what it really meant was
whether or not the accounting for the invoice had been

© Copyright 2000, by Oracle Corporation

The Update Accounting Entries form can also be used
as an inquiry form if desired.
Although encumbrance accounting is outside the scope
of this paper, one enhancement to point out in this area
is a new inquiry window made available in release 11i
to view the encumbrances for a particular invoice. The
new window is called View Encumbrances and can be
accessed via the navigator in the new Accounting menu
area. It can also be accessed via the Tools menu option
when in the Invoices window and inquiring on a
particular transaction.
This new window gives users better visibility into the
accounting for their encumbrance entries. This type of
inquiry was not available in Oracle Payables in prior
releases.
Transferring Accounting Entries to GL
As already noted, Payables Transfer to General Ledger
is a new process designed to transfer and optionally
summarize the accounting entries in the Payables
subledger to the general ledger interface.
The process works by transferring accounting data in a
selected date range and in a selected journal category.
The accounting entries are assigned a journal category
at the time they are created. This category can be
viewed in the accounting inquiry windows. There are
three journal categories: Purchase Invoices, Payments,
and Reconciled Payments. All of the invoice accounting
events are created with a journal category of Purchase
Invoices. All of the payment accounting events, except
for the payment clearing and the payment unclearing
events, are created with a journal category of Payments.
The payment clearing and unclearing events are created
with the journal category of Reconciled Payments.
There are several differences between the program
parameters in prior releases and the parameters in
release 11i. A new parameter - “Transfer Reporting
Book(s)” - has been added to simplify the transfer
process if MRC (Multiple Reporting Currencies) is
used. The “Post Through Date” parameter has been
replaced by two parameters - “From Date” and “To
Date”. The “To Date” parameter used alone works just
like the old parameter. However, now the two
parameters can be used together to transfer a more
precise range of accounting entries. The “Journal Entry
Category” parameter was renamed to the more accurate
“Journal Category”. The list of values displayed is the
list of the three types of Payables journal categories. A
new parameter, “Validate Accounts”, checks the
© Copyright 2000, by Oracle Corporation
accounting entries against the current account status in
general ledger. If invalid accounts are found, the entries
are not transferred. If this option is not used, then
Journal Import automatically validates the accounts.
All of the “Audit/No Audit” choices for all of the
account type parameters have been replaced by one
parameter called “Transfer to GL Interface”. Options
for this parameter are: In Detail, Summarize by
Accounting Date, and Summarize by Accounting
Period.
Once the data is transferred to the general ledger
interface, the process remains the same. The Journal
Import process takes the data in the interface and
creates unposted journal entry batches, headers, and
lines in Oracle General Ledger. From there the journal
entries can be posted to update the account balances.
Release 11i offers enhanced drill down capabilities
from Oracle General Ledger to the subledgers. As
mentioned earlier, it is now possible to transfer all
accounting entries in summary to gl, while still
retaining the ability to drill down from all accounts.
When viewing a journal with the source of Oracle
Payables, drill down to Oracle Payables can be chosen.
A new window has been created for the drill down, and
the window title and the information displayed vary
depending on which journal category is being reviewed.
The three window titles are: Payables Invoice
Accounting (from the Purchase Invoices category),
Payables Payment Accounting (from the Payments
category), and Payables Reconciled Payment
Accounting (from the Reconciled Payments category).
All of these windows use the standard Oracle
Applications folder functionality, allowing them to be
easily modified to best suit the typical inquiry needs of
a business. From these windows it is simple to drill
down to more detail - to view the transaction or to view
the transaction accounting.

Reports
Since the new accounting model affected all of the
accounting in Oracle Payables, any reports that
displayed accounting information in prior releases were
reviewed and changed as needed. Some new reports
were needed to support the new accounting model. And
some reports were made obsolete. A list of obsolete
reports can be found in the technical overview section.
The other reports are discussed here.
New Reports
Payables Accounting Process Report
This report is automatically produced by the Payables
Accounting Process. The audit section of the report
shows the detail of the accounting entries created by the
process. The exceptions section of the report shows the
detail of any accounting entries created with an error. It
is possible to run the report in a summarized version in
which case the audit section shows totals only.
Payables Accounting Entries Report
This report is similar to the output produced by the
Payables Accounting Process; however it can be run on
its own to report on accounting entries that meet
specific criteria. It allows greater flexibility in reporting
- for example it can be run just for accounting entries
that have or have not been transferred to general
ledger. It is also possible to run this report to get the
details of accounting entries created by a particular run
of the Payables Accounting Process. Similarly, this
report can be run to see the detail of what accounting
entries were transferred to GL during a particular run
of the Payables Transfer to General Ledger program.
Payables Transfer to General Ledger Report
The new transfer program automatically produces
report output. It has a summary section which gives
totals of the accounting entries transferred to the gl
interface. It has two sections which show exceptions:
one section shows accounting entries that could not be
transferred because they were in an error status, and the
second shows accounting entries that were accounted
with no problem but are now unable to be transferred
due to a discrepancy between the accounted account
and the account in the general ledger.
© Copyright 2000, by Oracle Corporation
This report does not produce an audit section of the
detail that has been transferred to the general ledger. If
that information is needed, then the Payables
Accounting Entries Report can be run for a particular
submission of the Payables Transfer to General Ledger
to get the audit detail.
The report output from the new transfer replaces the
Accounts Payable Journal Entry Audit and Exception
Reports.
Unaccounted Transactions Report
This new report is available to help review problems
with invoices and payments which can not have
accounting created for them due to some problem. It
will be useful to review this report after running the
Payables Accounting Process in order to see what
transactions could not be accounted and why.
The report is organized by the reason why accounting
can not be created. For example, invoices must be
approved by the Payables Approval process before they
can be accounted. So invoices that have not yet been
approved are grouped together on this report with the
exception of “Unapproved”. This report also shows
transactions that have holds that do not allow
accounting. Note that holds which did not allow
posting in prior releases now do not allow accounting
in release 11i.
This report replaces the Posting Holds Report. It
improves upon the old report in several ways. One way
is that it shows both invoice and payment transactions
rather than just invoices. For example, if a payment can
not be accounted due to a missing exchange rate, that
transaction is identified by this report.
Payables Account Analysis Report
This report was created to assist with review of
accounting created in the Payables subledger and to
assist with reconciliation of accounts to the general
ledger. It can be submitted for an accounting date range
and for a full account segment range.
This report replaces the Expense Distribution Detail
Report. The new report does not need a setup form as
the Expense Distribution Detail Report did.
Changed Reports
Accounts Payable Trial Balance
The Accounts Payable Trial Balance is actually a new
report but since the name is the same it is included in
the changed reports section. The new accounting model
made it necessary to rewrite the trial balance report. All
of the enhancements that had been outstanding against
the report were reviewed and incorporated into the new
report. For example, there is now an option to run the
report for a single supplier. There is also an option to
run the report for a single liability account.
Posted Invoice Register
This report was modified to report off the new
accounting entries which have been transferred to
general ledger. This (along with the Posted Payment
Register) was one of the cases where the use of the
word “posted” was retained in 11i. Although
technically the accounting in this report has only
transferred to general ledger and not necessarily been
posted, the existing report name seemed like the
simplest to use.
All of the enhancements that had been outstanding
against the report were reviewed and incorporated into
the new report. For example, there is now an option to
run the report for a single liability account. There is
also an option to run the report in summary in order to
get totals for reconciliation purposes.
Posted Payment Register
This report was modified to report off the new
accounting entries which have been transferred to
general ledger. All of the enhancements that had been
outstanding against the report were reviewed and
incorporated into the new report. For example, there is
now an option to run the report for a single liability
account. There is also an option to run the report in
summary in order to get totals for reconciliation
purposes.
New Close Process
The process to close an accounting period has changed
in release 11i. The close process is reviewed here in
order to compare it with the close process in prior
releases. The form to control the status of an
accounting period has been renamed from “AP
Accounting Periods” to “Control Payables Periods”. Its
location in the navigator has also changed. It has
moved from the Setup section into the new Accounting
section of the menu. The rules to close a period in
Payables in release 11i are:
. All payment batches must be confirmed
© Copyright 2000, by Oracle Corporation
. All transactions must be accounted
. All accounting entries must be transferred to general
ledger
. All future dated payments which have reached
maturity in the accounting period must have their status
updated to negotiable and be accounted
Optionally, unaccounted transactions can be swept to
the next accounting period if allowed by accounting
rules. There is a new program in 11i to support this -
the Unaccounted Transactions Sweep. This program
can be submitted from the Control Payables Periods
form in both a review mode and an update mode. The
program can be called only if there are any
unaccounted transactions in the period. The report
output of the program looks very much like the
Unaccounted Transactions Report. This new program
replaces the Unposted Invoice and Payment Sweep.
Before invoices can be accounted they must be
approved by the Payables Approval process. Before
payments can be accounted they must pass through the
Confirm process. Typical steps to close a period in
Payables release 11i are:
. Import all invoices and/or expense reports from
interface tables
. Run Approval
. Confirm any outstanding payment batches
. Run the Update Matured Future Payment Status
program for any future dated payments
. Run the Payables Accounting Process
. Review the accounting process output and correct
any accounting errors
. Review the Unaccounted Transactions Report to
identify transactions which cannot be accounted
. Correct any transaction data and run the Payables
Accounting Process again
. Review the Payables Account Analysis Report
(If someone reviewed the Expense Distribution Detail
Report for certain accounts in prior releases they will
want to review this new report in 11i)
. Run the Payables Transfer to General Ledger
. Optionally run the Unaccounted Transactions Sweep
. Close the Payables period
. Reconcile
Technical Overview
This section is an overview of the architectural changes
made to Oracle Payables to support the new accounting
model. It is not an exhaustive discussion of all the
changes made to the product, but it should serve as a
reference point for understanding the major changes. It
should also help in understanding what the upgrade
process does and if there is impact to any custom code a
business might have.
The key data model changes revolve around the fact
that now accounting entries are created and stored in
the Payables subledger. Prior to release 11i, data from
three tables was used to create accounting entries in the
general ledger interface:
AP_INVOICE_DISTRIBUTIONS_ALL,
AP_PAYMENT_DISTRIBUTIONS_ALL, and
AP_RECON_DISTRIBUTIONS_ALL
(Refer to Diagram 1 at the end of this paper for a view
of the release 11 data model.)
Now in release 11i, three new tables are used to hold
the accounting entries created in Payables:
AP_ACCOUNTING_EVENTS_ALL,
AP_AE_HEADERS_ALL, and AP_AE_LINES_ALL.
These tables are populated by the Payables Accounting
Process. The process creates accounting entries for
every set of books (combined basis accounting or
MRC). Data from these tables is now transferred to the
general ledger interface. There is another new table
which has been added to help track the activity on a
payment: AP_PAYMENT_HISTORY. This table holds
all the information for determining the payment
maturity, payment clearing, and payment unclearing
events.
(Refer to Diagram 2 at the end of this paper for a view
of the release 11i data model.)
Upgrade
The upgrade to release 11i converts the data in the
three distributions tables into accounting entry data in
the new tables. The tables
AP_PAYMENT_DISTRIBUTIONS_ALL and
AP_RECON_DISTRIBUTIONS_ALL are obsolete in
release 11i, although they are not dropped.
New Tables
AP_AE_HEADERS_ALL
AP_AE_LINES_ALL
AP_ACCOUNTING_EVENTS_ALL
AP_ENCUMBRANCE_LINES_ALL
AP_PAYMENT_HISTORY_ALL
AP_MC_PAYMENT_HISTORY
AP_TRIAL_BAL
New Forms
© Copyright 2000, by Oracle Corporation
Update Accounting Entries (APXUPDAE)
View Encumbrances (APXVWENC)
View Accounting Lines
View Invoice Accounting
View Payment Accounting
The three above are different views of the form
XLAIQACL
Payables Invoice Accounting
Payables Payment Accounting
Payables Reconciled Payment Accounting
The three above are different views of the form
XLAIQDRL
Obsolete Tables
AP_PAYMENT_DISTRIBUTIONS_ALL:
Used to hold payment accounting information. The
table was populated when a manual or quick payment
was entered or a payment batch was confirmed.
AP_MC_PAYMENT_DISTS_ALL:
Used to hold payment accounting information for
reporting sets of books (MRC).
AP_RECON_DISTRIBUTIONS_ALL:
Used to hold payment reconciliation information. The
table was populated when a payment was cleared or
reconciled in Oracle Cash Management.
AP_MC_RECON_DISTS_ALL:
Used to hold payment reconciliation information for
reporting sets of books (MRC).
AP_TRIAL_BALANCE:
Used to hold information for the Accounts Payable
Trial Balance report.
AP_MC_TRIAL_BALANCE:
Used to hold information for the Accounts Payable
Trial Balance report when run from a reporting set of
books (MRC).
Obsolete Forms
Invalid GL Accounts (APXPDFIX):
Used to correct invalid account information and
payment distributions. Effectively replaced by the
Update Accounting Entries form.
Invoice Distributions Summary (APXGLINQ):
Used as a way to look at accounting for invoice
distributions. Replaced by View Accounting Lines
window.
New Reports and Programs
(see Reports section for details)
Obsolete Reports and Programs
Payables Transfer to General Ledger (APPPST)
Unposted Invoice and Payment Sweep (APXSUMPS)
Accounts Payable Trial Balance (APXRTB)
Expense Distribution Detail Report (APXEDSRS)
Transaction Reconciliation Report (APXTRXRN)
Journal with GL Details Report (APXJEHIS)

Other Changes

The posted flag in the table

AP_INVOICE_DISTRIBUTIONS_ALL now means
that the distribution has been accounted. To see if an
accounting entry has been transferred to general ledger
look at the transferred flag in the AP_AE_LINES_ALL
table.

Conclusion
The new accounting model in Payables 11i has
dramatically changed the way accounting works in the
subledger. It is important to review and understand
these changes in order to make a smooth transition to
the new release.

This paper provides an overview of the new accounting

model and some details for the setup and accounting
entries created in the subledger. The reference
documentation should also be reviewed to ensure an
understanding of how to manage accounting in release
11i.

The new flexible accounting entries should prove

beneficial to users of Oracle Payables. Now the product
has an improved architecture to support building other
accounting enhancements in future releases.

About the Author

Lauren Scott is Senior Product Manager for the Oracle

Payables product. She has been working with Oracle
Financials since 1988, first as a user and then in
product development since 1997. She managed
Oracle’s US Payables and Fixed Assets operations for
six and a half years before moving to Applications.

© Copyright 2000, by Oracle Corporation

 Diagram 1 - R11 Physical Data Model

AP_TRIAL_BALANCE
(Accounts Payable Trial
Balance)

AP_CHECKS_ALL
(Payments)

AP_INVOICES_ALL
(Invoices)

AP_RECON_
DISTRIBUTIONS_ALL
(Reconciled Payments)

AP_PAYMENT_
SCHEDULES_ALL
(Scheduled Payments)

AP_INVOICE_ Transfer Program

AP_INVOICE_ PAYMENTS_ALL
DISTRIBUTIONS_ALL (Invoice Payments)
(Invoice Distributions)

GL_JE_BATCHES
Transfer Program (Journal Batches)

Transfer Program
AP_PAYMENT_
DISTRIBUTIONS_ALL
(Payment Distributions)

Transfer Program GL_JE_HEADERS

(Journal Headers)

GL_INTERFACE
(General Ledger Interface)

Journal Import

GL_IMPORT_
GL_JE_LINES
REFERENCES
(Journal Lines)
(Drilldown Link)

Journal Import

Journal Import

© Copyright 2000, by Oracle Corporation

 Diagram 2 - R11i Physical Data Model

AP_INVOICES_ALL
(Invoices)

AP_CHECKS_ALL
(Payments)

AP_INVOICE_ AP_PAYMENT_
DISTRIBUTIONS_ALL SCHEDULES_ALL
(Invoice Distributions) (Scheduled Payments)

AP_PAYMENT
HISTORY_ALL
(Payment History)

AP_ACCOUNTING
EVENTS_ALL AP_INVOICE_
(Accounting Events PAYMENTS_ALL
(Invoice Payments)

GL_JE_BATCHES
(Journal Batches)

Journal Import
AP_AE_HEADERS_ALL
(Accounting Entry
Headers)

GL_INTERFACE GL_JE_HEADERS
(General Ledger Interface) (Journal Headers)
Transfer Program Journal Import

AP_AE_LINES_ALL
(Accounting Entry Lines)
Journal Import
GL_IMPORT_ GL_JE_LINES
REFERENCES (Journal Lines)
(Drilldown Link)

© Copyright 2000, by Oracle Corporation