how do you account for that - oracle payables 11i

© Copyright 2000, by Oracle Corporation

How Do You Account for That? - Oracle Payables 11i

Lauren ScottOracle Corporation

Introduction

In release 11i, Oracle Payables introduces a newaccounting model to support the creation and retentionof accounting entries in the Payables subledger. Thispaper discusses why this change was made, and how itaffects the accounting and period close processes inPayables. This paper is primarily an overview of thenew functionality, however, a review of thefunctionality in previous releases is provided as a basisfor reference. Examples of the accounting entriescreated by the new model in release 11i are provided. Abrief technical overview of the key data model changesis provided at the end of this paper.

This paper should be most useful to current users ofOracle Payables who are interested in understandingthe accounting changes made in release 11i and whowant to plan for their upgrade to the new release.

Scope of This Paper

This paper describes accounting in the Oracle Payablessubledger and integration with Oracle General Ledger.Accounting transactions where Oracle Payablesintegrates with other subledgers are not in the scope ofthis paper. Transferring accounting data to non-Oraclegeneral ledgers is not in the scope of this paper. A goodfamiliarity with the Oracle Payables product is assumedas features referenced are not described in detail unlessthey are new to the accounting model.

This paper assumes accrual basis accounting for itsdiscussion. Where relevant, a mention of theaccounting impact for cash basis accounting isincluded, but only where specifically noted.

Other features which have accounting impact but areoutside of the scope of this paper include:. Encumbrance accounting. Automatic Offsets. Accrual on receipt. Tax accounting. Future dated paymentsWhere relevant, a mention of the accounting impact ofone of these features may be made, but only wherespecifically noted.

How Do You Account for That? - BusinessReasons Behind the Change

The new accounting architecture that Oracle Payableshas introduced with release 11i allows for moreflexibility as new features are introduced in futurereleases. However, these changes in 11i were not madejust for the purpose of improving the productarchitecture. There were many functionalenhancements in the area of accounting which OraclePayables development had been asked to make, andmany of them were not possible without this kind ofarchitectural foundation.

For example, there were desired enhancements in thearea of prepayment functionality that needed to bemade. Prior to release 11i, the application of aprepayment created some less than desirable accountingsuch as creating an accounting entry for the cashaccount. This and other problems could be addressedwith the new accounting model.

Another area which needed enhancement was thefuture dated payment functionality. Issues included theinability to cleanly account for the maturity of a futuredated payment, and the inability to simultaneously usethe future dated payment feature and create accountingwhen a payment was cleared or reconciled.

General improvements needed to be made to theaccounting that Payables created. For example, inrelease 11i, there is now a single accounting entrycreated to accounts such as liability, cash clearing,cash, and discount (if system level). Prior to thisrelease, one accounting entry was created to theseaccounts corresponding to each invoice distribution.This was somewhat cumbersome and madereconciliation more difficult for users.

Another business reason behind the change was thesupport of improvements in accounting for currencygains and losses. Some countries needed to be able toaccount for gain or loss only at the time of paymentclearing. Prior to the new accounting model in release11i, this would have been very difficult to support.Another enhancement in this area is support for thecalculation of gain or loss at the desired level. Oracle


Payables can now support the calculation at thepayment level or the payment line level.This is not an exhaustive overview of all the businessreasons for the introduction of this new accountingarchitecture, but it should serve to point out that thereare some important benefits to users of the OraclePayables product. This change is also consistent withthe future direction of Oracle Financials. In futurereleases all of the subledgers which create accountingwill move to this new subledger accounting model.Oracle Payables development will also be doing morework in this area to improve and enhance thearchitecture it now has in release 11i.

Review of Accounting in Prior Releases

A review of the way accounting works in Payables priorto release 11i is included here to serve as a basis forunderstanding the new accounting model discussed inthe following sections. When there are references tospecific forms, fields, reports, or programs, they are therelease 11 names.

Before 11i, there is no accounting in the Payablessubledger. Accounting information is inherent in aPayables document, but there is not always a way to seethe information (for example, an invoice price variancefor a purchase order matched invoice). Accounting forPayables transactions is created by a concurrent process- the Payables Transfer to General Ledger program.This is a very complex program which pullsinformation out of the transaction tables, createsaccounting entries, and places them in the gl interface.From there the general ledger process Journal Importcreates journal entries and imports them as unpostedjournal entries into Oracle General Ledger.

There are some setup options to point out which controlvarious aspects of the accounting which is created.

In the Accounting region of the Payables Options setupwindow there are two options in the Cash Clearingregion. The first is called “Allow ReconciliationAccounting”. If this is enabled, it means that if OracleCash Management is used to clear and/or reconcilepayments, accounting entries are created for thosereconciled payments.

The other is called “Allow Future Payment Method”. Itis not possible to select both of these options becausefuture dated payments use the account setup as the cashclearing account. Although future dated payments areoutside the scope of this paper this is worth pointingout since this is not the case in 11i. In 11i a separateaccount is supported for future dated payments so thisoption is not needed.

Also worth noting in this Accounting region is thesetup area called “Journal Entry Creation”. This setupcontrols defaults for the submission of the PayablesTransfer to General Ledger process for how it createsentries in the gl interface. For the accounts in this setupregion it is possible to specify an “Audit” or “NoAudit” option. The Audit option means that theaccounting information is created in detail in the glinterface, and this in turn means that drill down isavailable from the journal entries in Oracle GeneralLedger back to the details in the Payables subledger.The No Audit option creates summary entries, and drilldown is not available. (Note that there is a setup step inOracle General Ledger to enable drill down. TheImport Journal References option must be enabled inthe Journal Sources window for Payables.)

Although the drill down functionality provides somegood accounting detail there is not the oppositefunctionality in Payables. That is, it is not possible toinquire on a particular transaction and easily see theaccounting for that transaction.

The process to close an accounting period has alsochanged in release 11i, so a review of that process isalso provided here. The rules to close a period inPayables 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 ledgerBefore invoices can be transferred to general ledgerthey must be approved by the Payables Approvalprocess. Before payments can be transferred to generalledger they must pass through the Confirm process.Typical steps to close a period in Payables are:


. Import all invoices and/or expense reports frominterface tables

. Run Approval

. Review the Posting Holds Report to identify invoiceswhich 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 accountsbefore they close a period; they can identify andcorrect any issues prior to their close)

. Confirm any outstanding payment batches

. Run the Payables Transfer to General Ledgerprogram. Optionally run the Unposted Invoice and Payment

Sweep (some accounting rules allow this - others donot)

. 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 storesaccounting entries in the subledger. Accounting entriesare created based on a particular accounting event, forexample, the creation of an invoice, or the payment ofan invoice. These accounting entries are available forview and analysis even before they are transferred tothe general ledger. There is a new program to createthe accounting entries - the Payables AccountingProcess.

The Payables Transfer to General Ledger is a newprogram. Although it retains the same name, it is anew, much simpler program. It is now truly just atransfer program. It takes the accounting entries createdin Payables and transfers them to the general ledgerinterface, with the capability of doing summarization ifdesired. The general ledger Journal Import processremains the same.

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

Setup

Oracle Payables has some new and some changed setupwhich controls how accounting works in release 11i.The core of the changes is in the Payables Options form

in three regions: Accounting Methods, Transfer to GL,and Payment Accounting.

Accounting Methods

This region corresponds to the Accounting region inrelease 11. Notice that the section with the accountaudit options has been removed. With the newaccounting model, these options are no longer needed.When the accounting entries are transferred to the glinterface, a link is automatically created. This meansthat full drill down to the payables accounting entries isalways available from Oracle General Ledger, nomatter the level of summarization. (Note that the sameImport Journal References option in Oracle GeneralLedger must be enabled to allow drill down.)

The upgrade from a prior release to 11i retains thesetup in place for the accounting method/s.

Transfer to GL


This new region controls the default values for theparameters of the Payables Transfer to General Ledgerprogram. This assists users in ensuring that theyconsistently transfer their accounting entries to thegeneral ledger interface in the same way. If the “AllowOverride at Program Submission” parameter isdisabled, then an accounting manager can safelydelegate the submission and monitoring of this processto staff while still ensuring control.

Also, those who use the MRC (Multiple ReportingCurrencies) feature in release 11i can transferaccounting entries for the reporting sets of books andthe primary set of books at the same time.

Payment Accounting

This new region controls various options for theaccounting of payments. The Account for Paymentoption controls the timing of when accounting iscreated for a payment. There are three optionsavailable:. When Payment is Issued. When Payment Clears. or both can be selectedIf both options are selected then the same functionalityis provided as in prior releases when the “AllowReconciliation Accounting” feature was enabled. Thatis, accounting will be created at both the time thepayment is issued and at the time when the payment iscleared and/or reconciled in Oracle Cash Management.The upgrade from a prior release to 11i enables both ofthese options if the “Allow Reconciliation Accounting”feature was enabled.

The Account for Gain/Loss setup controls the timing ofwhen accounting is created for the recognition of gainor loss on a payment transaction.There are three options available:

. When Payment is Issued

. When Payment Clears

. or both can be selectedThis setup has dependencies on the Account forPayment setup and vice versa. For example, if theAccount for Payment When Payment is Issued option isnot chosen then the Account for Gain/Loss WhenPayment is Issued can not be chosen.

The Calculate Gain/Loss setup controls the calculationlevel for the accounting entry for any gain or loss on apayment transaction.There are two options available:. For Each Invoice. For Total PaymentPrior to release 11i, Payables did not offer this choice.Gain or loss was calculated for each invoice on apayment. The upgrade from a prior release does notautomatically choose one of these options - it is left tothe user to determine what is appropriate for his or herbusiness.

A detailed discussion of the setup relevant to FutureDated Payments is out of the scope of this paper.

Accounting Events

The 11i Payables accounting model uses the newconcept of accounting events. An accounting event isan event that might require accounting for atransaction, for example, a payment. The type of eventcontrols the accounting that is created for a transactionand how that accounting appears in the subledger.

The eleven accounting events in Payables are dividedinto two document classes, invoices and payments. Youcan specify a document class when you create or viewaccounting entries.

The accounting events for the invoice document classare:. Invoice Event. Invoice Adjustment Event. Invoice Cancellation Event. Prepayment Application Event. Prepayment Unapplication EventThe accounting events for the payment document classare:. Payment Event. Payment Maturity Event. Payment Adjustment Event. Payment Cancellation Event. Payment Clearing Event


. Payment Unclearing Event

Invoice Event

The invoice event occurs when a new, approved invoiceis accounted. This event creates accounting entries foreach of the accounts associated with the invoicedistributions and to the liability account of the invoice.

The accounting entry created for a simple invoice withone distribution in the functional (accounting) currencyis:

Account Debit CreditCharge 100AP Liability 100

The accounting entry created for an invoice withmultiple distributions in the functional currency is:

Account Debit CreditCharge 100Charge 50Charge 50AP Liability 200

Note the summarized entry to the liability account. Thisis an enhancement in release 11i. This is different inthe case of using the automatic offsets feature. If theautomatic offsets feature is used, then the same invoiceexample above yields the following accounting entry:

Account Debit CreditCharge (Co 01) 100Charge (Co 02) 50Charge (Co 03) 50AP Liability (Co 01) 100AP Liability (Co 02) 50AP Liability (Co 03) 50

If an invoice is entered in foreign currency, theaccounting entries for the invoice event are created inboth the foreign and functional currency. The followingexample assumes an invoice for 200 foreign currencyunits (FX) which converts to 300 in functional currencyunits (exchange rate of 1.5):

Account Debit(FX)

Credit(FX)

Debit Credit

Charge 100 150Charge 50 75Charge 50 75

AP Liability 200 300

There are many other examples of accounting for aninvoice event, but one other to point out here is theaccounting created for an invoice matched to apurchase order when accrual on receipt is used. Thefollowing example assumes an invoice for one itemwith an invoice price of 105 and a purchase order priceof 103:

Account Debit CreditAP Accrual 103Invoice Price Variance 2AP Liability 105

Now with the ability to view the accounting for aninvoice event online in Oracle Payables, users are ableto see this complete entry for their invoice transaction.

Invoice Adjustment Event

The invoice adjustment event typically occurs when anaccounted invoice is adjusted in some way. Anexample of a common adjustment is reversing onedistribution line entered in error to an incorrect chargeaccount and entering a correcting line. This eventcreates accounting entries for the adjusting lines.

The accounting entry created for a simple invoiceadjustment in the functional currency is:

Account Debit CreditCharge (in error) 100Charge (correction) 100

Another example of an adjustment is the case where anincrease is needed to the amount of an invoice, and theincrease is charged to one or more associated chargeaccounts. The accounting for an adjustment to increasean invoice by 100 looks just like the accounting for aninvoice event:


The accounting date (GL date) is part of what controlshow events are accounted. If an invoice is entered withmultiple distribution lines, and some of the distributionlines have different accounting dates, then the lineswith the earliest accounting date are accounted as an


invoice event while the lines with the later accountingdate are accounted as an invoice adjustment event.

Invoice Cancellation Event

The invoice cancellation event occurs when anaccounted invoice is cancelled. The cancellationfeature automatically adjusts the invoice amount tozero, and reverses all invoice distribution lines. If theinvoice lines were matched to a purchase order, thematch is also reversed.

The accounting entry created for the cancellation of asimple invoice with one distribution in the functionalcurrency is:


To understand other examples of accounting for theinvoice cancellation event, the invoice event accountingexamples can be reviewed. Note that a correspondinginvoice cancellation event would effectively reverse theaccounting 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 isinvolved.

Prepayment Application Event

This event accounts for the application of a prepaymentto an invoice. It is helpful to provide the accountingevent sequence for a typical prepayment entry, invoiceentry, and then prepayment application to make theevents clear in this case. The following example is a500 prepayment which is paid and then applied to a1000 invoice as a partial payment.

The entry of a prepayment into Oracle Payables isaccounted as an invoice event since a prepayment ismodeled as a type of invoice.

Account Debit CreditPrepaid Expense 500AP Liability 500

Without discussing the payment event, note that thepayment of the prepayment relieves the liability in thiscase so that 500 remains in the prepaid expenseaccount.

The next event is the entry of the invoice to which theprepayment is applied. The accounting process firstcreates the invoice event even if the prepayment hasalready been applied:

Account Debit CreditCharge 600Charge 200Charge 200AP Liability 1000

Next the prepayment application event is created:

Account Debit CreditAP Liability 500Prepaid Expense 500

The prepayment application event relieves the liabilityaccount for the amount of the applied prepayment, andit credits the prepaid expense account for the amountapplied.

For anyone familiar with the accounting of prepaymentapplications in prior releases, it is clear that theaccounting in release 11i is improved.

Note that although this event is modeled as part of thedocument class of invoices, this event does exist in cashbasis accounting. The reason for this is that theprepayment application is effectively a payment (partialor full) of the invoice to which it is applied.

Prepayment Unapplication Event

This event accounts for the unapplication of aprepayment to an invoice. Just as a prepayment can beapplied to an invoice, there is also a way to unapplythat prepayment. If this is done, then accounting entriesare created to reverse the accounting of the prepaymentapplication.

The accounting for the unapplication of the prepaymentapplied in the example above is:

Account Debit CreditPrepaid Expense 500AP Liability 500

Payment Event


The payment event occurs when a new payment isissued and accounted. This event creates accountingentries to relieve the liability of the invoice and tocharge the cash clearing or cash account, depending onthe system setup options.

This event occurs when the Payment Accounting option“Account for Payment When Payment is Issued” isenabled. If the system is set up to account for any gainsor losses at the time of payment issue, this accountingevent also creates those accounting entries. For thefollowing examples, assume that the setup used is toaccount for payments at both issue and clearing, and toaccount for gain or loss at the same time.

The accounting entry created for the payment of asimple invoice in the functional (accounting) currencyis:

Account Debit CreditAP Liability 100Cash Clearing 100

If an invoice is entered and paid in foreign currency,there may be a currency gain or loss realized at the timeof accounting for the payment event. In the foreigncurrency example in the invoice event section, theinvoice was for 200 foreign currency units (FX) whichconverted to 300 in functional currency units (exchangerate of 1.5). Using the same example, now the paymentis made for 200 foreign currency units (FX) whichconverted to 340 in functional currency units (exchangerate of 1.7). The accounting entries are created in bothcurrencies by the payment event:

Account Debit(FX)

Credit(FX)

Debit Credit

AP Liability 200 300Realized Loss 40Cash Clearing 200 340

Accounting for discounts is also handled by this event.This example assumes that the discount method is thesystem account. This is an example of a payment for aninvoice in the functional currency, where the invoiceamount is 200 and a discount of 18 is taken. Thisexample is for the payment of an invoice which hasmultiple invoice distributions.

Account Debit CreditAP Liability 200Cash Clearing 182

Discount Taken 18

Note the summarized entries to the cash clearing anddiscount accounts. This is an enhancement in release11i. This is different in the case of using the automaticoffsets feature. If the automatic offsets feature is used,then a similar payment event yields the followingaccounting entry:

Account Debit CreditAP Liability (Co 01) 100AP Liability (Co 02) 100Cash Clearing (Co 01) 91Cash Clearing (Co 02) 91Discount Taken (Co01)

9

Discount Taken (Co02)

9

There are many other examples of accounting for apayment event, but one other to point out here is theaccounting created for multiple payments made for thesame foreign currency invoice. When the final paymentis made on an invoice, Payables ensures that theliability is fully relieved, even if the sum of thefunctional currency amounts of the payments does notadd up to the functional currency amount of theliability. This is handled by creating the necessary entryto the rounding account. This example is for an invoicein the amount of 20.08 foreign currency units (FX)converted to 2.01 functional currency units. So theliability for the invoice was booked as 2.01.

A first payment is made for the invoice in the amountof 10.04 foreign currency units (FX) converted to 1.00functional currency units and accounted as follows(assume no gain or loss for simplicity):

Account Debit(FX)

Credit(FX)

Debit Credit

AP Liability 10.04 1.00Cash Clearing 10.04 1.00

A second payment is made for the invoice in theamount of 10.04 foreign currency units (FX) convertedto 1.00 functional currency units and accounted asfollows:

Account Debit(FX)

Credit(FX)

Debit Credit

AP Liability 10.04 1.00Cash Clearing 10.04 1.00AP Liability .01


Rounding .01

Payables creates the last two entries when it finds thatthe second payment is the final payment and yet the full2.01 of the liability is not relieved.

Payment Maturity Event

The payment maturity event occurs only for futuredated payments and if the system setup is to account forpayments at issue time. When future dated paymentsare issued, they are accounted by the payment event,just as for standard payments. The payment maturityevent happens when the future dated payments reachtheir maturity - that is, they become negotiabledocuments.

To understand the accounting created by the paymentmaturity event, first an example is needed of theaccounting for the payment event of a future datedpayment. Here is the accounting for a simple 100payment in the functional currency:

Account Debit CreditAP Liability 100Future Dated Payment 100

Note that rather than hitting a cash clearing or cashaccount, the accounting for the issue of a future datedpayment is entered to the designated future datedpayment account. The amount is held in this accountuntil the payment becomes negotiable.

When the payment status changes from “Issued” to“Negotiable” then the payment maturity event occursand is accounted as follows:

Account Debit CreditFuture Dated Payment 100Cash Clearing 100

Now that the future dated payment is negotiable, thefuture dated payment account is relieved and theappropriate entry is made to the cash clearing account.

Payment Adjustment Event

A payment adjustment event occurs when any of theinvoices recorded as paid by a manual payment arechanged. Payables has a feature which allows this typeof adjustment. If an adjustment like this is made, thenthe accounting event creates reversals of the accountingdone when the original payment of the invoices was

accounted. This includes any gains or losses, discounts,etc. Then the event creates new payment accounting forthe newly paid invoice or invoices.

The following illustrates the accounting that takes placeduring a payment adjustment event. The starting pointis the existing accounting created when an invoice wasrecorded paid by a manual payment. This example usesthe same foreign currency invoice and payment fromthe 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 200foreign currency units (FX) which converted to 340 infunctional currency units (exchange rate of 1.7). Theaccounting entries were created in both currencies bythe payment event:

Account Debit(FX)

Credit(FX)

Debit Credit

AP Liability 200 300Realized Loss 40Cash Clearing 200 340

Now it is realized that the invoice recorded by thismanual payment was recorded in error. It happenedthat the invoice selected was for the same 200 amountas the invoice that should have been recorded. Usingthe Payables adjustment functionality, the incorrectinvoice (1) is selected to be returned to unpaid status,and the invoice which should have been recorded aspaid (2) is now correctly recorded. The accounting forthe event is:

Account Debit(FX)

Credit (FX)

Debit Credit

AP Liability (1) 200 300Realized Loss (1) 40Cash Clearing(1)

200 340

AP Liability (2) 200 300Realized Loss (2) 40Cash Clearing(2)

200 340

Payment Cancellation Event


This event creates accounting entries for the void of apayment. A void of a payment cancels the paymentdocument and sets the invoices on the payment back tounpaid status. The accounting entries generated are theopposite of what are created for a payment event.

Here is the example of a 182 payment and 18 discounttaken (discount charged to a system account):

Account Debit CreditAP Liability 200Cash Clearing 182Discount Taken 18

If this payment is voided, and then accounting iscreated, the accounting for the payment cancellationevent appears as follows:


Payment Clearing Event

The payment clearing event occurs when a payment iscleared or reconciled in Oracle Cash Management, andthe system is set up to account for payments when theyclear (one of the payment accounting options reviewedin the Setup section).

Here is an example of the accounting created at bothpayment issue and payment clearing. Accounting atpayment issue for a 182 payment with a 18 discounttaken (discount charged to a system account):


Now at the time of payment clearing the accountingentry created is:

Account Debit CreditCash Clearing 182Cash 182

Effectively this accounting moves the cleared orreconciled payment out of the cash clearing accountand debits the cash account now that the cash has beenissued by the bank.

This accounting event may also handle any accountingfor currency gains or losses. If setup is such that thereis no accounting for gain or loss at the time a paymentis issued, but rather only at the time a payment clears,then the accounting for the payment clearing eventcreates the necessary accounting entries.

In the foreign currency example in the invoice eventsection, the invoice was for 200 foreign currency units(FX) which converted to 300 in functional currencyunits (exchange rate of 1.5). Using the same example,now the payment is made for 200 foreign currencyunits (FX) at the same conversion rate since no gain orloss will be calculated until the payment clears. Theaccounting entries are created in both currencies by thepayment event:

Account Debit(FX)

Credit(FX)

Debit Credit

AP Liability 200 300Cash Clearing 200 300

When the payment clears, the 200 foreign currencyunits are converted to 340 in functional currency units(exchange rate of 1.7). The accounting entries arecreated in both currencies by the payment clearingevent:

Account Debit(FX)

Credit(FX)

Debit Credit

Cash Clearing 200 300Realized Loss 40Cash 200 340

Payment Unclearing Event

The payment unclearing event occurs when a cleared orreconciled payment is reversed in Oracle CashManagement - in effect the payment is “uncleared”.The accounting entries created simply back out theaccounting created by the payment clearing event.If at the time of payment clearing the accounting entrycreated was:


Now at the time of the payment unclearing theaccounting created is:



Payables Accounting Process

Oracle Payables has introduced a new concurrentprogram in release 11i to create the accounting entriesfor the subledger transactions. It is called the PayablesAccounting Process. The process creates accountingentries in all sets of books. When the program runs, itproduces an output report that has two sections - anaudit and an exceptions section. The audit sectionshows the detail of all accounting entries created by theprocess. The exception section shows the detail of anyaccounting entries that were created with errors. Thismight happen if the process finds that an account hasbeen de-activated in general ledger after the time it wasentered in the payables subledger.

Program parameters include a date range oftransactions to be accounted, and the document class tobe accounted (invoices, payments, or both). An optionalValidate Accounts parameter can be selected. If thisparameter is selected and if an accounting entry has anaccount that is no longer valid in the general ledger,then the accounting entry will receive an “accountedwith error” status. It is a good idea to select this optionbecause accounting entries with errors can be reviewedand corrected before submitting the Payables Transferto General Ledger process. Another optional parametercan summarize the audit section of the report. This isuseful when accounting for large volumes of data thatdoes not need to be reviewed in detail.

The process works as follows. First it checks theaccounting rules in the setup options. Then it locks thetransaction data to be accounted, based on theparameters submitted to the concurrent program. Thenext step is the creation of the accounting events foreach transaction to be accounted. Once the events arecreated then the accounting for the events is created.There is a sequencing to the accounting that ismanaged by the program. For example, before apayment can be accounted, the invoices on the paymentmust be accounted. After the accounting entries arecreated, they are validated against general ledgeraccounts if that option was chosen. Then thetransactions are updated as accounted and the processis complete.

One other thing to mention about the process is thatwhen it creates the accounting entries it assigns a

journal category to each entry. When the PayablesTransfer to General Ledger is run it works bytransferring journal categories. The details areexplained in the section about transferring accountingentries to gl.

Like other concurrent programs, the PayablesAccounting Process can be setup to run on a periodicbasis. The business needs of the accounting departmentshould be reviewed to determine how frequently to runthis process. Now that the Payables Transfer to GeneralLedger simply transfers created accounting entries, thePayables Accounting Process must be run before thetransfer can be run. This means that as often as thetransfer was run before, now both the accountingprocess and the transfer need to be run. (The need toaccount and transfer more often is likely if other Oracleproducts like Assets and Projects are used. They requirethat Payables data be transferred to general ledgerbefore it can flow to their interfaces).

There are two ways to link these processes to simplifytheir submission. One way is within the PayablesAccounting Process. Two parameters can be used:Submit Transfer to GL and Submit Journal Import. IfYes is chosen for the Submit Transfer to GL parameter,then the options set up in the Transfer to GL region ofthe Payables Options window are called for thissubmission. Based on those options it may or may notbe possible to choose to submit Journal Import. (See theSetup section of this paper for detail). The second wayis to create a Request Set using standard OracleApplications functionality.

Oracle Payables also provides the option to createaccounting for a single transaction online from theInvoices and Payments windows, or for an invoice orpayment batch from the Invoice Batches and PaymentBatches window. This option may be helpful when in atesting phase or if a specific transaction needs specialprocessing.

New Accounting Inquiry and Update Forms

Now that Oracle Payables creates and stores accountingin the subledger it is also possible to inquire on andview the accounting created for payables transactions.There is a new form provided in release 11i whichshows a variation of accounting information dependingon where the form is accessed.

A new main menu heading has been added to theOracle Payables navigator called “Accounting”. One of


the options in this menu is “View Accounting Lines”.When this is chosen, the new View Accounting Lineswindow opens. When called from the navigator it ispossible to inquire on any range of accounting data,such as across documents, periods or accounts.

The data retrieved is displayed in the form of abalanced accounting entry. It can also be viewed in a T-account format or in an alternate currency if usingreporting sets of books.

Versions of this same window are available in the mainPayables transactions windows - Invoices andPayments. If opened in the Invoices window to see theaccounting for an invoice transaction, the window titleis “View Invoice Accounting”. If opened in thePayments window to see the accounting for a paymenttransaction, the window title is “View PaymentAccounting”. All of these windows use the standardOracle Applications folder functionality, allowing themto be easily modified to best suit the typical inquiryneeds of a business.There are a few fields to point out on the screenshot ofthis inquiry window. In the lower right hand regionthere is a field called “Event Type”. This displays theaccounting event that generated the particularaccounting line being viewed. Also in that same area isa field called “Transferred to GL”. This displays a Yesor No value depending on whether or not theaccounting line has been transferred to the generalledger interface.

This last field is useful to point out because thisinformation is no longer found on the main Invoiceswindow. In prior releases there was a field in theInvoices window called “Posted”. It would display Yes,No, or Partial (if part of the invoice had beentransferred to general ledger). This terminology was abit problematic because what it really meant waswhether or not the accounting for the invoice had been

transferred to the general ledger interface. It did nottruly mean that the accounting had been posted. Inrelease 11i, Oracle Payables has tried to move awayfrom using the terms “post” or “posted” wheneverpossible and instead refers to accounting as transferredto general ledger. This has been done in order to bemore precise about what has happened with thePayables transaction data.

Now in both the Invoices and Payments windows thereis a new field called “Accounted”. The value in thisfield shows as “Yes”, “No”, or “Partial”. This helpsindicate that there is accounting available for view on atransaction. Along with this the “Posted” field in theDistributions subwindow of the main Invoices windowhas been renamed “Accounted”. Most rules in priorreleases about whether or not a “posted” invoice orpayment could be adjusted now apply to an accountedinvoice or payment.

As covered in the section on the Payables AccountingProcess, sometimes an accounting entry can be createdwith an accounting status of “Error”. In this case thereis a new form available to allow correction of the error.The form can be accessed from the navigator under thenew Accounting menu heading. The menu path andwindow name are the same - Update AccountingEntries.

Typically this form is used when the PayablesAccounting Process is run with the option to “ValidateAccounts”. If the process finds that any of the accountsare not valid in general ledger then the accountingentries are created with an error status, and appear onthe exceptions report. The report is reviewed anddecisions are made as to how to correct the accounts.Then this new form is opened and the correct accountinformation is entered in the blank account field.


The Update Accounting Entries form can also be usedas an inquiry form if desired.

Although encumbrance accounting is outside the scopeof this paper, one enhancement to point out in this areais a new inquiry window made available in release 11ito view the encumbrances for a particular invoice. Thenew window is called View Encumbrances and can beaccessed via the navigator in the new Accounting menuarea. It can also be accessed via the Tools menu optionwhen in the Invoices window and inquiring on aparticular transaction.

This new window gives users better visibility into theaccounting for their encumbrance entries. This type ofinquiry was not available in Oracle Payables in priorreleases.

Transferring Accounting Entries to GL

As already noted, Payables Transfer to General Ledgeris a new process designed to transfer and optionallysummarize the accounting entries in the Payablessubledger to the general ledger interface.

The process works by transferring accounting data in aselected date range and in a selected journal category.The accounting entries are assigned a journal categoryat the time they are created. This category can beviewed in the accounting inquiry windows. There arethree journal categories: Purchase Invoices, Payments,and Reconciled Payments. All of the invoice accountingevents are created with a journal category of PurchaseInvoices. All of the payment accounting events, exceptfor the payment clearing and the payment unclearingevents, are created with a journal category of Payments.The payment clearing and unclearing events are createdwith the journal category of Reconciled Payments.There are several differences between the programparameters in prior releases and the parameters inrelease 11i. A new parameter - “Transfer ReportingBook(s)” - has been added to simplify the transferprocess if MRC (Multiple Reporting Currencies) isused. The “Post Through Date” parameter has beenreplaced by two parameters - “From Date” and “ToDate”. The “To Date” parameter used alone works justlike the old parameter. However, now the twoparameters can be used together to transfer a moreprecise range of accounting entries. The “Journal EntryCategory” parameter was renamed to the more accurate“Journal Category”. The list of values displayed is thelist of the three types of Payables journal categories. Anew parameter, “Validate Accounts”, checks the

accounting entries against the current account status ingeneral ledger. If invalid accounts are found, the entriesare not transferred. If this option is not used, thenJournal Import automatically validates the accounts.All of the “Audit/No Audit” choices for all of theaccount type parameters have been replaced by oneparameter called “Transfer to GL Interface”. Optionsfor this parameter are: In Detail, Summarize byAccounting Date, and Summarize by AccountingPeriod.

Once the data is transferred to the general ledgerinterface, the process remains the same. The JournalImport process takes the data in the interface andcreates unposted journal entry batches, headers, andlines in Oracle General Ledger. From there the journalentries can be posted to update the account balances.

Release 11i offers enhanced drill down capabilitiesfrom Oracle General Ledger to the subledgers. Asmentioned earlier, it is now possible to transfer allaccounting entries in summary to gl, while stillretaining the ability to drill down from all accounts.When viewing a journal with the source of OraclePayables, drill down to Oracle Payables can be chosen.A new window has been created for the drill down, andthe window title and the information displayed varydepending on which journal category is being reviewed.The three window titles are: Payables InvoiceAccounting (from the Purchase Invoices category),Payables Payment Accounting (from the Paymentscategory), and Payables Reconciled PaymentAccounting (from the Reconciled Payments category).

All of these windows use the standard OracleApplications folder functionality, allowing them to beeasily modified to best suit the typical inquiry needs ofa business. From these windows it is simple to drilldown to more detail - to view the transaction or to viewthe transaction accounting.


Reports

Since the new accounting model affected all of theaccounting in Oracle Payables, any reports thatdisplayed accounting information in prior releases werereviewed and changed as needed. Some new reportswere needed to support the new accounting model. Andsome reports were made obsolete. A list of obsoletereports 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 PayablesAccounting Process. The audit section of the reportshows the detail of the accounting entries created by theprocess. The exceptions section of the report shows thedetail of any accounting entries created with an error. Itis possible to run the report in a summarized version inwhich case the audit section shows totals only.

Payables Accounting Entries Report

This report is similar to the output produced by thePayables Accounting Process; however it can be run onits own to report on accounting entries that meetspecific criteria. It allows greater flexibility in reporting- for example it can be run just for accounting entriesthat have or have not been transferred to generalledger. It is also possible to run this report to get thedetails of accounting entries created by a particular runof the Payables Accounting Process. Similarly, thisreport can be run to see the detail of what accountingentries were transferred to GL during a particular runof the Payables Transfer to General Ledger program.

Payables Transfer to General Ledger Report

The new transfer program automatically producesreport output. It has a summary section which givestotals of the accounting entries transferred to the glinterface. It has two sections which show exceptions:one section shows accounting entries that could not betransferred because they were in an error status, and thesecond shows accounting entries that were accountedwith no problem but are now unable to be transferreddue to a discrepancy between the accounted accountand the account in the general ledger.

This report does not produce an audit section of thedetail that has been transferred to the general ledger. Ifthat information is needed, then the PayablesAccounting Entries Report can be run for a particularsubmission of the Payables Transfer to General Ledgerto get the audit detail.

The report output from the new transfer replaces theAccounts Payable Journal Entry Audit and ExceptionReports.

Unaccounted Transactions Report

This new report is available to help review problemswith invoices and payments which can not haveaccounting created for them due to some problem. Itwill be useful to review this report after running thePayables Accounting Process in order to see whattransactions could not be accounted and why.

The report is organized by the reason why accountingcan not be created. For example, invoices must beapproved by the Payables Approval process before theycan be accounted. So invoices that have not yet beenapproved are grouped together on this report with theexception of “Unapproved”. This report also showstransactions that have holds that do not allowaccounting. Note that holds which did not allowposting in prior releases now do not allow accountingin release 11i.

This report replaces the Posting Holds Report. Itimproves upon the old report in several ways. One wayis that it shows both invoice and payment transactionsrather than just invoices. For example, if a payment cannot be accounted due to a missing exchange rate, thattransaction is identified by this report.Payables Account Analysis Report

This report was created to assist with review ofaccounting created in the Payables subledger and toassist with reconciliation of accounts to the generalledger. It can be submitted for an accounting date rangeand for a full account segment range.

This report replaces the Expense Distribution DetailReport. The new report does not need a setup form asthe Expense Distribution Detail Report did.

Changed Reports

Accounts Payable Trial Balance


The Accounts Payable Trial Balance is actually a newreport but since the name is the same it is included inthe changed reports section. The new accounting modelmade it necessary to rewrite the trial balance report. Allof the enhancements that had been outstanding againstthe report were reviewed and incorporated into the newreport. For example, there is now an option to run thereport for a single supplier. There is also an option torun the report for a single liability account.

Posted Invoice Register

This report was modified to report off the newaccounting entries which have been transferred togeneral ledger. This (along with the Posted PaymentRegister) was one of the cases where the use of theword “posted” was retained in 11i. Althoughtechnically the accounting in this report has onlytransferred to general ledger and not necessarily beenposted, the existing report name seemed like thesimplest to use.

All of the enhancements that had been outstandingagainst the report were reviewed and incorporated intothe new report. For example, there is now an option torun the report for a single liability account. There isalso an option to run the report in summary in order toget totals for reconciliation purposes.

Posted Payment Register

This report was modified to report off the newaccounting entries which have been transferred togeneral ledger. All of the enhancements that had beenoutstanding against the report were reviewed andincorporated into the new report. For example, there isnow an option to run the report for a single liabilityaccount. There is also an option to run the report insummary in order to get totals for reconciliationpurposes.New Close Process

The process to close an accounting period has changedin release 11i. The close process is reviewed here inorder to compare it with the close process in priorreleases. The form to control the status of anaccounting period has been renamed from “APAccounting Periods” to “Control Payables Periods”. Itslocation in the navigator has also changed. It hasmoved from the Setup section into the new Accountingsection of the menu. The rules to close a period inPayables in release 11i are:. All payment batches must be confirmed

. All transactions must be accounted

. All accounting entries must be transferred to generalledger. All future dated payments which have reachedmaturity in the accounting period must have their statusupdated to negotiable and be accounted

Optionally, unaccounted transactions can be swept tothe next accounting period if allowed by accountingrules. There is a new program in 11i to support this -the Unaccounted Transactions Sweep. This programcan be submitted from the Control Payables Periodsform in both a review mode and an update mode. Theprogram can be called only if there are anyunaccounted transactions in the period. The reportoutput of the program looks very much like theUnaccounted Transactions Report. This new programreplaces the Unposted Invoice and Payment Sweep.

Before invoices can be accounted they must beapproved by the Payables Approval process. Beforepayments can be accounted they must pass through theConfirm process. Typical steps to close a period inPayables 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 DetailReport for certain accounts in prior releases they willwant 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 changesmade to Oracle Payables to support the new accountingmodel. It is not an exhaustive discussion of all thechanges made to the product, but it should serve as areference point for understanding the major changes. It


should also help in understanding what the upgradeprocess does and if there is impact to any custom code abusiness might have.

The key data model changes revolve around the factthat now accounting entries are created and stored inthe Payables subledger. Prior to release 11i, data fromthree tables was used to create accounting entries in thegeneral ledger interface:AP_INVOICE_DISTRIBUTIONS_ALL,AP_PAYMENT_DISTRIBUTIONS_ALL, andAP_RECON_DISTRIBUTIONS_ALL(Refer to Diagram 1 at the end of this paper for a viewof the release 11 data model.)

Now in release 11i, three new tables are used to holdthe 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 AccountingProcess. The process creates accounting entries forevery set of books (combined basis accounting orMRC). Data from these tables is now transferred to thegeneral ledger interface. There is another new tablewhich has been added to help track the activity on apayment: AP_PAYMENT_HISTORY. This table holdsall the information for determining the paymentmaturity, payment clearing, and payment unclearingevents.(Refer to Diagram 2 at the end of this paper for a viewof the release 11i data model.)

Upgrade

The upgrade to release 11i converts the data in thethree distributions tables into accounting entry data inthe new tables. The tablesAP_PAYMENT_DISTRIBUTIONS_ALL andAP_RECON_DISTRIBUTIONS_ALL are obsolete inrelease 11i, although they are not dropped.

New Tables

AP_AE_HEADERS_ALLAP_AE_LINES_ALLAP_ACCOUNTING_EVENTS_ALLAP_ENCUMBRANCE_LINES_ALLAP_PAYMENT_HISTORY_ALLAP_MC_PAYMENT_HISTORYAP_TRIAL_BAL

New Forms

Update Accounting Entries (APXUPDAE)View Encumbrances (APXVWENC)View Accounting LinesView Invoice AccountingView Payment AccountingThe three above are different views of the formXLAIQACLPayables Invoice AccountingPayables Payment AccountingPayables Reconciled Payment AccountingThe three above are different views of the formXLAIQDRL

Obsolete Tables

AP_PAYMENT_DISTRIBUTIONS_ALL:Used to hold payment accounting information. Thetable was populated when a manual or quick paymentwas entered or a payment batch was confirmed.AP_MC_PAYMENT_DISTS_ALL:Used to hold payment accounting information forreporting sets of books (MRC).AP_RECON_DISTRIBUTIONS_ALL:Used to hold payment reconciliation information. Thetable was populated when a payment was cleared orreconciled in Oracle Cash Management.AP_MC_RECON_DISTS_ALL:Used to hold payment reconciliation information forreporting sets of books (MRC).AP_TRIAL_BALANCE:Used to hold information for the Accounts PayableTrial Balance report.AP_MC_TRIAL_BALANCE:Used to hold information for the Accounts PayableTrial Balance report when run from a reporting set ofbooks (MRC).

Obsolete Forms

Invalid GL Accounts (APXPDFIX):Used to correct invalid account information andpayment distributions. Effectively replaced by theUpdate Accounting Entries form.Invoice Distributions Summary (APXGLINQ):Used as a way to look at accounting for invoicedistributions. Replaced by View Accounting Lineswindow.

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 tableAP_INVOICE_DISTRIBUTIONS_ALL now meansthat the distribution has been accounted. To see if anaccounting entry has been transferred to general ledgerlook at the transferred flag in the AP_AE_LINES_ALLtable.

Conclusion

The new accounting model in Payables 11i hasdramatically changed the way accounting works in thesubledger. It is important to review and understandthese changes in order to make a smooth transition tothe new release.

This paper provides an overview of the new accountingmodel and some details for the setup and accountingentries created in the subledger. The referencedocumentation should also be reviewed to ensure anunderstanding of how to manage accounting in release11i.

The new flexible accounting entries should provebeneficial to users of Oracle Payables. Now the producthas an improved architecture to support building otheraccounting enhancements in future releases.

About the Author

Lauren Scott is Senior Product Manager for the OraclePayables product. She has been working with OracleFinancials since 1988, first as a user and then inproduct development since 1997. She managedOracle’s US Payables and Fixed Assets operations forsix and a half years before moving to Applications.


Diagram 1 - R11 Physical Data Model

AP_TRIAL_BALANCE(Accounts Payable Trial

Balance)

AP_INVOICES_ALL(Invoices)

AP_INVOICE_DISTRIBUTIONS_ALL(Invoice Distributions)

AP_PAYMENT_SCHEDULES_ALL

(Scheduled Payments)

AP_CHECKS_ALL(Payments)

AP_RECON_DISTRIBUTIONS_ALL(Reconciled Payments)

AP_PAYMENT_DISTRIBUTIONS_ALL(Payment Distributions)

AP_INVOICE_PAYMENTS_ALL

(Invoice Payments)

GL_IMPORT_REFERENCES(Drilldown Link)

GL_JE_LINES(Journal Lines)

GL_JE_HEADERS(Journal Headers)

GL_JE_BATCHES(Journal Batches)

GL_INTERFACE(General Ledger Interface)

Journal Import

Transfer Program

Transfer Program Transfer P

rogram

Journal Import

Journal Import

Transfer Program


Diagram 2 - R11i Physical Data Model

AP_INVOICES_ALL(Invoices)

AP_INVOICE_DISTRIBUTIONS_ALL(Invoice Distributions)

AP_PAYMENT_SCHEDULES_ALL

(Scheduled Payments)

AP_CHECKS_ALL(Payments)

AP_PAYMENTHISTORY_ALL

(Payment History)

AP_INVOICE_PAYMENTS_ALL

(Invoice Payments)

GL_IMPORT_REFERENCES(Drilldown Link)

GL_JE_LINES(Journal Lines)

GL_JE_HEADERS(Journal Headers)

GL_JE_BATCHES(Journal Batches)

GL_INTERFACE(General Ledger Interface)

Journal Import

AP_ACCOUNTINGEVENTS_ALL

(Accounting Events

AP_AE_HEADERS_ALL(Accounting Entry

Headers)

AP_AE_LINES_ALL(Accounting Entry Lines)

Transfer Program Journal Import

Journal Import

how do you account for that - oracle payables 11i

Documents