1. Ensure that all Inventory, WIP and Pending activity for the current date has been completed and that no other transactions affecting these subledgers will be posted until after the reconciliation procedure has been completed and/or the date has been changed.
2. Record the last inventory transaction number used in the Inventory Activity file (File 91). This number can be used to verify the validity of the cuttoff on the WIP valuation and transaction reports which are used to reconcile WIP activity. Note: The current version of the Inventory, WIP, and Pending valuation reports automatically record the last inventory transaction number used at the time the reports are run and they will print an error message if the number changes during processing.
3. Produce a valid ending WIP Subledger report. This can be accomplished by running the Shop Order WIP Value by Component Report (FV076R13). This report runs through the open shop orders in the system and lists the quantities and costs from all open shop order lines which have pulled quantities. The report uses the quantities and costs stored in each shop order line to determine the WIP subledger total. The WIP quantity and cost from the Inventory Master file are also listed on the report for comparative purposes. Normally, the Shop Order and Inventory Master quantities should be exactly the same. The actual WIP value and the Inventory Based WIP value listed on the report may not agree because of changes to average cost which are made to the inventory subledger while items exist in WIP. The Shop Order Line based total must be used when balancing the WIP subledger. Non stock items will not be included in the report total (these items are not included in the Inventory, WIP or Pending subledger totals). Note: The ending WIP subledger report is a point in time report (a “snapshot” of the WIP quantities and costs at a particular point in time). The ending subledger report must include all activity through the end of the day being balanced and no activity after that date. A valid report can only be produced if it is run at the proper time. This is normally accomplished by running the report after hours or as part of the nightime process. The report can be processed automatically by the system at night and the system date can be changed immediately before or after running the report to ensure that the next days transactions will be posted using the proper date. This produces a report with a valid cutoff.
4. Verify that the subledger was in balance at the end of the prior day. The only way to prove that the beginning balance being used during this procedure is valid is to have already balanced the subledger for the prior days activity. This proves that the subledger beginning balance has a valid cutoff (that it includes all activity thru the end of the prior days processing and no activity from the current days processing). If the prior days activity is not in balance, then you must either balance it first (discover and resolve the cause), or balance the activity for the entire period since the last time that the subledger was proven to be in balance.
5. Run the WIP Activity by Transaction Type report (FV091R07) for the date range being reconciled. This report totals the inventory transactions that affect the WIP sub-ledger during the selected date range and it provides the number you will need in order to prove the activity in the sub-ledger. The report automatically includes all transactions that affect the WIP sub-ledger and that should be included when proving the activity in the sub-ledger. A list describing all transaction types which affect the Inventory, WIP and Pending sub-ledgers is presented in the Reference Information section of this document.
6. Prepare a reconciliation worksheet using the information listed on the reports.
WIP Subledger - Daily Reconciliation Worksheet
WIP Sub-ledger Balance - beginning (1) 50000.00
WIP Activity by Transaction Type (2) -5000.00
Calculated Subledger Balance (3) 45000.00
WIP Subledger Balance – ending (4) 45000.00
(1) This should be a verified beginning balance and should be printed in detail and preferably to file so that the file can be searched if any problems are discovered during the balancing procedure.
(3) Add the net total from the above transactions to the beginning subledger balance and compare the result to the ending subledger balance. The totals should match. If the totals are in agreement, file the reports (or archive the files and store the daily reconciliation worksheet for future use). If the totals do not match, the cause of the variance should be resolved.
If the subledger cannot be reconciled, the reasons for the variance may include the following.
• Items have been changed from Stocking to Non stocking during the period (ie Trk flag in file 70 is changed from Y to N) or vice versa. Non stock items are not included on the inventory valuation and changing the value in this field can cause undocumented (unrecorded) changes to the inventory valuation. To confirm that this value has been changed you may compare the beginning and ending valuation reports and the reports listing inventory activity to determine if there is a change to the valuation not backed up by activity detail, or you can use the inventory activity detail records for each item to see if the value in the field has changed (the most current versions of programs affecting inventory now write the value in the Trk field to the inventory activity records.
• Transactions have been improperly processed. Use of obsolete programs (ie Materials Conversion), improper versions of some programs, and disregard for system design and procedures may cause undocumented or incorrect updates to the inventory subledger.
• Off line editors have been used to change item quantities and or costs in the Inventory Master file. Off line editors do not write to the inventory activity file and improper use of the programs can result in undocmented changes to the inventory subledger.
• Data loss. Loss of inventory master or inventory activity records can cause the inventory subledger to go out of balance. This occurrence should be extremely rare on a stable system. Recovering from data loss is a complicated procedure which is handled on a case by case basis and is not discussed in this document.