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.

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

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

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.

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:

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

. Import all invoices and/or expense reports from interface tables . 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) . 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

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

Accounting Methods

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

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

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.

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

Payment Accounting

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

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

. Payment Unclearing Event

AP Liability

200

300

Invoice Event
The invoice event occurs when a new, approved invoice is accounted. This event creates accounting entries for each of the accounts associated with the invoice distributions and to the liability account of the invoice. The accounting entry created for a simple invoice with one distribution in the functional (accounting) currency is: Account Charge AP Liability Debit 100 Credit 100

There are many other examples of accounting for an invoice event, but one other to point out here is the accounting created for an invoice matched to a purchase order when accrual on receipt is used. The following example assumes an invoice for one item with an invoice price of 105 and a purchase order price of 103:

Account AP Accrual Invoice Price Variance AP Liability

Debit 103 2

Credit

105

The accounting entry created for an invoice with multiple distributions in the functional currency is: Account Charge Charge Charge AP Liability Debit 100 50 50 Credit

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

Invoice Adjustment Event

The invoice adjustment event typically occurs when an accounted invoice is adjusted in some way. An example of a common adjustment is reversing one distribution line entered in error to an incorrect charge account and entering a correcting line. This event creates accounting entries for the adjusting lines. The accounting entry created for a simple invoice adjustment in the functional currency is: Account Charge (in error) Charge (correction) Debit 100 Credit 100

200

Note the summarized entry to the liability account. This is an enhancement in release 11i. This is different in the case of using the automatic offsets feature. If the automatic offsets feature is used, then the same invoice example above yields the following accounting entry: Account Charge (Co 01) Charge (Co 02) Charge (Co 03) AP Liability (Co 01) AP Liability (Co 02) AP Liability (Co 03) Debit 100 50 50 Credit

100 50 50

If an invoice is entered in foreign currency, the 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 units (FX) which converts to 300 in functional currency units (exchange rate of 1.5): Account Charge Charge Charge Debit (FX) 100 50 50 Credit (FX) Debit 150 75 75 Credit

Another example of an adjustment is the case where an increase is needed to the amount of an invoice, and the 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 invoice event: Account Charge AP Liability Debit 100 Credit 100

The accounting date (GL date) is part of what controls how events are accounted. If an invoice is entered with multiple distribution lines, and some of the distribution lines have different accounting dates, then the lines with the earliest accounting date are accounted as an

Copyright 2000, by Oracle Corporation

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

Invoice Cancellation Event

The invoice cancellation event occurs when an accounted invoice is cancelled. The cancellation feature automatically adjusts the invoice amount to zero, and reverses all invoice distribution lines. If the invoice lines were matched to a purchase order, the match is also reversed. The accounting entry created for the cancellation of a simple invoice with one distribution in the functional currency is: Account Charge AP Liability Debit 100 Credit 100

The next event is the entry of the invoice to which the prepayment is applied. The accounting process first creates the invoice event even if the prepayment has already been applied: Account Charge Charge Charge AP Liability Debit 600 200 200 Credit

1000

Next the prepayment application event is created: Account AP Liability Prepaid Expense Debit 500 Credit 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.

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 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 Prepaid Expense AP Liability Debit 500 Credit 500

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 Prepaid Expense AP Liability Debit 500 Credit 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.

Payment Event

Copyright 2000, by Oracle Corporation

Discount Taken The payment event occurs when a new payment is issued and accounted. This event creates accounting entries to relieve the liability of the invoice and to charge the cash clearing or cash account, depending on the system setup options. This event occurs when the Payment Accounting option Account for Payment When Payment is Issued is enabled. If the system is set up to account for any gains or losses at the time of payment issue, this accounting event also creates those accounting entries. For the following examples, assume that the setup used is to account for payments at both issue and clearing, and to account for gain or loss at the same time. The accounting entry created for the payment of a simple invoice in the functional (accounting) currency is: Account AP Liability Cash Clearing Debit 100 Credit 100

18

Note the summarized entries to the cash clearing and discount accounts. This is an enhancement in release 11i. This is different in the case of using the automatic offsets feature. If the automatic offsets feature is used, then a similar payment event yields the following accounting entry: Account Debit Credit AP Liability (Co 01) 100 AP Liability (Co 02) 100 Cash Clearing (Co 01) 91 Cash Clearing (Co 02) 91 Discount Taken (Co 9 01) Discount Taken (Co 9 02) There are many other examples of accounting for a payment event, but one other to point out here is the accounting created for multiple payments made for the same foreign currency invoice. When the final payment is made on an invoice, Payables ensures that the liability is fully relieved, even if the sum of the functional currency amounts of the payments does not add up to the functional currency amount of the liability. This is handled by creating the necessary entry to the rounding account. This example is for an invoice in the amount of 20.08 foreign currency units (FX) converted to 2.01 functional currency units. So the liability for the invoice was booked as 2.01. A first payment is made for the invoice in the amount of 10.04 foreign currency units (FX) converted to 1.00 functional currency units and accounted as follows (assume no gain or loss for simplicity): Account Debit (FX) 10.04 Credit (FX) 10.04 Debit 1.00 1.00 Credit

If an invoice is entered and paid in foreign currency, there may be a currency gain or loss realized at the time of accounting for the payment event. In the foreign currency example in the invoice event section, the invoice was for 200 foreign currency units (FX) which converted to 300 in functional currency units (exchange rate of 1.5). Using the same example, now the payment is made for 200 foreign currency units (FX) which converted to 340 in functional currency units (exchange rate of 1.7). The accounting entries are created in both currencies by the payment event: Account AP Liability Realized Loss Cash Clearing Debit (FX) 200 Credit (FX) Debit 300 40 200 340 Credit

AP Liability Cash Clearing

Accounting for discounts is also handled by this event. This example assumes that the discount method is the system account. This is an example of a payment for an invoice in the functional currency, where the invoice amount is 200 and a discount of 18 is taken. This example is for the payment of an invoice which has multiple invoice distributions. Account AP Liability Cash Clearing Debit 200 Credit 182

A second payment is made for the invoice in the amount of 10.04 foreign currency units (FX) converted to 1.00 functional currency units and accounted as follows: Account AP Liability Cash Clearing AP Liability Debit (FX) 10.04 Credit (FX) 10.04 .01 Debit 1.00 1.00 Credit

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.

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:

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 Future Dated Payment Cash Clearing Debit 100 Credit 100

Account AP Liability Realized Loss Cash Clearing

Debit (FX) 200

Credit (FX)

Debit 300 40

Credit

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: Account AP Liability (1) Realized Loss (1) Cash Clearing (1) AP Liability (2) Realized Loss (2) Cash Clearing (2) Debit (FX) Credi t (FX) 200 Debit Credit 300 40 340 300 40 200 340

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

Payment Adjustment Event

A payment adjustment event occurs when any of the invoices recorded as paid by a manual payment are changed. Payables has a feature which allows this type of adjustment. If an adjustment like this is made, then the accounting event creates reversals of the accounting done when the original payment of the invoices was

200 200

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 document and sets the invoices on the payment back to unpaid status. The accounting entries generated are the opposite of what are created for a payment event. Here is the example of a 182 payment and 18 discount taken (discount charged to a system account): Account AP Liability Cash Clearing Discount Taken Debit 200 Credit 182 18

This accounting event may also handle any accounting for currency gains or losses. If setup is such that there is no accounting for gain or loss at the time a payment is issued, but rather only at the time a payment clears, then the accounting for the payment clearing event creates the necessary accounting entries. In the foreign currency example in the invoice event section, the invoice was for 200 foreign currency units (FX) which converted to 300 in functional currency units (exchange rate of 1.5). Using the same example, now the payment is made for 200 foreign currency units (FX) at the same conversion rate since no gain or loss will be calculated until the payment clears. The accounting entries are created in both currencies by the payment event: Account AP Liability Cash Clearing Debit (FX) 200 Credit (FX) 200 Debit 300 300 Credit

If this payment is voided, and then accounting is created, the accounting for the payment cancellation event appears as follows: Account AP Liability Cash Clearing Discount Taken Debit 182 18 Credit 200

Payment Clearing Event

The payment clearing event occurs when a payment is cleared or reconciled in Oracle Cash Management, and the system is set up to account for payments when they clear (one of the payment accounting options reviewed in the Setup section). Here is an example of the accounting created at both payment issue and payment clearing. Accounting at payment issue for a 182 payment with a 18 discount taken (discount charged to a system account): Account AP Liability Cash Clearing Discount Taken Debit 200 Credit 182 18

When the payment clears, the 200 foreign currency units are converted to 340 in functional currency units (exchange rate of 1.7). The accounting entries are created in both currencies by the payment clearing event: Account Cash Clearing Realized Loss Cash Debit (FX) 200 Credit (FX) Debit 300 40 200 340 Credit

Payment Unclearing Event

The payment unclearing event occurs when a cleared or reconciled payment is reversed in Oracle Cash Management - in effect the payment is uncleared. The accounting entries created simply back out the accounting created by the payment clearing event. If at the time of payment clearing the accounting entry created was: Account Cash Clearing Cash Debit 182 Credit 182

Now at the time of payment clearing the accounting entry created is: Account Cash Clearing Cash Debit 182 Credit 182

Effectively this accounting moves the cleared or reconciled payment out of the cash clearing account and debits the cash account now that the cash has been issued by the bank.

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

Copyright 2000, by Oracle Corporation

Account Cash Clearing Cash

Debit 182

Credit 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

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

Copyright 2000, by Oracle Corporation

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 balanced accounting entry. It can also be viewed in a Taccount format or in an alternate currency if using reporting sets of books. Versions of this same window are available in the main Payables transactions windows - Invoices and Payments. If opened in the Invoices window to see the accounting for an invoice transaction, the window title is View Invoice Accounting. If opened in the Payments window to see the accounting for a payment transaction, the window title is View Payment Accounting. 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. There are a few fields to point out on the screenshot of this inquiry window. In the lower right hand region 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

As covered in the section on the Payables Accounting Process, sometimes an accounting entry can be created with an accounting status of Error. In this case there is a new form available to allow correction of the error. The form can be accessed from the navigator under the new Accounting menu heading. The menu path and window name are the same - Update Accounting Entries. Typically this form is used when the Payables Accounting Process is run with the option to Validate Accounts. If the process finds that any of the accounts are not valid in general ledger then the accounting entries are created with an error status, and appear on the exceptions report. The report is reviewed and decisions are made as to how to correct the accounts. Then this new form is opened and the correct account information is entered in the blank account field.

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.

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

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

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.

Copyright 2000, by Oracle Corporation

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.

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

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.

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

Copyright 2000, by Oracle Corporation

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.

. 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

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

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

Copyright 2000, by Oracle Corporation

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.

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

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

Payables Transfer to General Ledger (APPPST)

Copyright 2000, by Oracle Corporation

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 Oracles 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_ PAYMENTS_ALL (Invoice Payments) Transfer Program

AP_INVOICE_ DISTRIBUTIONS_ALL (Invoice Distributions)

Transfer Program Transfer Program

GL_JE_BATCHES (Journal Batches)

AP_PAYMENT_ DISTRIBUTIONS_ALL (Payment Distributions)

Transfer Program

GL_JE_HEADERS (Journal Headers) GL_INTERFACE (General Ledger Interface)

Journal Import GL_IMPORT_ REFERENCES (Drilldown Link) Journal Import Journal Import

GL_JE_LINES (Journal Lines)

Copyright 2000, by Oracle Corporation

Diagram 2 - R11i Physical Data Model

AP_INVOICES_ALL (Invoices)

AP_CHECKS_ALL (Payments)

AP_INVOICE_ DISTRIBUTIONS_ALL (Invoice Distributions)

AP_PAYMENT_ SCHEDULES_ALL (Scheduled Payments) AP_PAYMENT HISTORY_ALL (Payment History)

AP_ACCOUNTING EVENTS_ALL (Accounting Events

AP_INVOICE_ PAYMENTS_ALL (Invoice Payments) GL_JE_BATCHES (Journal Batches)

AP_AE_HEADERS_ALL (Accounting Entry Headers) GL_INTERFACE (General Ledger Interface) Transfer Program

Journal Import

GL_JE_HEADERS (Journal Headers) Journal Import

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

Copyright 2000, by Oracle Corporation