Closing the AP Month - How it works and what to do when it doesn’t!

Deidre FigueroaOracle Corporation

Abstract

Improve your AP process by understanding thefundamentals of closing the month in AP and learningwhat to do when the unexpected occurs. This paperprovides an overview of the AP month-end process anddiscusses proven solutions to frequently encounteredproblems. Topics include new 10.7 and cashmanagement features.

Scope

I. Fundamentals of ClosingII. Solutions to Frequently Encountered ProblemsIII. Overview of the Cash Management Impact on AP

Please note that this paper does not discuss data entry,but focuses on insuring that the transactions entered areposted and balanced. The new 10.7 reporting featuresare integrated with the closing process, while ahighlight of the Cash Management will be discussedseparately.

I. FUNDAMENTALS OF CLOSING

Month-end closing within the Oracle Payables system

is a simple process. You navigate to the close periodform, select close, commit, and if all is well, yourperiod will close and balance. Its that little phrase “ifall is well” that introduces the bulk of the workrequired for the month end closing.

If you understand the concepts of what happens duringthe closing and how your system setup affects theprocess, you can insure that “all is well” for your periodto close and know that it is in balance.

The closing process will be divided into 5 main steps.• Pre-post work• Posting• Reporting• Balancing• Closing

Pre-Post Work

Before you can post to the GL, you want to review bothyour invoice and payment transactions to insure thatthey are ready to post.

Insure invoices are ready to post: An invoice must be approved and/or have no postingholds in order to be selected for posting. To insure that

AP DataGL Data

Pre-Post Work Reporting& Balancing

Journal Import

Close/OpenPeriod

AP Data

AP Transfer toGL

GL_INTERFACE

your invoices are ready to post, you should runautoapproval and review the hold reports

1. Approve invoicesThe approval process attempts to approve invoices andremove any existing holds. If exceptions are found,some invoices may be placed on hold and not approved.If an invoice contains a system hold you need tomanually fix the invoice and then re-run theautoapproval process to remove the hold. All userdefined holds must be manually removed as they arenot automatically removed by the autoapproval process.

Payables - Autoapproval report

2. Look for unapproved invoicesAfter running autoapproval, you want to look forinvoices containing holds and Oracle provides 3 reportsfor this purpose. If an invoice appears on any of thesereports, you either need to adjust the invoice ormanually remove the hold.

Invoice Hold Report - displays all held invoices.Posting Hold Report - only displays invoices with holdsthat prevent posting.Matching Hold Report - only displays invoices withmatching holds.

Insure Payments are made:The pre-work for payments is limited to insuring thatthe transactions you want recorded in this period havebeen processed. You must insure that all yourpayment batches have been completed: eitherconfirmed or canceled. A period will not close if thereare payment batches in a status other than confirmed orcanceled.

If an invoice is approved by will not pay, you shouldinsure that the invoice is due to be paid and that thepayment schedule is not on hold.

Posting

Once the pre-work is complete, you are ready to post.The posting process selects and updates transactions inthe AP subledger and creates accounting transactionsfor the general ledger. This process actually occurs in 2distinct steps:

Step 1 - Transfer from AP to GL Updates the AP system

Step 2 - Journal ImportCreates journals in the GL system

Step 1 - Transfer from AP to GL:Posting begins in the AP system and can be startedfrom a form or report, depending on the version of theapplications you are using.

Character: /Navigate Task GLPostCharacter (10.6 and 10.7) and GUI:

Payables Transfer to General Ledger Report

1. The transfer process selects the invoices andpayments that are ready to post to the general ledger.

2. The appropriate accounting transactions are createdand inserted into the GL_INTERFACE table.This is the GL open interface used to import journals.It is a temporary table that holds all the accountingtransactions received from AP until they are importedinto the GL system. Once a transaction has beensuccessfully imported into the GL system, it is deletedfrom the GL_INTERFACE table.

3. Transactions successfully selected and inserted intothe GL_INTERFACE table are updated to "Posted" inthe AP system. Transactions that were selected butencountered some exception are not inserted into theGL_INTERFACE table nor are they updated to“Posted”. (Exceptions can be an inactive accountingflexfield value, a GL_DATE in an un-opened GLperiod, exchange rate missing, etc.)

When an invoice or payment encounters an exception,the distribution containing the exception will not post,yet will not prevent the other distributions fromposting. For example, an invoice with 2 distributionscan have one distribution that posted and one thatencountered an exception. If you query the invoice, thestatus will show as partially posted.

AP Transfer to GL

AP Journal Reports

ap_invoice_distributions

ap_invoice_payments

gl_interface

AP is Posted GL not yetUpdated

4. After the process is complete, the AP Journalreports are generated to display the results of theposting selection. These reports are very important andshould be saved. They are generated directly from theposting process and can not be rerun at a latter date.

Accounts Payable Journal Entry Audit ReportThis report lists the details of the accountingtransactions that have been inserted into theGL_INTERFACE table. It displays the APtransaction, its corresponding debits and credits, theGL accounts affected, and more.

Accounts Payable Journal Entry Exception ReportThis report displays the transactions that encounteredan exception during the posting process. Eachtransaction includes an exception code that explainswhy it was prevented from posting. All transactionsappearing on this report will require some change inorder to be selected for posting the next time you runthe AP transfer process.

Once the AP Transfer to GL process hasfinished, only the AP system will havecompleted its portion of the posting

process. As far as AP is concerned, posting is done andcomplete. For AP, there is no turning back from thispoint. The transactions are now in theGL_INTERFACE table waiting to be imported into theGL, via the Journal Import process. If thetransactions are deleted from the GL_INTERFACEtable, the AP system will still show the transactionsas posted, even though the GL has not imported thetransactions. Once an AP transaction has been posted,it can not be re-selected for posting again, and there isno system process to un-post a transaction. Therefore,NEVER DELETE the AP information from theGL_INTERFACE table unless you do not want theaccounting transactions to be reflected in the GL.

Posting OptionsWhile submitting the AP Transfer to GL process, thereare parameters that require input and each is importantto the results received from the posting. Eachparameter will be discussed, along with an example ofits impact on the posting transactions.

1. Post Thru DateThe GL_DATE attached to an invoice distribution orpayment determines in which accounting period thetransaction will be posted. All viable non-postedtransactions having a GL_DATE less than or equal to

the date entered in this field will be selected forposting.

2. Posting in Detail or SummaryThis parameter determines the level of detailinformation recorded in the general ledger. Regardlessof what choice is made, the AP subledger maintains allthe detail information for each AP transaction.

DetailDetailed posting implies that every invoice or paymentdistribution will create a unique GL journal entry. Forexample, 2 invoices with distributions charged to thesame expense account will create 2 journal entries, eachwith a distinct debit and credit.

Example Invoices (Liability Account 1-200)Description Amount Expense

AccountInvoice #ABC

Distribution #1 $50 1-500Invoice #XYZ

Distribution #1 $100 1-500

GL Journal createdAccount Description Debit Credit1-200 Liability - #ABC $501-200 Liability - #XYZ $1001-500 Expense - #ABC $501-500 Expense - #XYZ $100

SummarySummary posting groups transactions with similaraccounting flexfield information together, and creates asingle GL journal for each grouping. Debits andcredits made to the same accounting flexfield aregrouped separately, they are not summed together andnet out.

Example Invoices (Liability Account 1-200)Description Amount Expense

AccountInvoice #ABC

Distribution #1 $60 1-500Distribution #2 ($10) 1-500

Invoice #XYZDistribution #1 $100 1-500Distribution #2 $0 1-500

Note!

GL Journal CreatedAccount Description Debit Credit1-200 Liability Summary $101-200 Liability Summary $1601-500 Expense Summary $1601-500 Expense Summary $10

AP does not create accounting entries for zero amounttransactions. If you have an individual payment ordistribution line equal to zero, the transaction will notappear on the Journal Entry Audit report or the postingreports. However, the AP system will still flag thetransaction as posted.

3. Posting with AuditAudit provides the information necessary to uniquelyidentify the AP transaction that created a GLaccounting entry. (Information such as InvoiceNumber, Supplier Name, Check Number, etc.) Auditworks with the detail/summary option to provide theinformation you desire to see in the GL. You must postin audit in order to utilize the following features:• Posting in detail• Zooming from GL to AP for transaction detail• Running the Posted Payment and Invoice reports

Audit is required in order to post in detail. If yourequest detail information, but do not have auditselected, you will not see detail, but summaryinformation in the GL_INTERFACE table.

There are different types of accounting transactions thatcan be inserted into the GL_INTERFACE table, and foreach type, you can determine whether to request auditor not.

• Cash and Expense TransactionsAll transactions that affect a cash or expenseaccount require Audit information. You can notchange the default for these items.

• Discount, Realized Gain/Loss, and Cash Clearing(future payment) transactions.You have the option to select Audit or No Audit.

• Liability transactionsYou have the option to select Audit, No Audit orpartial audit. Partial audit summarizes the liabilitytransactions per invoice or payment, instead of forthe entire posting batch. This provides enoughdetail to know which invoice or payment a

transaction came from, but the individualdistribution detail for that item is summarized.

By using the detail/summary and audit optionstogether, you can get detail information for sometransactions and summary information for others.Review the following examples to see how the optionswork together.

Example Invoices (Liability Account 1-200)Description Amount Expense

AccountInvoice #ABC $50

Distribution #1 $40 1-500Distribution #2 $10 1-500

Invoice #XYZ $200Distribution #1 $125 1-500Distribution #2 $75 1-500

Example Payments (Cash Account 1-100)Description Amount Other

AccountCheck #101

Pays Invoice #ABC$50

Supplier Payment $45 1-200Discount Taken $5 1-700

Check #102Pays Invoice #XYZ

$100

Supplier Payment $180 1-200Discount Taken $20 1-700

Example #1: Post in detailAudit for Expense, Liability, Cash, and Discounts

GL Journal created for invoices:Account Description Debit Credit1-200 Liability - #ABC $101-200 Liability - #ABC $401-200 Liability - #XYZ $751-200 Liability - #XYZ $1251-500 Expense - #ABC $101-500 Expense - #ABC $401-500 Expense - #XYZ $751-500 Expense - #XYZ $125

GL Journal created for Payments:Account Description Debit Credit1-100 Cash - #101 $91-100 Cash - #101 $361-100 Cash - #102 $67.501-100 Cash - #102 $112.501-200 Liability - #101 $101-200 Liability - #101 $401-200 Liability - #102 $751-200 Liability - #102 $1251-700 Discount - #101 $11-700 Discount - #101 $41-700 Discount - #102 7.501-700 Discount - #102 $12.50

Example #2: Post in detailAudit for Expense and CashNo Audit for Liabilities and Discounts

GL Journal created for invoices:Account Description Debit Credit1-200 Cr Liability Summary $2501-500 Expense - #ABC $101-500 Expense - #ABC $401-500 Expense - #XYZ $751-500 Expense - #XYZ $125

GL Journal created for Payments:Account Description Debit Credit1-100 Cash - #101 $91-100 Cash - #101 $361-100 Cash - #102 $67.501-100 Cash - #102 $112.501-200 Liability Summary $2501-700 Discount Summary $25

Step 2 - Submit Journal ImportAt this point, AP has completed its portion of theposting process and the GL needs to complete thesecond portion: importing the accounting transactionsinto the GL system.

When running the AP Transfer to GL process, theJournal Import process can be initiated from either theGL system or the AP system. If the option "SubmitJournal Import" is equal to YES, once the AP transferis complete the Journal Import program is

automatically executed. If "Submit Journal Import" isequal to NO, then you manually submit the JournalImport process through the GL.

Character: /Navigate Journal Import runGUI: Journal Import Run

When submitting the process manually, there are 2additional options that must be selected: Source andGROUP_ID. The source and GROUP_ID are used touniquely identify which transactions in theGL_INTERFACE table you are requesting to import.

For AP, the source will always be equal to ‘Payables’.The GROUP_ID will be unique for each posting batchthat is created. A unique GROUP_ID is generatedduring the AP transfer process, and it identifies everytransaction that belongs to the posting batch.

The purpose of the journal import is to extract theaccounting transactions and audit information from theGL_INTERFACE table and populate the appropriateGL tables. The transaction information in theGL_INTERFACE table will generate the actualaccounting transactions in the GL journal tables(GL_BATCHES, GL_HEADERS and GL_LINES).

During import, the audit information is removed fromthe GL_INTERFACE table and inserted into theGL_IMPORT_REFERENCES table. This table mustbe populated in order to produce the Posted Paymentand Posted Invoice reports. This data is also used tozoom from a GL journal line to the originating APtransaction. The Audit information is the ONLYstored data link between the GL and AP transactions.If you do not post in audit, you can not perform thesefunctions.

Even though you instruct AP to post in Audit, your GLsystem must also be configured correctly in order to

Journal Import

Journal Import Reports

gl_batches

gl_interface

AP isPosted

GL isPosted

gl_import_references

gl_headers

gl_lines

AP Posted

import Audit information. This is handled via theJournal Import Source form in GL, where the standardinstall defaults to allow the import of Payables auditdata.

Character: /Navigate Setup Journal SourcesGUI: Setup Journal SourcesImport Journal References = YES

As with the AP process, it is possible that an exceptioncan occur while attempting to import a transaction.The Journal Import Exception report displaysinformation about all the transactions that GLattempted to import. The transactions are noted assuccessful or containing exceptions. If an exceptionoccurred, a code is associated with the transaction andan explanation for each code is displayed at the bottomof the report. If a batch encounters an exception, unlessthe exception can be posted to a suspense account, theentire batch is left in the GL_INTERFACE table andis not imported.

When submitting the Journal Importprocess from the GL, there is an option toimport descriptive flexfields. The AP

system does not currently send the information requiredto populate the descriptive flexfields. Although thisoption can be used for importing from otherapplications, it does NOT work for AP journals. If yourequire this feature, at this time you will need tocustomize your AP system to insert the requireddescriptive flexfield information into theGL_INTERFACE table.

Reporting

Once the posting process is complete, you are ready torun some key reports to insure that both your Payablessub-ledger and the General Ledger are in balance.Oracle provides numerous reports to assist you inbalancing.

1. Unposted Invoice Sweep ReportThis report informs you about un-posted invoices andpayments in the current or previous open periods. Ifun-posted transactions exist, you must decided if youwant to post them in the current period or sweep them(move them) to the next open period.

The parameter, "Report Only", determines if the un-posted transactions are simply displayed or displayedAND SWEPT to the next open period. When a

transaction is swept, its GL_DATE is changed to thefirst day of the next open period. (Remember that theGL_DATE determines in which period a transaction isposted).

In report only mode, you can run the reportas often as you like. IN SWEEP MODE,THE REPORT SHOULD ONLY BE RUN

AFTER ALL DESIRED TRANSACTIONS HAVEBEEN POSTED IN THE CURRENT PERIOD. This isvery important, because the sweep report selects alltransactions that have NOT yet posted, and moves themto the next open period. There is NO process to"unsweep" transactions once they have been moved tothe next open period.

2. Accounts Payable Trial Balance ReportThis report displays the individual liability for everysupplier that has an open balance. The report isdivided and summed by liability account, and shouldbalance to the respective AP Liability account in thegeneral ledger.

Only invoices and payments that have been POSTED inAP will display on this report. (They need not beposted in the GL).

3. Posted Invoice Report, Posted Payment ReportThese reports display the invoices or payments thathave been posted to the general ledger in a given daterange. In order for a transaction to appear on thesereports, it must have been posted in audit in AP, andimported into the general ledger.

4. Expense Distribution Report,Payment Distribution ReportThese reports display the accounting transactions thatwill be created when you post your transactions. Theycan be run before or after you post, as they analyze eachAP transaction and display what accountingtransactions will be created during the posting process.They show accounting detail that you can not see byviewing a transaction online.

5. Journal with GL Details ReportTransaction Reconciliation ReportThese are new reports introduced in release 10.7, andare used to review details of transactions posted fromAP and imported into the GL. The report is based ondata in the GL_IMPORT_REFERENCES table, whichis populated when you post in Audit. If you have notposted in Audit, this information will not be available.

Note!

Note!

These reports are basically the same, but utilizedifferent parameters to select the information that isdisplayed. The Journal with GL details report selectsdata based upon GL entries created from APtransactions, while the Transaction Reconciliationreport selects data based upon the AP transactions.Therefore, if you have an AP transaction for which youwould like to see the accompanying GL transactions,use the reconciliation report. If you have a GL journalfor which you would like to see the originating APtransaction, run the GL details report.

Balancing

The reports described above will be used in thebalancing process. To determine if your system is inbalance, you need to insure that the amount reported inAP matches the amount reported in the GL. Inaddition, there are times when you want to see that theAP system is in balance with itself. (i.e. Pilot testing,checking the validity of converted data, or your AP andGL systems don’t balance together).

Balancing APEvery transaction that is posted from AP to the GL isreflected in the Accounts Payable Trial Balance report.If you want to test the data on this report against thetransactions entered for a supplier, you can spot checkindividual suppliers. View the outstanding balance forthe individual supplier via the invoice inquiry form andcompare it to the data on the trial balance report. Theon-line balance inquiry includes all transactions, unlikethe trail balance report that only includes postedtransactions. Therefore, the on-line supplier balanceshould match the data reported on the trial balancereport, +/- any non-posted transactions. If a supplierdoes not appear on the trial balance report, thatindicates there is no outstanding posted liability for thatsupplier.

Character: /Navigate Invoice InquirySearch Option: Balance by Supplier

GUI: Invoices Inquiry InvoicesCalculate Balance Owed

Trial Balance Total (Posted Items)+ Non-Posted Invoices (Posted Invoice

Register Report)- Non-Posted Payments (Posted Payment

Invoice Register Report)

= Supplier Total (On-line Inquiry)

Balancing AP to the GLTo balance the AP and GL systems together, the APTrial Balance report should agree with the GL liabilityaccounts and the posting reports.

1. GL posted transactions and AP trial balanceUtilizing the trial balance report and the postingreports, you can insure that the transactions importedinto the GL system agree with those entered and postedin the AP system. Although the posting reports arerun from the AP menu, they are based on data stored inthe GL system (GL_IMPORT_REFERENCES table).If you did not post in audit or are using Cash basedaccounting, you will not be able to perform thisbalancing process.

To balance, you will need this months and last monthsAP Trial Balance Report, and this months postingreports. Last months trial balance, plus this monthstransactions should equal this months trial balance.

Last Months Trial Balance+ This Months Posted (Posted Invoice

Invoices Register Report)- This Months Posted (Posted Payment

Invoice Register ReportPayments

= Current Trial Balance (On-line Inquiry)

2. Balance GL liability account to the trial balanceVerify that the GL liability accounts agree with the datareported on the AP trial balance report.

3. Balance GL batch to the AP posting batchWhen you post and import transactions from AP intothe GL system, a unique GL batch is created. You canbalance a GL batch against the AP Journal Entry Auditreport that was generated during the AP transferprocess.

AP Posted

ap_trial_balance

AP GL

gl_import_references

AP Trial Balance

If your set of books allows intercompany accounting,the GL batch totals may be higher than the totals listedon the AP Journal Entry Audit report. When posting aGL batch, if transactions do not balance acrossbalancing segments, the GL system will automaticallycreate the entries necessary to balance the amounts ineach segment. These transactions will be displayed inthe posted GL batch, but will not be reflected in the APsystem. AP is not concerned with segment balances,but with the overall balancing of debits and credits pertransaction. Since the transactions are NOT createdduring the Journal Import process, you will not see theintercompany transactions until you post the GL batch.

Example AP Invoice (Liability Account 1-200)Balancing Segments: 1 and 2

Description Amount ExpenseAccount

Invoice #ABCDistribution #1 $40 1-500Distribution #2 $60 2-500

AP Transactions on AP Journal Entry ReportAccount Description Debit Credit1-200 Liability - Dist. #1 $401-200 Liability - Dist. #2 $601-500 Expense - Dist. #1 $402-500 Expense - Dist. #2 $60

GL Batch: Transactions from GL Journal ImportAccount Description Debit Credit1-200 Liability - Dist. #1 $401-200 Liability - Dist. #2 $601-500 Expense - Dist. #1 $402-500 Expense - Dist. #2 $60

GL Batch: Transactions after running GL PostAccount Description Debit Credit1-200 Liability - Dist. #1 $401-200 Liability - Dist. #2 $601-500 Expense - Dist. #1 $402-500 Expense - Dist. #2 $601-199 Intercompany

Receivable Segment 1$60

2-299 IntercompanyPayable Segment 2

$60

As you can see, the difference between the posted GLbatch and the AP Journal Entry report is equal to theamount of the intercompany transactions created duringthe GL posting process.

Closing the Period

When you are comfortable that your system is inbalance, you are ready to close the period. To open orclose a period in the Payables system, use the periodcontrol form.

Character: /Navigate - Control - PeriodsGUI: Setup: Calendar - Accounting -

AP Accounting Periods

Although the AP periods mirror those defined in yourGL Set of Books, they are controlled independently.Both the AP and GL systems are required to open andclose their own periods.

When attempting to close an AP period, if un-postedtransactions exist, a message will be displayed and theperiod will not be closed. At that point, you need torepeat the pre-post steps mentioned above in order toidentify and adjust, or sweep the un-postedtransactions.

You can re-open a closed period in AP as long as it isnot finally closed, and the corresponding GL period isnot closed. Once a final close has been done, theperiod can never be reopened. It is recommended thatyou final close a period only if it is from a prior year.

II. SOLUTIONS TO FREQUENTLYENCOUNTERED PROBLEMS

Even after you understand the fundamentals it ispossible to encounter a problem during your closingprocess. The following entries describe somefrequently encountered issues, and provide provensolutions for dealing with them.

1. My invoice was on hold, but it still posted.All holds prevent invoices from being paid, but not allholds prevent invoices from posting. The postingoption can be changed on most holds (with theexception of the system holds).

To change the posting options of a hold, use the DefineInvoice Approval form.

Character: /Navigate Setup Invoices ApprovalsGUI: Navigate Setup Invoices Approvals

Unfortunately, once an invoice has been posted, there isno un-post option. You will have to create manual GLjournal entries if you want to back out the posting.

2. Someone deleted the AP data from theGL_INTERFACE table before we imported to theGL!Although there is no standard process to re-post yourAP transactions, there are times when it is necessary todo so.

Oracle Support does have some pre-defined scripts tohelp you with this situation. These scripts will go intothe database and manually "un-post" your transactions.You can then re-run the AP transfer to GL process, andthe transactions will be re-selected for posting, insertedinto the GL_INTERFACE table, re-flagged as posted,and will be ready to import into the GL system.

Should you run into a situation requiring re-posting,please contact Oracle support. They need to work withyou to analyze your situation and determine whatchanges your system requires and which scripts will beneeded.

Although Oracle can provide help in fixing thetransactions, it is up to you to determine WHICHtransactions need to be adjusted. This process can begreatly simplified if you retain the AP Journal EntryAudit report generated from the AP Transfer to GLprocess. If you do not maintain the report, it will bedifficult to identify the problem transactions.

3. My invoice displays a different date from theperiod in which it posted.The GL_DATE associated with an invoice distributiondetermines the posting period, not the GL-DATEassociated with the invoice.

The GL_DATE at the invoice level is used for displaypurposes only. If you query a posted invoice, theGL_DATE at the invoice level will default to the latestGL_DATE from your distributions, or the first day inthe next open period. Do not worry that thedistributions posted in one period and now the invoiceshows a different date. The invoice GL_DATE isdisplay only, purely intended to help make your inputof distributions easier.

Example:Description Amount GL_DATEInvoice #ABC

Distribution #1 $40 15-FEB-97Distribution #2 $60 25-FEB-97

Example #1: Query invoice on 26-FEB-97The invoice GL_DATE will display 25-FEB-97

Example #2: Query invoice in April, whenFEBRUARY is already closed.The invoice GL_DATE will display 01-APR-97

4. I am trying to run the Journal import processfrom the GL system, but no transactions are beingimported.When running the Journal Import process from GL,you must select source = Payables, and select aGROUP_ID. If you do not select a GROUP_ID, theprocess will run, but no transactions will be imported.

If you have more than one GROUP_ID to choose from,you may not know which one to select. Unfortunately,there is no report that you can run to get this ID. Ifneeded, you can run the following select statement fromsqlplus to identify the GROUP_ID associated with yourAP Posting Batch.

col batchname format a15;col trans_type format a15;

select distinct reference1 batchname, GROUP_ID,reference26 trans_typefrom GL_INTERFACEwhere reference26 like 'AP%'group by group_iD,reference1, reference26order by GROUP_ID, reference26;

5. My trial balance is wrong.First, insure that you have posted all your invoices andpayments. Remember that non-posted transactions donot show up on the trial balance report. This is thenumber one culprit for trial balance issues.

If it is actually determined that the data listed in thereport is incorrect, a script can be used to rebuild thetrial balance report. The script will backup yourcurrent trial balance table, delete the existing data, andthen use the data stored for your invoices

(AP_INVOICE_DISTRIBUTIONS) and payments(AP_INVOICE_PAYMENTS) to rebuild the data.

Should you need to rebuild your trial balance, pleasecall Oracle Support and request the rebuild script. Thisinformation is documented in Bug #375496.

6. I have paid invoices that continue to show up onthe trial balance report!In order for an invoice to be removed from the trialbalance report, it must have a correspondingpayment… even if the invoice was for a total of zerodollars. Therefore, you must issue zero dollarpayments for these invoices in order to mark them aspaid, and thus remove them from the trial balancereport.

7. My canceled invoices continue to show up on thetrial balance report!This occurs if you are using Automatic Offsets.

When the trial balance report is generated, it groups allthe entries for a supplier, and sums them byINVOICE_ID. If an invoice is paid, summing theinvoice and payment together should net to zero. If theamounts sum to zero, all transactions associated withthe invoice are removed from the report. Hence, youonly see suppliers where the sum of their payments donot equal the sum of their invoices, indicating that theyhave an outstanding liability, credit, or un-postedtransaction.

Because automatic offsets records a unique liabilityaccount for each distribution line, the trial balancesums transactions by INVOICE_ID andDISTRIBUTION_LINE_NUMBER. Under mostcircumstances, the trial balance looks the same,whether you are using automatic offsets or not.

However, reversed distribution lines work differently.When canceling an invoice, each distribution thatcurrently exists on the invoice must be reversed. Areversal entry is created for each distribution beingreversed. The reversal line shares the sameINVOICE_ID as the original distribution, but has itsown unique DISTRIBUTION_LINE_NUMBER. Whenthe trial balance report attempts to group and sum thetransactions by INVOICE_ID andDISTRIBUTION_LINE_NUMBER, it does not netthese items together and omit them from the trialbalance report.

Although Oracle development is working on anenhancement for a future release, there currently is nopatch for this issue. If your report is too large and youneed the zero amount transactions removed, you cancontact Oracle Support and they will help you resolvethis issue.

They will help you update the AP_TRIAL_BALANCEtable through sqlplus and enable the invoices andpayments to net together and thus be removed from thereport. However, this is only a temporary solution,because the next time you post, the same situation willoccur.

8. My GL liability account doesn’t agree with theAP trial balance report. Where can I look for help?1. Run the GL Account Analysis report for the liabilityaccount and for the date range in question. Look fortransactions with a source other than Payables. Thiscan quickly pinpoint any transactions incorrectlycharged to the account.

2. Are there still transactions in the GL_INTERFACEtable that need to be imported? Those transactionswould be displayed in the trial balance report, butwould not yet display in the GL accounts.

3. Have the transactions been posted within the GL?The GL account balance is not updated until the GLjournals are posted.

4. Are you still in pilot testing? Perhaps you haven’tconverted your outstanding invoices yet but the GLshows an up-to-date liability total. In this case, youwould need to account for the converted GL amountswhen balancing.

III. CASH MANAGEMENTINTEGRATION

If you are running the 10SC product, you have theability to use the Cash Management application andintegrate it with your Accounts Payable system. CashManagement will help you reconcile your bankstatements, create miscellaneous transactions, andmanage your cash flow.

When defining the Payables system, you can decidewhether or not you want the cash managementapplication to create accounting transactions when itprocesses the bank transactions. This option is called

"Allow Reconciliation Accounting", and it can bedefined in the payables setup option. If you enable thisoption, Cash Management will create accountingtransactions. If the option is not enabled, you can stilluse the Cash Management application, but it will notcreate accounting transactions.

Char: /Navigate - Setup - System - OptionsGUI: Setup - Options - Payables Options

Accounting Impact

When using the standard Payables system, the cashaccount is credited when issuing a payment. This holdstrue for both accrual and cash based accounting.

Example: Pay a $100 Invoice utilizing accrualaccounting

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

When utilizing reconciliation accounting, a cashclearing account will be charged instead of the cashaccount. When the payment document is reconciled orcleared within the Cash Management application,additional transactions will be created and chargedagainst the cash clearing account.

Example: Pay a $100 Invoice utilizing accrualaccounting. Then, clear the check in the CashManagement application.

GL Journal created for payment:Account Description Debit Credit1-200 Invoice Liability $1001-150 Cash Clearing $100

GL Journal created for payment clearing:Account Description Debit Credit1-150 Cash Clearing $1001-100 Cash Account $100

When the payments are cleared or reconciled, thetransactions will be created and inserted into thePayables system. (AP_RECON_DISTRIBUTIONStable). During this time, other miscellaneoustransactions can be created, such as bank charges,

errors and miscellaneous payments. The payablessystem will then integrate all these transactions into thestandard posting and closing process.

Closing Impact

Utilizing the Cash Management application will notalter the standard AP closing process, but will changethe some accounting transactions. In the standardclosing process, the invoice and payment transactionswere discussed. If you are using autoreconciliationaccounting, your closing reports will still look thesame, but will contain an additional section thatcontains the reconciliation transactions.

For Example:The AP transfer to GL process will include thereconciliation transactions, and the data will bedisplayed in a separate section on the AP Journal EntryAudit reports.

The Un-posted Invoice Sweep report will also display aseparate section for the reconciliation transactions.This allows the un-posted transactions to be reported orswept to the next period.

Conclusions

It is my desire that this paper has helped youunderstand the fundamental process of closing a periodin AP. Breaking the process into the 5 main categoriesshould help you understand the "state" of your system.If something appears incorrect in the posting orbalancing process, I hope that you are now betterequipped to troubleshoot the problem and determinewhat needs to be done to resolve the issue.

In addition, if you encounter a problem that requiresassistance, please remember to call Oracle Support.They may have seen the issue before and may alreadyhave a solution for the issue!

About the Author

Deidre Figueroa is a Technical Specialist with theOracle Support financials group. She has 8 years ofexperience implementing financial applications, bothnationally and internationally, including 1 1/2 yearswith Oracle Consulting. She has implemented theOracle Payables system several times, and is currently amember of the Accounts Payable support team.