This topic describes how to reconcile the PO Liability Account. This discussion contains instructions for users of General Ledger and Accounts Payable, and Materials Management. If your site does not use General Ledger, and instead, exports transactions to an external general ledger system, see Reconciling the PO Liability Accounts - External GL Systems
PO liability means that there are POs that have been received but not matched with invoices.
The PO LIability Report pulls all materials transactions and all AP transactions up to the run period of the report by PO Number. Materials transactions have a credit to PO Liability and AP transactions have a debit to PO Liability. If the amounts do not net to zero, the report captures the PO data.
For each month in the fiscal year, you should reconcile the PO Liability Account balance with the PO Liability Report amount. If the two values are not equal, you need to find the source of any discrepancy. The process reconciling the PO Liability Account involves comparing data using Supply Chain tools.
Additionally, the PO Liability Maintenance tool is available to assist in PO liability reconciliation. This tool avoids the situation in which a user has to manually create a zero dollar invoice to run a debit against the PO vendor GL account, and a credit against the AP invoice GL account to fix the PO liability issue. With non-file and non-stock items, any receipts can then be reversed. However, this approach is particularly problematic when the item is a stock-item. The item receipt cannot be reversed because that would impact the on-hand quantity.
The sections below describe the process and the tool.
For any period and year, the balance in the PO Liability Account is the dollar amount for purchase orders that are not yet matched with invoices:
PO Liability Account balance = the amount owed for purchase orders the total amount invoiced.
Transactions for materials (MM) and accounts payable (AP) are generated by the system as part of receiving and invoice matching. When items from a purchase order are delivered to a medical center, warehouse staff use the system to create receipts. A receipt record contains the dollar amount of the delivery. When invoices arrive, the invoices are matched to the receipts and approved for payment.
A receipt generates an MM transaction. The organization's inventory account is debited, and the PO Liability account is credited with the receipt amount. Matching the invoice generates an AP transaction that debits PO Liability and credits AP Liability. For example, transactions for a $100.00 receipt and matching invoice would look like this:
|
|
Both MM transactions for receipts and AP transactions for invoices are extracted (written to) the GL Transaction Table. (You can write reports on the table's contents using the GL Transactions MM and AP report object.) The PO Liability Report, available from the Reports menu, pulls data from the GL Transactions Table.
When you request a PO Liability Report, the system looks for transactions in the GL Transactions Table. Any GL transactions without matching AP transactions that is, any receipt amount that is not relieved by matching invoices is a candidate for the PO Liability Report. The report shows transaction amounts and the total amount for the period and year that you specify. Figure 1 shows how the system elements work together.
General Ledger automatically imports data from the GL Transactions Table. Each import becomes a journal voucher in General Ledger. General Ledger posts the AP transactions to the AP source journal, and MM transactions to the MM source journal. AP transactions posted by the system have journal voucher numbers in the form "APXXXXX." MM transactions posted by the system have journal voucher numbers in the form "MMXXXX." Debits and credits to the PO Liability Account come from the system's automatic posting of AP and GL transactions. Here is a key point to remember:
When you use General Ledger to display the balance in the PO Liability Account, you are looking at the same data that exists in the GL Transaction Table, and the same data that is the source for the PO Liability Report.
How can a PO Liability Account be out of balance?
Since the data for the PO Liability Account comes from the same source as data for the Report, how can the balance displayed for the account be different from the total on the PO Liability Report?
The account balance and the Report total can be different if:
If a difference exists, and the account total is higher,
- Verify that the accounts have no ongoing activity. If staff are continuing
to match invoices, the totals for the period can shift.
- Verify that the PO Liability Report
includes all transactions for receipts and invoices look for journal
vouchers posted manually to the PO Liability Account.
If a difference exists, and the Report total is higher,
- Verify that the accounts have no ongoing activity.
- Make sure that all relevant transactions in the GL Transaction Table were
posted.
This utility uses the standard ERP import process to bring in amounts for PO liability and tax liability (if relevant) for a specified organization and purchase order. The utility creates an AP transaction with the type "PO Liability and Tax Liability Write Off."
The amount in the transaction is: PO liability amount + tax liability amount.
Attachments to the AP transaction are the GL transactions for PO Liability, Tax Liability, and Write-Off GL accounts.
Inter-org GL accounts will also exist when the organization for the write-off account is different from the organization for the PO.
Security: The role object "POLiabImport" controls the user's ability to work with this new tool. The default setting is None.
Make sure that the role object "POLiabImport" in your user role has the setting All or Create.
Step 1: Create the .csv file for the importRow |
Column |
Contains |
What is this? |
1 | A | POLiab | The name of the import type. ERP recognizes this name as a PO Liability and Tax Liability Write-Off file. |
1 | B | Customer ID | The name of your ERP site. If you do not know this this value, mouse over the Current Settings header above your current settings, or call the Help Desk. |
1 | C | Date | Use the format MM/DD/YYYY |
2 | A | Org | This is the column header for the organization field. |
2 | B | PONo | The column header for the purchase order number. |
2 | C | POLiabAmt | The column header for the PO liability amount from the PO. |
2 | D | TaxLiabAmt | The column header for the tax liability amount. |
2 | E | GLAcctWriteOff | The column header for the write-off account from your chart of accounts. |
3 and succeeding | A-E | data | Your data for each column: organization, PO number, PO liability amount, tax liability amount, GL write-off account. |
Last row | Last column | EOF | This string must be the last element in the file. |
Figure 2 is an example of a spreadsheet for the import.
The upload file must be a .csv file.
This step uses the standard ERP upload process.
A list of imports appears, if any have been created (Figure 3). Otherwise, No Data appears.
The following fields provide useful status data:
Import Status - The successful or unsuccessful status of the upload.
Complete: The .csv file uploaded and imported its data successfully.
Errors: The .csv file could not be read or validated.
Ready for Processing: If you have used a two-stage upload, the file is ready for the second (update) step.
Processed - The number of data records processed out of the total uploaded. This number indicates how many of the import file records successfully performed their respective actions on General Ledger account records.
n of X: X is the number of data records uploaded and n is the number of records processed.
For a one-stage upload, this field indicates whether the system could make changes to existing GL account information using the imported file's records, and, if so, how many records processed successfully. 0 of X means that the system was not able to process any of the imported file's records. For a two-stage upload, 0 of X is normal.
Additional Notes
The PO Liability Report Summary has two versions: one version produces output in Adobe Acrobat format; the other version outputs data to an Excel spreadsheet. You can select either, according to your preference.
Figure 7 is a sample PO Liability Report Summary using Adobe output. The first page and the last page of the report are in the figure. The red arrow points to the location of the amount on the last page of the report to use in the reconciliation.
Calculate the difference between the PO Liability Report
Balance and the PO Liability Account Ending Balance
for the period.
- If the difference is
zero, or below a threshold set for your organization, no further reconciliation
is needed.
- Otherwise, proceed to Step 4 (see
the Steps above) to look for discrepancies.
If your account balance is higher than the report balance, and all invoice matching activity for the period is frozen, manual journal vouchers may have been posted to the PO Liability Account. Use the General Ledger Detail by Account report to get a list of credits and debits to the PO Liability Account for the year and period of interest.
The report shows journal vouchers posted to the account, the date, the source journal, and the credit or debit amount. This format makes it easy to spot manually posted journal vouchers (Figure 6 doesn't have any), particularly if your site has a source journal used only for manual vouchers. The postings In Figure 6 that the were made only by Supply Chain.
To view fields for the "GL Transactions MM and AP"
Report Object, from the GL Contents, select Reports > Browse Report
Objects.
- You can use the Position To field to find the Report Object.
- Click View Fields.
If you need instructions for writing a custom report using Report Objects, see
Creating Custom Reports.
Copyright © 2023 by Premier Inc. All rights reserved.