Closing the AP Month
Content
Closing the AP Month - How it works and what to do when it doesn’ t!
Deidre Figueroa Oracle Corporation Abstract
Improve your AP process by understanding the fundamentals of closing the month in AP and learning what to do when the unexpected occurs. This paper provides an overview of the AP month-end process and discusses proven solutions to frequently encountered problems. Topics include new 10.7 and cash management features. is a simple process. You navigate to the close period form, select close, commit, and if all is well, your period will close and balance. Its that little phrase “if all is well” that introduces the bulk of the work required for the month end closing. If you understand the concepts of what happens during the closing and how your system setup affects the process, you can insure that “all is well” for your period to close and know that it is in balance. The closing process will be divided into 5 main steps. • Pre-post work • Posting • Reporting • Balancing • Closing
Scope
I. Fundamentals of Closing II. Solutions to Frequently Encountered Problems III. Overview of the Cash Management Impact on AP Please note that this paper does not discuss data entry, but focuses on insuring that the transactions entered are posted and balanced. The new 10.7 reporting features are integrated with the closing process, while a highlight of the Cash Management will be discussed separately.
Pre-Post Work
Before you can post to the GL, you want to review both your invoice and payment transactions to insure that they are ready to post. Insure invoices are ready to post: An invoice must be approved and/or have no posting holds in order to be selected for posting. To insure that
I. FUNDAMENTALS OF CLOSING
Month-end closing within the Oracle Payables system
Close/Open Period
Pre-Post Work
Reporting & Balancing
GL_INTERFACE
AP Data GL Data AP Transfer to GL Journal Import AP Data
your invoices are ready to post, you should run autoapproval and review the hold reports 1. Approve invoices The approval process attempts to approve invoices and remove any existing holds. If exceptions are found, some invoices may be placed on hold and not approved. If an invoice contains a system hold you need to manually fix the invoice and then re-run the autoapproval process to remove the hold. All user defined holds must be manually removed as they are not automatically removed by the autoapproval process. Payables - Autoapproval report 2. Look for unapproved invoices After running autoapproval, you want to look for invoices containing holds and Oracle provides 3 reports for this purpose. If an invoice appears on any of these reports, you either need to adjust the invoice or manually remove the hold. Invoice Hold Report - displays all held invoices. Posting Hold Report - only displays invoices with holds that prevent posting. Matching Hold Report - only displays invoices with matching holds. Insure Payments are made: The pre-work for payments is limited to insuring that the transactions you want recorded in this period have been processed. You must insure that all your payment batches have been completed: either confirmed or canceled. A period will not close if there are payment batches in a status other than confirmed or canceled. If an invoice is approved by will not pay, you should insure that the invoice is due to be paid and that the payment schedule is not on hold.
Step 2 - Journal Import Creates journals in the GL system Step 1 - Transfer from AP to GL: Posting begins in the AP system and can be started from a form or report, depending on the version of the applications you are using. Character: /Navigate Task GLPost Character (10.6 and 10.7) and GUI: Payables Transfer to General Ledger Report 1. The transfer process selects the invoices and payments that are ready to post to the general ledger. 2. The appropriate accounting transactions are created and inserted into the GL_INTERFACE table. This is the GL open interface used to import journals. It is a temporary table that holds all the accounting transactions received from AP until they are imported into the GL system. Once a transaction has been successfully imported into the GL system, it is deleted from the GL_INTERFACE table. 3. Transactions successfully selected and inserted into the GL_INTERFACE table are updated to "Posted" in the AP system. Transactions that were selected but encountered some exception are not inserted into the GL_INTERFACE table nor are they updated to “Posted”. (Exceptions can be an inactive accounting flexfield value, a GL_DATE in an un-opened GL period, exchange rate missing, etc.) When an invoice or payment encounters an exception, the distribution containing the exception will not post, yet will not prevent the other distributions from posting. For example, an invoice with 2 distributions can have one distribution that posted and one that encountered an exception. If you query the invoice, the status will show as partially posted. AP is Posted GL not yet Updated
Posting
Once the pre-work is complete, you are ready to post. The posting process selects and updates transactions in the AP subledger and creates accounting transactions for the general ledger. This process actually occurs in 2 distinct steps: Step 1 - Transfer from AP to GL Updates the AP system
ap_invoice_ distributions
AP Transfer to GL
gl_interface
ap_invoice_ payments AP Journal Reports
4. After the process is complete, the AP Journal reports are generated to display the results of the posting selection. These reports are very important and should be saved. They are generated directly from the posting process and can not be rerun at a latter date. Accounts Payable Journal Entry Audit Report This report lists the details of the accounting transactions that have been inserted into the GL_INTERFACE table. It displays the AP transaction, its corresponding debits and credits, the GL accounts affected, and more. Accounts Payable Journal Entry Exception Report This report displays the transactions that encountered an exception during the posting process. Each transaction includes an exception code that explains why it was prevented from posting. All transactions appearing on this report will require some change in order to be selected for posting the next time you run the AP transfer process. Once the AP Transfer to GL process has finished, only the AP system will have completed its portion of the posting process. As far as AP is concerned, posting is done and complete. For AP, there is no turning back from this point. The transactions are now in the GL_INTERFACE table waiting to be imported into the GL, via the Journal Import process. If the transactions are deleted from the GL_INTERFACE table, the AP system will still show the transactions as posted, even though the GL has not imported the transactions. Once an AP transaction has been posted, it can not be re-selected for posting again, and there is no system process to un-post a transaction. Therefore, NEVER DELETE the AP information from the GL_INTERFACE table unless you do not want the accounting transactions to be reflected in the GL.
Note!
the date entered in this field will be selected for posting. 2. Posting in Detail or Summary This parameter determines the level of detail information recorded in the general ledger. Regardless of what choice is made, the AP subledger maintains all the detail information for each AP transaction. Detail Detailed posting implies that every invoice or payment distribution will create a unique GL journal entry. For example, 2 invoices with distributions charged to the same expense account will create 2 journal entries, each with a distinct debit and credit.
Example Invoices Description Invoice #ABC Distribution #1 Invoice #XYZ Distribution #1
(Liability Account 1-200) Amount Expense Account $50 $100 1-500 1-500
GL Journal created Account Description 1-200 Liability - #ABC 1-200 Liability - #XYZ 1-500 Expense - #ABC 1-500 Expense - #XYZ
Debit
Credit $50 $100
$50 $100
Posting Options While submitting the AP Transfer to GL process, there are parameters that require input and each is important to the results received from the posting. Each parameter will be discussed, along with an example of its impact on the posting transactions. 1. Post Thru Date The GL_DATE attached to an invoice distribution or payment determines in which accounting period the transaction will be posted. All viable non-posted transactions having a GL_DATE less than or equal to
Summary Summary posting groups transactions with similar accounting flexfield information together, and creates a single GL journal for each grouping. Debits and credits made to the same accounting flexfield are grouped separately, they are not summed together and net out. Example Invoices Description Invoice #ABC Distribution #1 Distribution #2 Invoice #XYZ Distribution #1 Distribution #2 (Liability Account 1-200) Amount Expense Account $60 ($10) $100 $0 1-500 1-500 1-500 1-500
GL Journal Created Account Description 1-200 Liability Summary 1-200 Liability Summary 1-500 Expense Summary 1-500 Expense Summary
Debit $10 $160
Credit $160 $10
transaction came from, but the individual distribution detail for that item is summarized. By using the detail/summary and audit options together, you can get detail information for some transactions and summary information for others. Review the following examples to see how the options work together.
AP does not create accounting entries for zero amount transactions. If you have an individual payment or distribution line equal to zero, the transaction will not appear on the Journal Entry Audit report or the posting reports. However, the AP system will still flag the transaction as posted. 3. Posting with Audit Audit provides the information necessary to uniquely identify the AP transaction that created a GL accounting entry. (Information such as Invoice Number, Supplier Name, Check Number, etc.) Audit works with the detail/summary option to provide the information you desire to see in the GL. You must post in audit in order to utilize the following features: • Posting in detail • Zooming from GL to AP for transaction detail • Running the Posted Payment and Invoice reports Audit is required in order to post in detail. If you request detail information, but do not have audit selected, you will not see detail, but summary information in the GL_INTERFACE table. There are different types of accounting transactions that can be inserted into the GL_INTERFACE table, and for each type, you can determine whether to request audit or not. • Cash and Expense Transactions All transactions that affect a cash or expense account require Audit information. You can not change the default for these items. • Discount, Realized Gain/Loss, and Cash Clearing (future payment) transactions. You have the option to select Audit or No Audit. • Liability transactions You have the option to select Audit, No Audit or partial audit. Partial audit summarizes the liability transactions per invoice or payment, instead of for the entire posting batch. This provides enough detail to know which invoice or payment a
Example Invoices Description Invoice #ABC Distribution #1 Distribution #2 Invoice #XYZ Distribution #1 Distribution #2
(Liability Account 1-200) Amount Expense Account $50 $40 1-500 $10 1-500 $200 $125 1-500 $75 1-500
Example Payments Description Check #101 Pays Invoice #ABC Supplier Payment Discount Taken Check #102 Pays Invoice #XYZ Supplier Payment Discount Taken
(Cash Account 1-100) Amount Other Account $50 $45 $5 $100 $180 $20 1-200 1-700
1-200 1-700
Example #1: Post in detail Audit for Expense, Liability, Cash, and Discounts GL Journal created for invoices: Account Description 1-200 Liability - #ABC 1-200 Liability - #ABC 1-200 Liability - #XYZ 1-200 Liability - #XYZ 1-500 Expense - #ABC 1-500 Expense - #ABC 1-500 Expense - #XYZ 1-500 Expense - #XYZ
Debit
Credit $10 $40 $75 $125
$10 $40 $75 $125
GL Journal created for Payments: Account Description Debit 1-100 Cash - #101 1-100 Cash - #101 1-100 Cash - #102 1-100 Cash - #102 1-200 Liability - #101 $10 1-200 Liability - #101 $40 1-200 Liability - #102 $75 1-200 Liability - #102 $125 1-700 Discount - #101 1-700 Discount - #101 1-700 Discount - #102 1-700 Discount - #102
Credit $9 $36 $67.50 $112.50
automatically executed. If "Submit Journal Import" is equal to NO, then you manually submit the Journal Import process through the GL. Character: /Navigate Journal Import run GUI: Journal Import Run When submitting the process manually, there are 2 additional options that must be selected: Source and GROUP_ID. The source and GROUP_ID are used to uniquely identify which transactions in the GL_INTERFACE table you are requesting to import. For AP, the source will always be equal to ‘ Payables’ . The GROUP_ID will be unique for each posting batch that is created. A unique GROUP_ID is generated during the AP transfer process, and it identifies every transaction that belongs to the posting batch. The purpose of the journal import is to extract the accounting transactions and audit information from the GL_INTERFACE table and populate the appropriate GL tables. The transaction information in the GL_INTERFACE table will generate the actual accounting transactions in the GL journal tables (GL_BATCHES, GL_HEADERS and GL_LINES). During import, the audit information is removed from the GL_INTERFACE table and inserted into the GL_IMPORT_REFERENCES table. This table must be populated in order to produce the Posted Payment and Posted Invoice reports. This data is also used to zoom from a GL journal line to the originating AP transaction. The Audit information is the ONLY stored data link between the GL and AP transactions. If you do not post in audit, you can not perform these functions.
AP is Posted GL is Posted
$1 $4 7.50 $12.50
Example #2: Post in detail Audit for Expense and Cash No Audit for Liabilities and Discounts
GL Journal created for invoices: Account Description 1-200 Cr Liability Summary 1-500 Expense - #ABC 1-500 Expense - #ABC 1-500 Expense - #XYZ 1-500 Expense - #XYZ
Debit $10 $40 $75 $125
Credit $250
GL Journal created for Payments: Account Description Debit 1-100 Cash - #101 1-100 Cash - #101 1-100 Cash - #102 1-100 Cash - #102 1-200 Liability Summary $250 1-700 Discount Summary
Credit $9 $36 $67.50 $112.50 $25
gl_batches
Step 2 - Submit Journal Import At this point, AP has completed its portion of the posting process and the GL needs to complete the second portion: importing the accounting transactions into the GL system. When running the AP Transfer to GL process, the Journal Import process can be initiated from either the GL system or the AP system. If the option "Submit Journal Import" is equal to YES, once the AP transfer is complete the Journal Import program is
gl_interface
gl_headers Journal Import
gl_lines gl_import_ references Journal Import Reports AP Posted
Even though you instruct AP to post in Audit, your GL system must also be configured correctly in order to
import Audit information. This is handled via the Journal Import Source form in GL, where the standard install defaults to allow the import of Payables audit data. Character: /Navigate Setup Journal Sources GUI: Setup Journal Sources Import Journal References = YES As with the AP process, it is possible that an exception can occur while attempting to import a transaction. The Journal Import Exception report displays information about all the transactions that GL attempted to import. The transactions are noted as successful or containing exceptions. If an exception occurred, a code is associated with the transaction and an explanation for each code is displayed at the bottom of the report. If a batch encounters an exception, unless the exception can be posted to a suspense account, the entire batch is left in the GL_INTERFACE table and is not imported. When submitting the Journal Import process from the GL, there is an option to import descriptive flexfields. The AP system does not currently send the information required to populate the descriptive flexfields. Although this option can be used for importing from other applications, it does NOT work for AP journals. If you require this feature, at this time you will need to customize your AP system to insert the required descriptive flexfield information into the GL_INTERFACE table.
Note!
transaction is swept, its GL_DATE is changed to the first day of the next open period. (Remember that the GL_DATE determines in which period a transaction is posted). In report only mode, you can run the report as often as you like. IN SWEEP MODE, THE REPORT SHOULD ONLY BE RUN AFTER ALL DESIRED TRANSACTIONS HAVE BEEN POSTED IN THE CURRENT PERIOD. This is very important, because the sweep report selects all transactions that have NOT yet posted, and moves them to the next open period. There is NO process to "unsweep" transactions once they have been moved to the next open period. 2. Accounts Payable Trial Balance Report This report displays the individual liability for every supplier that has an open balance. The report is divided and summed by liability account, and should balance to the respective AP Liability account in the general ledger. Only invoices and payments that have been POSTED in AP will display on this report. (They need not be posted in the GL). 3. Posted Invoice Report, Posted Payment Report These reports display the invoices or payments that have been posted to the general ledger in a given date range. In order for a transaction to appear on these reports, it must have been posted in audit in AP, and imported into the general ledger. 4. Expense Distribution Report, Payment Distribution Report These reports display the accounting transactions that will be created when you post your transactions. They can be run before or after you post, as they analyze each AP transaction and display what accounting transactions will be created during the posting process. They show accounting detail that you can not see by viewing a transaction online. 5. Journal with GL Details Report Transaction Reconciliation Report These are new reports introduced in release 10.7, and are used to review details of transactions posted from AP and imported into the GL. The report is based on data in the GL_IMPORT_REFERENCES table, which is populated when you post in Audit. If you have not posted in Audit, this information will not be available.
Note!
Reporting
Once the posting process is complete, you are ready to run some key reports to insure that both your Payables sub-ledger and the General Ledger are in balance. Oracle provides numerous reports to assist you in balancing. 1. Unposted Invoice Sweep Report This report informs you about un-posted invoices and payments in the current or previous open periods. If un-posted transactions exist, you must decided if you want to post them in the current period or sweep them (move them) to the next open period. The parameter, "Report Only", determines if the unposted transactions are simply displayed or displayed AND SWEPT to the next open period. When a
These reports are basically the same, but utilize different parameters to select the information that is displayed. The Journal with GL details report selects data based upon GL entries created from AP transactions, while the Transaction Reconciliation report selects data based upon the AP transactions. Therefore, if you have an AP transaction for which you would like to see the accompanying GL transactions, use the reconciliation report. If you have a GL journal for which you would like to see the originating AP transaction, run the GL details report.
Balancing AP to the GL To balance the AP and GL systems together, the AP Trial Balance report should agree with the GL liability accounts and the posting reports.
AP
GL
gl_import_ references
ap_trial_balance
Balancing
The reports described above will be used in the balancing process. To determine if your system is in balance, you need to insure that the amount reported in AP matches the amount reported in the GL. In addition, there are times when you want to see that the AP system is in balance with itself. (i.e. Pilot testing, checking the validity of converted data, or your AP and GL systems don’ balance together). t Balancing AP Every transaction that is posted from AP to the GL is reflected in the Accounts Payable Trial Balance report. If you want to test the data on this report against the transactions entered for a supplier, you can spot check individual suppliers. View the outstanding balance for the individual supplier via the invoice inquiry form and compare it to the data on the trial balance report. The on-line balance inquiry includes all transactions, unlike the trail balance report that only includes posted transactions. Therefore, the on-line supplier balance should match the data reported on the trial balance report, +/- any non-posted transactions. If a supplier does not appear on the trial balance report, that indicates there is no outstanding posted liability for that supplier. Character: /Navigate Invoice Inquiry Search Option: Balance by Supplier GUI: Invoices Inquiry Invoices Calculate Balance Owed Trial Balance Total Non-Posted Invoices Non-Posted Payments Invoice Supplier Total (Posted Items) (Posted Invoice Register Report) (Posted Payment Register Report) (On-line Inquiry)
AP Trial Balance AP Posted
1. GL posted transactions and AP trial balance Utilizing the trial balance report and the posting reports, you can insure that the transactions imported into the GL system agree with those entered and posted in the AP system. Although the posting reports are run from the AP menu, they are based on data stored in the GL system (GL_IMPORT_REFERENCES table). If you did not post in audit or are using Cash based accounting, you will not be able to perform this balancing process. To balance, you will need this months and last months AP Trial Balance Report, and this months posting reports. Last months trial balance, plus this months transactions should equal this months trial balance. Last Months Trial Balance This Months Posted Invoices This Months Posted Invoice Payments Current Trial Balance
+ -
(Posted Invoice Register Report) (Posted Payment Register Report (On-line Inquiry)
=
2. Balance GL liability account to the trial balance Verify that the GL liability accounts agree with the data reported on the AP trial balance report. 3. Balance GL batch to the AP posting batch When you post and import transactions from AP into the GL system, a unique GL batch is created. You can balance a GL batch against the AP Journal Entry Audit report that was generated during the AP transfer process.
+ =
If your set of books allows intercompany accounting, the GL batch totals may be higher than the totals listed on the AP Journal Entry Audit report. When posting a GL batch, if transactions do not balance across balancing segments, the GL system will automatically create the entries necessary to balance the amounts in each segment. These transactions will be displayed in the posted GL batch, but will not be reflected in the AP system. AP is not concerned with segment balances, but with the overall balancing of debits and credits per transaction. Since the transactions are NOT created during the Journal Import process, you will not see the intercompany transactions until you post the GL batch.
As you can see, the difference between the posted GL batch and the AP Journal Entry report is equal to the amount of the intercompany transactions created during the GL posting process.
Closing the Period
When you are comfortable that your system is in balance, you are ready to close the period. To open or close a period in the Payables system, use the period control form. Character: /Navigate - Control - Periods GUI: Setup: Calendar - Accounting AP Accounting Periods Although the AP periods mirror those defined in your GL Set of Books, they are controlled independently. Both the AP and GL systems are required to open and close their own periods. When attempting to close an AP period, if un-posted transactions exist, a message will be displayed and the period will not be closed. At that point, you need to repeat the pre-post steps mentioned above in order to identify and adjust, or sweep the un-posted transactions. You can re-open a closed period in AP as long as it is not finally closed, and the corresponding GL period is not closed. Once a final close has been done, the period can never be reopened. It is recommended that you final close a period only if it is from a prior year.
Example AP Invoice Description Invoice #ABC Distribution #1 Distribution #2
(Liability Account 1-200) Balancing Segments: 1 and 2 Amount Expense Account $40 $60 1-500 2-500
AP Transactions on AP Journal Entry Report Account Description Debit Credit 1-200 Liability - Dist. #1 $40 1-200 Liability - Dist. #2 $60 1-500 Expense - Dist. #1 $40 2-500 Expense - Dist. #2 $60 GL Batch: Transactions from GL Journal Import Account Description Debit Credit 1-200 Liability - Dist. #1 $40 1-200 Liability - Dist. #2 $60 1-500 Expense - Dist. #1 $40 2-500 Expense - Dist. #2 $60
II. SOLUTIONS TO FREQUENTLY ENCOUNTERED PROBLEMS
Even after you understand the fundamentals it is possible to encounter a problem during your closing process. The following entries describe some frequently encountered issues, and provide proven solutions for dealing with them. 1. My invoice was on hold, but it still posted. All holds prevent invoices from being paid, but not all holds prevent invoices from posting. The posting option can be changed on most holds (with the exception of the system holds). To change the posting options of a hold, use the Define Invoice Approval form.
GL Batch: Transactions after running GL Post Account Description Debit Credit 1-200 Liability - Dist. #1 $40 1-200 Liability - Dist. #2 $60 1-500 Expense - Dist. #1 $40 2-500 Expense - Dist. #2 $60 1-199 Intercompany $60 Receivable Segment 1 2-299 Intercompany $60 Payable Segment 2
Character: /Navigate Setup Invoices Approvals GUI: Navigate Setup Invoices Approvals Unfortunately, once an invoice has been posted, there is no un-post option. You will have to create manual GL journal entries if you want to back out the posting.
Example: Description Invoice #ABC Distribution #1 Distribution #2
Amount $40 $60
GL_DATE 15-FEB-97 25-FEB-97
2. Someone deleted the AP data from the GL_INTERFACE table before we imported to the GL! Although there is no standard process to re-post your AP transactions, there are times when it is necessary to do so. Oracle Support does have some pre-defined scripts to help you with this situation. These scripts will go into the database and manually "un-post" your transactions. You can then re-run the AP transfer to GL process, and the transactions will be re-selected for posting, inserted into the GL_INTERFACE table, re-flagged as posted, and will be ready to import into the GL system. Should you run into a situation requiring re-posting, please contact Oracle support. They need to work with you to analyze your situation and determine what changes your system requires and which scripts will be needed. Although Oracle can provide help in fixing the transactions, it is up to you to determine WHICH transactions need to be adjusted. This process can be greatly simplified if you retain the AP Journal Entry Audit report generated from the AP Transfer to GL process. If you do not maintain the report, it will be difficult to identify the problem transactions.
Example #1: Query invoice on 26-FEB-97 The invoice GL_DATE will display 25-FEB-97
Example #2: Query invoice in April, when FEBRUARY is already closed. The invoice GL_DATE will display 01-APR-97
4. I am trying to run the Journal import process from the GL system, but no transactions are being imported. When running the Journal Import process from GL, you must select source = Payables, and select a GROUP_ID. If you do not select a GROUP_ID, the process will run, but no transactions will be imported. If you have more than one GROUP_ID to choose from, you may not know which one to select. Unfortunately, there is no report that you can run to get this ID. If needed, you can run the following select statement from sqlplus to identify the GROUP_ID associated with your AP Posting Batch. col batchname format a15; col trans_type format a15; select distinct reference1 batchname, GROUP_ID, reference26 trans_type from GL_INTERFACE where reference26 like 'AP%' group by group_iD,reference1, reference26 order by GROUP_ID, reference26;
3. My invoice displays a different date from the period in which it posted. The GL_DATE associated with an invoice distribution determines the posting period, not the GL-DATE associated with the invoice. The GL_DATE at the invoice level is used for display purposes only. If you query a posted invoice, the GL_DATE at the invoice level will default to the latest GL_DATE from your distributions, or the first day in the next open period. Do not worry that the distributions posted in one period and now the invoice shows a different date. The invoice GL_DATE is display only, purely intended to help make your input of distributions easier.
5. My trial balance is wrong. First, insure that you have posted all your invoices and payments. Remember that non-posted transactions do not show up on the trial balance report. This is the number one culprit for trial balance issues. If it is actually determined that the data listed in the report is incorrect, a script can be used to rebuild the trial balance report. The script will backup your current trial balance table, delete the existing data, and then use the data stored for your invoices
(AP_INVOICE_DISTRIBUTIONS) and payments (AP_INVOICE_PAYMENTS) to rebuild the data. Should you need to rebuild your trial balance, please call Oracle Support and request the rebuild script. This information is documented in Bug #375496.
Although Oracle development is working on an enhancement for a future release, there currently is no patch for this issue. If your report is too large and you need the zero amount transactions removed, you can contact Oracle Support and they will help you resolve this issue. They will help you update the AP_TRIAL_BALANCE table through sqlplus and enable the invoices and payments to net together and thus be removed from the report. However, this is only a temporary solution, because the next time you post, the same situation will occur.
6. I have paid invoices that continue to show up on the trial balance report! In order for an invoice to be removed from the trial balance report, it must have a corresponding payment… even if the invoice was for a total of zero dollars. Therefore, you must issue zero dollar payments for these invoices in order to mark them as paid, and thus remove them from the trial balance report.
7. My canceled invoices continue to show up on the trial balance report! This occurs if you are using Automatic Offsets. When the trial balance report is generated, it groups all the entries for a supplier, and sums them by INVOICE_ID. If an invoice is paid, summing the invoice and payment together should net to zero. If the amounts sum to zero, all transactions associated with the invoice are removed from the report. Hence, you only see suppliers where the sum of their payments do not equal the sum of their invoices, indicating that they have an outstanding liability, credit, or un-posted transaction. Because automatic offsets records a unique liability account for each distribution line, the trial balance sums transactions by INVOICE_ID and DISTRIBUTION_LINE_NUMBER. Under most circumstances, the trial balance looks the same, whether you are using automatic offsets or not. However, reversed distribution lines work differently. When canceling an invoice, each distribution that currently exists on the invoice must be reversed. A reversal entry is created for each distribution being reversed. The reversal line shares the same INVOICE_ID as the original distribution, but has its own unique DISTRIBUTION_LINE_NUMBER. When the trial balance report attempts to group and sum the transactions by INVOICE_ID and DISTRIBUTION_LINE_NUMBER, it does not net these items together and omit them from the trial balance report.
8. My GL liability account doesn’ agree with the t AP trial balance report. Where can I look for help? 1. Run the GL Account Analysis report for the liability account and for the date range in question. Look for transactions with a source other than Payables. This can quickly pinpoint any transactions incorrectly charged to the account. 2. Are there still transactions in the GL_INTERFACE table that need to be imported? Those transactions would be displayed in the trial balance report, but would not yet display in the GL accounts. 3. Have the transactions been posted within the GL? The GL account balance is not updated until the GL journals are posted. 4. Are you still in pilot testing? Perhaps you haven’ t converted your outstanding invoices yet but the GL shows an up-to-date liability total. In this case, you would need to account for the converted GL amounts when balancing.
III. CASH MANAGEMENT INTEGRATION
If you are running the 10SC product, you have the ability to use the Cash Management application and integrate it with your Accounts Payable system. Cash Management will help you reconcile your bank statements, create miscellaneous transactions, and manage your cash flow. When defining the Payables system, you can decide whether or not you want the cash management application to create accounting transactions when it processes the bank transactions. This option is called
"Allow Reconciliation Accounting", and it can be defined in the payables setup option. If you enable this option, Cash Management will create accounting transactions. If the option is not enabled, you can still use the Cash Management application, but it will not create accounting transactions. Char: /Navigate - Setup - System - Options GUI: Setup - Options - Payables Options
errors and miscellaneous payments. The payables system will then integrate all these transactions into the standard posting and closing process.
Closing Impact
Utilizing the Cash Management application will not alter the standard AP closing process, but will change the some accounting transactions. In the standard closing process, the invoice and payment transactions were discussed. If you are using autoreconciliation accounting, your closing reports will still look the same, but will contain an additional section that contains the reconciliation transactions. For Example: The AP transfer to GL process will include the reconciliation transactions, and the data will be displayed in a separate section on the AP Journal Entry Audit reports.
Accounting Impact
When using the standard Payables system, the cash account is credited when issuing a payment. This holds true for both accrual and cash based accounting. Example: Pay a $100 Invoice utilizing accrual accounting GL Journal created for payment: Account Description Debit 1-200 Invoice Liability $100 1-100 Cash Account
Credit $100
The Un-posted Invoice Sweep report will also display a separate section for the reconciliation transactions. This allows the un-posted transactions to be reported or swept to the next period.
When utilizing reconciliation accounting, a cash clearing account will be charged instead of the cash account. When the payment document is reconciled or cleared within the Cash Management application, additional transactions will be created and charged against the cash clearing account. Example: Pay a $100 Invoice utilizing accrual accounting. Then, clear the check in the Cash Management application. GL Journal created for payment: Account Description Debit 1-200 Invoice Liability $100 1-150 Cash Clearing GL Journal created for payment clearing: Account Description Debit 1-150 Cash Clearing $100 1-100 Cash Account
Conclusions
It is my desire that this paper has helped you understand the fundamental process of closing a period in AP. Breaking the process into the 5 main categories should help you understand the "state" of your system. If something appears incorrect in the posting or balancing process, I hope that you are now better equipped to troubleshoot the problem and determine what needs to be done to resolve the issue. In addition, if you encounter a problem that requires assistance, please remember to call Oracle Support. They may have seen the issue before and may already have a solution for the issue!
Credit $100
Credit $100
About the Author
Deidre Figueroa is a Technical Specialist with the Oracle Support financials group. She has 8 years of experience implementing financial applications, both nationally and internationally, including 1 1/2 years with Oracle Consulting. She has implemented the Oracle Payables system several times, and is currently a member of the Accounts Payable support team.
When the payments are cleared or reconciled, the transactions will be created and inserted into the Payables system. (AP_RECON_DISTRIBUTIONS table). During this time, other miscellaneous transactions can be created, such as bank charges,
Deidre Figueroa Oracle Corporation Abstract
Improve your AP process by understanding the fundamentals of closing the month in AP and learning what to do when the unexpected occurs. This paper provides an overview of the AP month-end process and discusses proven solutions to frequently encountered problems. Topics include new 10.7 and cash management features. is a simple process. You navigate to the close period form, select close, commit, and if all is well, your period will close and balance. Its that little phrase “if all is well” that introduces the bulk of the work required for the month end closing. If you understand the concepts of what happens during the closing and how your system setup affects the process, you can insure that “all is well” for your period to close and know that it is in balance. The closing process will be divided into 5 main steps. • Pre-post work • Posting • Reporting • Balancing • Closing
Scope
I. Fundamentals of Closing II. Solutions to Frequently Encountered Problems III. Overview of the Cash Management Impact on AP Please note that this paper does not discuss data entry, but focuses on insuring that the transactions entered are posted and balanced. The new 10.7 reporting features are integrated with the closing process, while a highlight of the Cash Management will be discussed separately.
Pre-Post Work
Before you can post to the GL, you want to review both your invoice and payment transactions to insure that they are ready to post. Insure invoices are ready to post: An invoice must be approved and/or have no posting holds in order to be selected for posting. To insure that
I. FUNDAMENTALS OF CLOSING
Month-end closing within the Oracle Payables system
Close/Open Period
Pre-Post Work
Reporting & Balancing
GL_INTERFACE
AP Data GL Data AP Transfer to GL Journal Import AP Data
your invoices are ready to post, you should run autoapproval and review the hold reports 1. Approve invoices The approval process attempts to approve invoices and remove any existing holds. If exceptions are found, some invoices may be placed on hold and not approved. If an invoice contains a system hold you need to manually fix the invoice and then re-run the autoapproval process to remove the hold. All user defined holds must be manually removed as they are not automatically removed by the autoapproval process. Payables - Autoapproval report 2. Look for unapproved invoices After running autoapproval, you want to look for invoices containing holds and Oracle provides 3 reports for this purpose. If an invoice appears on any of these reports, you either need to adjust the invoice or manually remove the hold. Invoice Hold Report - displays all held invoices. Posting Hold Report - only displays invoices with holds that prevent posting. Matching Hold Report - only displays invoices with matching holds. Insure Payments are made: The pre-work for payments is limited to insuring that the transactions you want recorded in this period have been processed. You must insure that all your payment batches have been completed: either confirmed or canceled. A period will not close if there are payment batches in a status other than confirmed or canceled. If an invoice is approved by will not pay, you should insure that the invoice is due to be paid and that the payment schedule is not on hold.
Step 2 - Journal Import Creates journals in the GL system Step 1 - Transfer from AP to GL: Posting begins in the AP system and can be started from a form or report, depending on the version of the applications you are using. Character: /Navigate Task GLPost Character (10.6 and 10.7) and GUI: Payables Transfer to General Ledger Report 1. The transfer process selects the invoices and payments that are ready to post to the general ledger. 2. The appropriate accounting transactions are created and inserted into the GL_INTERFACE table. This is the GL open interface used to import journals. It is a temporary table that holds all the accounting transactions received from AP until they are imported into the GL system. Once a transaction has been successfully imported into the GL system, it is deleted from the GL_INTERFACE table. 3. Transactions successfully selected and inserted into the GL_INTERFACE table are updated to "Posted" in the AP system. Transactions that were selected but encountered some exception are not inserted into the GL_INTERFACE table nor are they updated to “Posted”. (Exceptions can be an inactive accounting flexfield value, a GL_DATE in an un-opened GL period, exchange rate missing, etc.) When an invoice or payment encounters an exception, the distribution containing the exception will not post, yet will not prevent the other distributions from posting. For example, an invoice with 2 distributions can have one distribution that posted and one that encountered an exception. If you query the invoice, the status will show as partially posted. AP is Posted GL not yet Updated
Posting
Once the pre-work is complete, you are ready to post. The posting process selects and updates transactions in the AP subledger and creates accounting transactions for the general ledger. This process actually occurs in 2 distinct steps: Step 1 - Transfer from AP to GL Updates the AP system
ap_invoice_ distributions
AP Transfer to GL
gl_interface
ap_invoice_ payments AP Journal Reports
4. After the process is complete, the AP Journal reports are generated to display the results of the posting selection. These reports are very important and should be saved. They are generated directly from the posting process and can not be rerun at a latter date. Accounts Payable Journal Entry Audit Report This report lists the details of the accounting transactions that have been inserted into the GL_INTERFACE table. It displays the AP transaction, its corresponding debits and credits, the GL accounts affected, and more. Accounts Payable Journal Entry Exception Report This report displays the transactions that encountered an exception during the posting process. Each transaction includes an exception code that explains why it was prevented from posting. All transactions appearing on this report will require some change in order to be selected for posting the next time you run the AP transfer process. Once the AP Transfer to GL process has finished, only the AP system will have completed its portion of the posting process. As far as AP is concerned, posting is done and complete. For AP, there is no turning back from this point. The transactions are now in the GL_INTERFACE table waiting to be imported into the GL, via the Journal Import process. If the transactions are deleted from the GL_INTERFACE table, the AP system will still show the transactions as posted, even though the GL has not imported the transactions. Once an AP transaction has been posted, it can not be re-selected for posting again, and there is no system process to un-post a transaction. Therefore, NEVER DELETE the AP information from the GL_INTERFACE table unless you do not want the accounting transactions to be reflected in the GL.
Note!
the date entered in this field will be selected for posting. 2. Posting in Detail or Summary This parameter determines the level of detail information recorded in the general ledger. Regardless of what choice is made, the AP subledger maintains all the detail information for each AP transaction. Detail Detailed posting implies that every invoice or payment distribution will create a unique GL journal entry. For example, 2 invoices with distributions charged to the same expense account will create 2 journal entries, each with a distinct debit and credit.
Example Invoices Description Invoice #ABC Distribution #1 Invoice #XYZ Distribution #1
(Liability Account 1-200) Amount Expense Account $50 $100 1-500 1-500
GL Journal created Account Description 1-200 Liability - #ABC 1-200 Liability - #XYZ 1-500 Expense - #ABC 1-500 Expense - #XYZ
Debit
Credit $50 $100
$50 $100
Posting Options While submitting the AP Transfer to GL process, there are parameters that require input and each is important to the results received from the posting. Each parameter will be discussed, along with an example of its impact on the posting transactions. 1. Post Thru Date The GL_DATE attached to an invoice distribution or payment determines in which accounting period the transaction will be posted. All viable non-posted transactions having a GL_DATE less than or equal to
Summary Summary posting groups transactions with similar accounting flexfield information together, and creates a single GL journal for each grouping. Debits and credits made to the same accounting flexfield are grouped separately, they are not summed together and net out. Example Invoices Description Invoice #ABC Distribution #1 Distribution #2 Invoice #XYZ Distribution #1 Distribution #2 (Liability Account 1-200) Amount Expense Account $60 ($10) $100 $0 1-500 1-500 1-500 1-500
GL Journal Created Account Description 1-200 Liability Summary 1-200 Liability Summary 1-500 Expense Summary 1-500 Expense Summary
Debit $10 $160
Credit $160 $10
transaction came from, but the individual distribution detail for that item is summarized. By using the detail/summary and audit options together, you can get detail information for some transactions and summary information for others. Review the following examples to see how the options work together.
AP does not create accounting entries for zero amount transactions. If you have an individual payment or distribution line equal to zero, the transaction will not appear on the Journal Entry Audit report or the posting reports. However, the AP system will still flag the transaction as posted. 3. Posting with Audit Audit provides the information necessary to uniquely identify the AP transaction that created a GL accounting entry. (Information such as Invoice Number, Supplier Name, Check Number, etc.) Audit works with the detail/summary option to provide the information you desire to see in the GL. You must post in audit in order to utilize the following features: • Posting in detail • Zooming from GL to AP for transaction detail • Running the Posted Payment and Invoice reports Audit is required in order to post in detail. If you request detail information, but do not have audit selected, you will not see detail, but summary information in the GL_INTERFACE table. There are different types of accounting transactions that can be inserted into the GL_INTERFACE table, and for each type, you can determine whether to request audit or not. • Cash and Expense Transactions All transactions that affect a cash or expense account require Audit information. You can not change the default for these items. • Discount, Realized Gain/Loss, and Cash Clearing (future payment) transactions. You have the option to select Audit or No Audit. • Liability transactions You have the option to select Audit, No Audit or partial audit. Partial audit summarizes the liability transactions per invoice or payment, instead of for the entire posting batch. This provides enough detail to know which invoice or payment a
Example Invoices Description Invoice #ABC Distribution #1 Distribution #2 Invoice #XYZ Distribution #1 Distribution #2
(Liability Account 1-200) Amount Expense Account $50 $40 1-500 $10 1-500 $200 $125 1-500 $75 1-500
Example Payments Description Check #101 Pays Invoice #ABC Supplier Payment Discount Taken Check #102 Pays Invoice #XYZ Supplier Payment Discount Taken
(Cash Account 1-100) Amount Other Account $50 $45 $5 $100 $180 $20 1-200 1-700
1-200 1-700
Example #1: Post in detail Audit for Expense, Liability, Cash, and Discounts GL Journal created for invoices: Account Description 1-200 Liability - #ABC 1-200 Liability - #ABC 1-200 Liability - #XYZ 1-200 Liability - #XYZ 1-500 Expense - #ABC 1-500 Expense - #ABC 1-500 Expense - #XYZ 1-500 Expense - #XYZ
Debit
Credit $10 $40 $75 $125
$10 $40 $75 $125
GL Journal created for Payments: Account Description Debit 1-100 Cash - #101 1-100 Cash - #101 1-100 Cash - #102 1-100 Cash - #102 1-200 Liability - #101 $10 1-200 Liability - #101 $40 1-200 Liability - #102 $75 1-200 Liability - #102 $125 1-700 Discount - #101 1-700 Discount - #101 1-700 Discount - #102 1-700 Discount - #102
Credit $9 $36 $67.50 $112.50
automatically executed. If "Submit Journal Import" is equal to NO, then you manually submit the Journal Import process through the GL. Character: /Navigate Journal Import run GUI: Journal Import Run When submitting the process manually, there are 2 additional options that must be selected: Source and GROUP_ID. The source and GROUP_ID are used to uniquely identify which transactions in the GL_INTERFACE table you are requesting to import. For AP, the source will always be equal to ‘ Payables’ . The GROUP_ID will be unique for each posting batch that is created. A unique GROUP_ID is generated during the AP transfer process, and it identifies every transaction that belongs to the posting batch. The purpose of the journal import is to extract the accounting transactions and audit information from the GL_INTERFACE table and populate the appropriate GL tables. The transaction information in the GL_INTERFACE table will generate the actual accounting transactions in the GL journal tables (GL_BATCHES, GL_HEADERS and GL_LINES). During import, the audit information is removed from the GL_INTERFACE table and inserted into the GL_IMPORT_REFERENCES table. This table must be populated in order to produce the Posted Payment and Posted Invoice reports. This data is also used to zoom from a GL journal line to the originating AP transaction. The Audit information is the ONLY stored data link between the GL and AP transactions. If you do not post in audit, you can not perform these functions.
AP is Posted GL is Posted
$1 $4 7.50 $12.50
Example #2: Post in detail Audit for Expense and Cash No Audit for Liabilities and Discounts
GL Journal created for invoices: Account Description 1-200 Cr Liability Summary 1-500 Expense - #ABC 1-500 Expense - #ABC 1-500 Expense - #XYZ 1-500 Expense - #XYZ
Debit $10 $40 $75 $125
Credit $250
GL Journal created for Payments: Account Description Debit 1-100 Cash - #101 1-100 Cash - #101 1-100 Cash - #102 1-100 Cash - #102 1-200 Liability Summary $250 1-700 Discount Summary
Credit $9 $36 $67.50 $112.50 $25
gl_batches
Step 2 - Submit Journal Import At this point, AP has completed its portion of the posting process and the GL needs to complete the second portion: importing the accounting transactions into the GL system. When running the AP Transfer to GL process, the Journal Import process can be initiated from either the GL system or the AP system. If the option "Submit Journal Import" is equal to YES, once the AP transfer is complete the Journal Import program is
gl_interface
gl_headers Journal Import
gl_lines gl_import_ references Journal Import Reports AP Posted
Even though you instruct AP to post in Audit, your GL system must also be configured correctly in order to
import Audit information. This is handled via the Journal Import Source form in GL, where the standard install defaults to allow the import of Payables audit data. Character: /Navigate Setup Journal Sources GUI: Setup Journal Sources Import Journal References = YES As with the AP process, it is possible that an exception can occur while attempting to import a transaction. The Journal Import Exception report displays information about all the transactions that GL attempted to import. The transactions are noted as successful or containing exceptions. If an exception occurred, a code is associated with the transaction and an explanation for each code is displayed at the bottom of the report. If a batch encounters an exception, unless the exception can be posted to a suspense account, the entire batch is left in the GL_INTERFACE table and is not imported. When submitting the Journal Import process from the GL, there is an option to import descriptive flexfields. The AP system does not currently send the information required to populate the descriptive flexfields. Although this option can be used for importing from other applications, it does NOT work for AP journals. If you require this feature, at this time you will need to customize your AP system to insert the required descriptive flexfield information into the GL_INTERFACE table.
Note!
transaction is swept, its GL_DATE is changed to the first day of the next open period. (Remember that the GL_DATE determines in which period a transaction is posted). In report only mode, you can run the report as often as you like. IN SWEEP MODE, THE REPORT SHOULD ONLY BE RUN AFTER ALL DESIRED TRANSACTIONS HAVE BEEN POSTED IN THE CURRENT PERIOD. This is very important, because the sweep report selects all transactions that have NOT yet posted, and moves them to the next open period. There is NO process to "unsweep" transactions once they have been moved to the next open period. 2. Accounts Payable Trial Balance Report This report displays the individual liability for every supplier that has an open balance. The report is divided and summed by liability account, and should balance to the respective AP Liability account in the general ledger. Only invoices and payments that have been POSTED in AP will display on this report. (They need not be posted in the GL). 3. Posted Invoice Report, Posted Payment Report These reports display the invoices or payments that have been posted to the general ledger in a given date range. In order for a transaction to appear on these reports, it must have been posted in audit in AP, and imported into the general ledger. 4. Expense Distribution Report, Payment Distribution Report These reports display the accounting transactions that will be created when you post your transactions. They can be run before or after you post, as they analyze each AP transaction and display what accounting transactions will be created during the posting process. They show accounting detail that you can not see by viewing a transaction online. 5. Journal with GL Details Report Transaction Reconciliation Report These are new reports introduced in release 10.7, and are used to review details of transactions posted from AP and imported into the GL. The report is based on data in the GL_IMPORT_REFERENCES table, which is populated when you post in Audit. If you have not posted in Audit, this information will not be available.
Note!
Reporting
Once the posting process is complete, you are ready to run some key reports to insure that both your Payables sub-ledger and the General Ledger are in balance. Oracle provides numerous reports to assist you in balancing. 1. Unposted Invoice Sweep Report This report informs you about un-posted invoices and payments in the current or previous open periods. If un-posted transactions exist, you must decided if you want to post them in the current period or sweep them (move them) to the next open period. The parameter, "Report Only", determines if the unposted transactions are simply displayed or displayed AND SWEPT to the next open period. When a
These reports are basically the same, but utilize different parameters to select the information that is displayed. The Journal with GL details report selects data based upon GL entries created from AP transactions, while the Transaction Reconciliation report selects data based upon the AP transactions. Therefore, if you have an AP transaction for which you would like to see the accompanying GL transactions, use the reconciliation report. If you have a GL journal for which you would like to see the originating AP transaction, run the GL details report.
Balancing AP to the GL To balance the AP and GL systems together, the AP Trial Balance report should agree with the GL liability accounts and the posting reports.
AP
GL
gl_import_ references
ap_trial_balance
Balancing
The reports described above will be used in the balancing process. To determine if your system is in balance, you need to insure that the amount reported in AP matches the amount reported in the GL. In addition, there are times when you want to see that the AP system is in balance with itself. (i.e. Pilot testing, checking the validity of converted data, or your AP and GL systems don’ balance together). t Balancing AP Every transaction that is posted from AP to the GL is reflected in the Accounts Payable Trial Balance report. If you want to test the data on this report against the transactions entered for a supplier, you can spot check individual suppliers. View the outstanding balance for the individual supplier via the invoice inquiry form and compare it to the data on the trial balance report. The on-line balance inquiry includes all transactions, unlike the trail balance report that only includes posted transactions. Therefore, the on-line supplier balance should match the data reported on the trial balance report, +/- any non-posted transactions. If a supplier does not appear on the trial balance report, that indicates there is no outstanding posted liability for that supplier. Character: /Navigate Invoice Inquiry Search Option: Balance by Supplier GUI: Invoices Inquiry Invoices Calculate Balance Owed Trial Balance Total Non-Posted Invoices Non-Posted Payments Invoice Supplier Total (Posted Items) (Posted Invoice Register Report) (Posted Payment Register Report) (On-line Inquiry)
AP Trial Balance AP Posted
1. GL posted transactions and AP trial balance Utilizing the trial balance report and the posting reports, you can insure that the transactions imported into the GL system agree with those entered and posted in the AP system. Although the posting reports are run from the AP menu, they are based on data stored in the GL system (GL_IMPORT_REFERENCES table). If you did not post in audit or are using Cash based accounting, you will not be able to perform this balancing process. To balance, you will need this months and last months AP Trial Balance Report, and this months posting reports. Last months trial balance, plus this months transactions should equal this months trial balance. Last Months Trial Balance This Months Posted Invoices This Months Posted Invoice Payments Current Trial Balance
+ -
(Posted Invoice Register Report) (Posted Payment Register Report (On-line Inquiry)
=
2. Balance GL liability account to the trial balance Verify that the GL liability accounts agree with the data reported on the AP trial balance report. 3. Balance GL batch to the AP posting batch When you post and import transactions from AP into the GL system, a unique GL batch is created. You can balance a GL batch against the AP Journal Entry Audit report that was generated during the AP transfer process.
+ =
If your set of books allows intercompany accounting, the GL batch totals may be higher than the totals listed on the AP Journal Entry Audit report. When posting a GL batch, if transactions do not balance across balancing segments, the GL system will automatically create the entries necessary to balance the amounts in each segment. These transactions will be displayed in the posted GL batch, but will not be reflected in the AP system. AP is not concerned with segment balances, but with the overall balancing of debits and credits per transaction. Since the transactions are NOT created during the Journal Import process, you will not see the intercompany transactions until you post the GL batch.
As you can see, the difference between the posted GL batch and the AP Journal Entry report is equal to the amount of the intercompany transactions created during the GL posting process.
Closing the Period
When you are comfortable that your system is in balance, you are ready to close the period. To open or close a period in the Payables system, use the period control form. Character: /Navigate - Control - Periods GUI: Setup: Calendar - Accounting AP Accounting Periods Although the AP periods mirror those defined in your GL Set of Books, they are controlled independently. Both the AP and GL systems are required to open and close their own periods. When attempting to close an AP period, if un-posted transactions exist, a message will be displayed and the period will not be closed. At that point, you need to repeat the pre-post steps mentioned above in order to identify and adjust, or sweep the un-posted transactions. You can re-open a closed period in AP as long as it is not finally closed, and the corresponding GL period is not closed. Once a final close has been done, the period can never be reopened. It is recommended that you final close a period only if it is from a prior year.
Example AP Invoice Description Invoice #ABC Distribution #1 Distribution #2
(Liability Account 1-200) Balancing Segments: 1 and 2 Amount Expense Account $40 $60 1-500 2-500
AP Transactions on AP Journal Entry Report Account Description Debit Credit 1-200 Liability - Dist. #1 $40 1-200 Liability - Dist. #2 $60 1-500 Expense - Dist. #1 $40 2-500 Expense - Dist. #2 $60 GL Batch: Transactions from GL Journal Import Account Description Debit Credit 1-200 Liability - Dist. #1 $40 1-200 Liability - Dist. #2 $60 1-500 Expense - Dist. #1 $40 2-500 Expense - Dist. #2 $60
II. SOLUTIONS TO FREQUENTLY ENCOUNTERED PROBLEMS
Even after you understand the fundamentals it is possible to encounter a problem during your closing process. The following entries describe some frequently encountered issues, and provide proven solutions for dealing with them. 1. My invoice was on hold, but it still posted. All holds prevent invoices from being paid, but not all holds prevent invoices from posting. The posting option can be changed on most holds (with the exception of the system holds). To change the posting options of a hold, use the Define Invoice Approval form.
GL Batch: Transactions after running GL Post Account Description Debit Credit 1-200 Liability - Dist. #1 $40 1-200 Liability - Dist. #2 $60 1-500 Expense - Dist. #1 $40 2-500 Expense - Dist. #2 $60 1-199 Intercompany $60 Receivable Segment 1 2-299 Intercompany $60 Payable Segment 2
Character: /Navigate Setup Invoices Approvals GUI: Navigate Setup Invoices Approvals Unfortunately, once an invoice has been posted, there is no un-post option. You will have to create manual GL journal entries if you want to back out the posting.
Example: Description Invoice #ABC Distribution #1 Distribution #2
Amount $40 $60
GL_DATE 15-FEB-97 25-FEB-97
2. Someone deleted the AP data from the GL_INTERFACE table before we imported to the GL! Although there is no standard process to re-post your AP transactions, there are times when it is necessary to do so. Oracle Support does have some pre-defined scripts to help you with this situation. These scripts will go into the database and manually "un-post" your transactions. You can then re-run the AP transfer to GL process, and the transactions will be re-selected for posting, inserted into the GL_INTERFACE table, re-flagged as posted, and will be ready to import into the GL system. Should you run into a situation requiring re-posting, please contact Oracle support. They need to work with you to analyze your situation and determine what changes your system requires and which scripts will be needed. Although Oracle can provide help in fixing the transactions, it is up to you to determine WHICH transactions need to be adjusted. This process can be greatly simplified if you retain the AP Journal Entry Audit report generated from the AP Transfer to GL process. If you do not maintain the report, it will be difficult to identify the problem transactions.
Example #1: Query invoice on 26-FEB-97 The invoice GL_DATE will display 25-FEB-97
Example #2: Query invoice in April, when FEBRUARY is already closed. The invoice GL_DATE will display 01-APR-97
4. I am trying to run the Journal import process from the GL system, but no transactions are being imported. When running the Journal Import process from GL, you must select source = Payables, and select a GROUP_ID. If you do not select a GROUP_ID, the process will run, but no transactions will be imported. If you have more than one GROUP_ID to choose from, you may not know which one to select. Unfortunately, there is no report that you can run to get this ID. If needed, you can run the following select statement from sqlplus to identify the GROUP_ID associated with your AP Posting Batch. col batchname format a15; col trans_type format a15; select distinct reference1 batchname, GROUP_ID, reference26 trans_type from GL_INTERFACE where reference26 like 'AP%' group by group_iD,reference1, reference26 order by GROUP_ID, reference26;
3. My invoice displays a different date from the period in which it posted. The GL_DATE associated with an invoice distribution determines the posting period, not the GL-DATE associated with the invoice. The GL_DATE at the invoice level is used for display purposes only. If you query a posted invoice, the GL_DATE at the invoice level will default to the latest GL_DATE from your distributions, or the first day in the next open period. Do not worry that the distributions posted in one period and now the invoice shows a different date. The invoice GL_DATE is display only, purely intended to help make your input of distributions easier.
5. My trial balance is wrong. First, insure that you have posted all your invoices and payments. Remember that non-posted transactions do not show up on the trial balance report. This is the number one culprit for trial balance issues. If it is actually determined that the data listed in the report is incorrect, a script can be used to rebuild the trial balance report. The script will backup your current trial balance table, delete the existing data, and then use the data stored for your invoices
(AP_INVOICE_DISTRIBUTIONS) and payments (AP_INVOICE_PAYMENTS) to rebuild the data. Should you need to rebuild your trial balance, please call Oracle Support and request the rebuild script. This information is documented in Bug #375496.
Although Oracle development is working on an enhancement for a future release, there currently is no patch for this issue. If your report is too large and you need the zero amount transactions removed, you can contact Oracle Support and they will help you resolve this issue. They will help you update the AP_TRIAL_BALANCE table through sqlplus and enable the invoices and payments to net together and thus be removed from the report. However, this is only a temporary solution, because the next time you post, the same situation will occur.
6. I have paid invoices that continue to show up on the trial balance report! In order for an invoice to be removed from the trial balance report, it must have a corresponding payment… even if the invoice was for a total of zero dollars. Therefore, you must issue zero dollar payments for these invoices in order to mark them as paid, and thus remove them from the trial balance report.
7. My canceled invoices continue to show up on the trial balance report! This occurs if you are using Automatic Offsets. When the trial balance report is generated, it groups all the entries for a supplier, and sums them by INVOICE_ID. If an invoice is paid, summing the invoice and payment together should net to zero. If the amounts sum to zero, all transactions associated with the invoice are removed from the report. Hence, you only see suppliers where the sum of their payments do not equal the sum of their invoices, indicating that they have an outstanding liability, credit, or un-posted transaction. Because automatic offsets records a unique liability account for each distribution line, the trial balance sums transactions by INVOICE_ID and DISTRIBUTION_LINE_NUMBER. Under most circumstances, the trial balance looks the same, whether you are using automatic offsets or not. However, reversed distribution lines work differently. When canceling an invoice, each distribution that currently exists on the invoice must be reversed. A reversal entry is created for each distribution being reversed. The reversal line shares the same INVOICE_ID as the original distribution, but has its own unique DISTRIBUTION_LINE_NUMBER. When the trial balance report attempts to group and sum the transactions by INVOICE_ID and DISTRIBUTION_LINE_NUMBER, it does not net these items together and omit them from the trial balance report.
8. My GL liability account doesn’ agree with the t AP trial balance report. Where can I look for help? 1. Run the GL Account Analysis report for the liability account and for the date range in question. Look for transactions with a source other than Payables. This can quickly pinpoint any transactions incorrectly charged to the account. 2. Are there still transactions in the GL_INTERFACE table that need to be imported? Those transactions would be displayed in the trial balance report, but would not yet display in the GL accounts. 3. Have the transactions been posted within the GL? The GL account balance is not updated until the GL journals are posted. 4. Are you still in pilot testing? Perhaps you haven’ t converted your outstanding invoices yet but the GL shows an up-to-date liability total. In this case, you would need to account for the converted GL amounts when balancing.
III. CASH MANAGEMENT INTEGRATION
If you are running the 10SC product, you have the ability to use the Cash Management application and integrate it with your Accounts Payable system. Cash Management will help you reconcile your bank statements, create miscellaneous transactions, and manage your cash flow. When defining the Payables system, you can decide whether or not you want the cash management application to create accounting transactions when it processes the bank transactions. This option is called
"Allow Reconciliation Accounting", and it can be defined in the payables setup option. If you enable this option, Cash Management will create accounting transactions. If the option is not enabled, you can still use the Cash Management application, but it will not create accounting transactions. Char: /Navigate - Setup - System - Options GUI: Setup - Options - Payables Options
errors and miscellaneous payments. The payables system will then integrate all these transactions into the standard posting and closing process.
Closing Impact
Utilizing the Cash Management application will not alter the standard AP closing process, but will change the some accounting transactions. In the standard closing process, the invoice and payment transactions were discussed. If you are using autoreconciliation accounting, your closing reports will still look the same, but will contain an additional section that contains the reconciliation transactions. For Example: The AP transfer to GL process will include the reconciliation transactions, and the data will be displayed in a separate section on the AP Journal Entry Audit reports.
Accounting Impact
When using the standard Payables system, the cash account is credited when issuing a payment. This holds true for both accrual and cash based accounting. Example: Pay a $100 Invoice utilizing accrual accounting GL Journal created for payment: Account Description Debit 1-200 Invoice Liability $100 1-100 Cash Account
Credit $100
The Un-posted Invoice Sweep report will also display a separate section for the reconciliation transactions. This allows the un-posted transactions to be reported or swept to the next period.
When utilizing reconciliation accounting, a cash clearing account will be charged instead of the cash account. When the payment document is reconciled or cleared within the Cash Management application, additional transactions will be created and charged against the cash clearing account. Example: Pay a $100 Invoice utilizing accrual accounting. Then, clear the check in the Cash Management application. GL Journal created for payment: Account Description Debit 1-200 Invoice Liability $100 1-150 Cash Clearing GL Journal created for payment clearing: Account Description Debit 1-150 Cash Clearing $100 1-100 Cash Account
Conclusions
It is my desire that this paper has helped you understand the fundamental process of closing a period in AP. Breaking the process into the 5 main categories should help you understand the "state" of your system. If something appears incorrect in the posting or balancing process, I hope that you are now better equipped to troubleshoot the problem and determine what needs to be done to resolve the issue. In addition, if you encounter a problem that requires assistance, please remember to call Oracle Support. They may have seen the issue before and may already have a solution for the issue!
Credit $100
Credit $100
About the Author
Deidre Figueroa is a Technical Specialist with the Oracle Support financials group. She has 8 years of experience implementing financial applications, both nationally and internationally, including 1 1/2 years with Oracle Consulting. She has implemented the Oracle Payables system several times, and is currently a member of the Accounts Payable support team.
When the payments are cleared or reconciled, the transactions will be created and inserted into the Payables system. (AP_RECON_DISTRIBUTIONS table). During this time, other miscellaneous transactions can be created, such as bank charges,
