Mitigating Factors in Audit Exceptions 1693

  • In our site, we had an audit exception noted regarding the possibility of the processing of a duplicate invoice under any given vendor.
    We implemented the logic to detect when a Vendor invoice number had already been entered for that specific vendor, and blocked payment.
    However, we only provided the logic check under application forms or data entry screenst hat allow direct entry of vendor invoices, those NOT tied to a Purchase Order. Unfortunately, this has led to another audit exception.
    Our contention in responding to this exception is that when a Purchase Order enforces ‘three-way-matching’, there is no risk of duplicate invoice processing or vendor overpayment, because payment is limited to the authorized Purchase Order lines, and what has been received against them. according to the terms and defined tolerances of the Purchase Order.

    1. Is there anything we are missing?
    2. Are there any other ‘mitigating factors’ I can mention or enforce to support our contention?
    3. What other objections or reactions could I expect to our position on ‘three-way-matching’ as an adequate control?
      Thanks in advance,

  • 3 way matchings should help to ensure that all invoices match a valid purchase order, and that payables are not recognised until the goods have been received.
    Your control to ensure that all purchase invoices cannot be posted twice is also useful as it means that the same invoice should not be posted twice (I assume that the sytem generated number is noted on the paper invoice after it is received for traceability). It would only cover the risk of overpayment if a purchase order was created for every vendor purchase however.
    Another useful control which is standard for audit purposes in UK and Ireland ( for some reason there is no requirement elsewhere in Europe), is to perform a creditors reconciliation at regular intervals. This may be quite arduous however, as it involves obtaining creditors statements and reconciling them to the balances on your accounts payable ledger, cash in transit and goods received but not invoiced. Where it can be confirmed that the goods have been received for reconciling differences, the balances may be accrued for. Where there is an invoice on the statement, but no goods have been received, you do not adjust the amount on your account as the balance is not due for recognition yet. This helps to ensure that payables are not under or over stated in the accounts and therefore, not under or over paid.
    Hope this helps?

  • We implemented the logic to detect when a Vendor invoice number had already been entered for that specific vendor, and blocked payment
    Is this a notification, or a hard-coded restriction?
    We found out that some of our vendors re-use invoice numbers after they’ve used all of them… ie, they use all from 100000 to 999999, and then start again on 100000. I came across this issue a few years ago when I was working in the accounting department.
    ‘Fortunately’, our system was only set up with notifications, so that we could process this invoice the proper way. All it took was some extra investigation as to why this invoice number was used twice.

  • Generally, I would have regarded 3-way match as a sufficiently robust key control to cover the risk of processing a duplicate invoice. An additional control would potentially be supplier statement reconciliations but many companies do not do this.
    Your only potential risk not covered - which may be getting tenuous anyway - would be that you process a duplicate invoice once under the PO process and once under the non-PO process. But presumably there is a process under which non-PO invoices are approved and considers whether not using the 3-way match is appropriate?

  • Dear William,
    there are some interesting issues that might not be covered.
    The answers depend on whether the various accounting and finance modules that you are using/ testing are integrated or not. I have worked on sites where the Purchasing module, Materials/ Inventory module, and the A/P module are all standalone, interfaced by software to talk to each other.
    The answers also depend on whether you operate with a shared service centre or local processing at each business unit. I have seen cases where the shared service centre is a long way distant, resulting in invoices spending up to 5 days in the mail between registration and processing steps.

    1. Is there anything we are missing?
      Answer: It depends on how you configured the logic. In some practical examples I have seen, a space in an invoice number will be interpreted as a unique invoice number by the application. Example 1234 B and 1234B will be treated as two separate invoices and the duplication will not be detected in this case. The best way to catch the duplications is to set the application logic to check for duplication of vendor name, amount and invoice. Any apparent duplications should either result in an on screen warning, or an entry on a daily exception report.
      Denis’ response to your query mentions the risk where PO invoices are paid as Non PO, in which case there could still arise a duplication, especially if the modules stand alone.
      I have seen cases where warehouse receiving departments have been deficient or tardy in entering receiving information. This could lead to quantities received as being entered as 1, when in fact only part of the Purchase Order amount has been received. A three way match would not identify this weakness. Having a duplicate invoice control over PO Invoices would be an additional assurance that ostensibly the same deliveries are not invoiced twice.
      I would also have a look at the urgent/ manual check payment processes. Some payments may slip through this way.
    2. Are there any other ‘mitigating factors’ I can mention or enforce to support our contention?
      Answer: Without knowing the full details of your operating environment, alluded to in the first two paragraphs of my answer, I would not be able to give a complete answer.
      However, there is software around that will allow you to review vendor files and invoice histories, as a detective control. This type of software is used by some specialist service providers eg Protiviti Spend Risk software, to do periodic reviews on numerous parameters to detect anything unusual.
      Vendor statement reconciliations are also useful as mentioned by others.
      Creditor circularization is another good control.
      Ensuring that only original invoices are processed and that no copies are ever processed.
    3. What other objections or reactions could I expect to our position on ‘three-way-matching’ as an adequate control?
      I think the answers before will give you some idea. For your information, I have been through clean up exercises in companies where the three way match control was being used as a single control point, and it can create an enormous mess, resulting in duplicate payments and major misstatements in month end accruals.
      Good luck,

Log in to reply