Causes of reconciliation issues

If both the GL and AMT have the same work order or billing, but the value of that record is different between the two systems, the reason for the variance is typically a result of the interface between the ERP and AMT. That is, the specific scenario of that transaction has not been handled or interpreted properly by the interface before sending the transaction to AMT. Typical errors which indicate the work order or billing interface from the ERP to AMT may not be handling correctly are:

• Special codes (for example warranty splits, flat rates) may be applied to the work order in the ERP but the work order settlement records interfaced to AMT have not had these adjustments applied.
• The work order or billing may have been backed out (reversed) in the ERP system but this change has not been interfaced to AMT.
• The work order settlement or some of its segments may be flagged as a contract cost in AMT (Cost Bearer = CC) but this may not be the case in the work order in the ERP.
• The work order settlement may be showing as closed or invoiced in AMT but in the ERP the work order is still open or vice-versa. This is caused by the Closed Period in the work order interface file not being set ( it does not contain a value).
• The serial number linked to the work order settlement in AMT may be different to the serial number linked to the work order in the ERP. In this case, the values of the work orders may actually balance between AMT and the GL, but it is the serial number resulting in the imbalance.

It is possible that the GL contains cost records but AMT does not. This could be a result of: 

• Miscellaneous general journals posted to the contract account in the GL rather than being processed as work orders or billings.
  • This issue is addressed by stopping the practice of using general journals and replacing them with work orders and billings.
• Users of the ERP posting transactions to the contract’s GL account which should have been allocated elsewhere (such as journals mistakenly debited or credited to the wrong account code).
  • Such transactions have to be identified individually and reprocessed so that they are reversed in AMT (that is, so that AMT no longer shows the incorrect amount).

    It may not be possible to delete the transaction entirely out of AMT but it should be possible to change its value through reprocessing in the ERP and interfacing the result back to AMT.

  • Users of the ERP have to be educated so this practice does not continue.
• The interface failing to recognise work order or billings transactions in the ERP which should be interfaced to AMT.
  • You should investigate the nature of the work order or billing record in the ERP system in order to identify why it was not sent to AMT through the normal work order or billing import interface.

It is possible that AMT contains work order or billings records but the GL does not. This could be a result of: 

• Users manually creating work order settlements internally within AMT that do not have a corresponding record in the ERP.
  • Users have the ability to create work order settlements in AMT using Work order Settlement Manager or using Equipment Status, but costs can only be entered onto these internal AMT work orders using Work Order Settlement Manager.
  • This Work Order Settlement Manager function should only be available to those who will use it responsibly.
• A timing difference between when you close or invoice a billing or work order in the ERP, to when it is actually transferred to the proper account in the ERP. Batch processes in the ERP can sometimes delay posting to certain accounts.
  • Look for these records in the WIP – Not Currently Processed section of the AMT to GL Reconciliation report.
  • The GL interface and reconciliation should only be performed once all such processes are completed.
• A problem with the GL interface file where some records which actually exist in the contract account in the GL are not being picked up and sent to AMT for some unknown reason.