Audit Finding Attribute: Cause

This is the fifth in a series of articles on data analytics and internal audit. This article looks at the audit finding statement: Cause. The focus will be on the use of data analytics to assist you in determining the cause of what was observed (the condition) and to support the development of the recommendation.

In simple terms, the cause answers the ‘why.’  Why are controls failing to prevent and/or detect what is happening?  The cause could many things, but it often relates to an absence of controls, overriding of controls, or  a lack of separation of duties that bypass the controls.

It is not sufficient to only identify the transactions that fail the audit criteria, more work must be done to determine why.  Simply identifying the transactions that are in error does not produce a good audit result – one that provides management with recommendations that will address the risks by improving the controls.  Too often I have seen the following audits:

  • Objective: determine if “A” is happening
  • Criteria: we should not be doing “A”
  • Condition: we are doing “A”
  • Recommendation: don’t do “A”

In an accounts payable audit where we found the duplicates exist, it is not sufficient to simply tell management recover the overpayments and not to pay duplicate invoices. Given that we have found duplicates, the auditor should ask “why are there duplicates”?    Not just once, but repeatedly until they get to the root cause.  Often this can be done by examining the initial results file (e.g., duplicate invoices).  Once you have the initial results (e.g., transactions that failed the criteria), further analysis can identify relationships and patterns that can help to identify the root cause and help you to formulate recommendations are tied to the cause of the control weakness, not the symptom.

  • Why do we have duplicates?
  • The ERP test for duplicates is failing to identify the duplicate transactions.
  • Why is the ERP preventative/detective test failing?
  • Our analysis of duplicate transactions indicates that in 23 percent of the duplicates, the duplicates are being paid to the same vendor, but under different vendor numbers.
  • Further, in 37 percent of the duplicates, the invoice date is being allowed to default to the entry date.  The system won’t detect invoices as duplicates if the invoice date is not identical.
  • Why do the same vendors have multiple vendor numbers?
  • The analysis of the vendor master table to determine which clerks created vendors determined that all A/P clerks were creating vendors, and many were not doing a proper check to ensure that the vendor did not already exist.
  • Why is the invoice date defaulting to the entry date?
  • A/P clerks do not understand the importance of the invoice date.

After only three ‘why’ questions, we arrived at two of root causes of duplicates: poor controls over the creation of vendors in the vendor master table and incorrect entry of the invoice date.   Now the recommendation could be not only to ‘recover duplicate payments, but also to restrict create/modify/delete access to the vendor master table to a single, properly trained user and instruct users on the proper entry of the invoice date’.  Not only will the process recover the duplicate payments, but it will reduce the risk of invoices being paid twice in the future. 

In an A/P audit, we determined that invoices over $25K were being entered without referencing a purchase order.  The procurement process required that purchase orders be created for all purchases over $25K, however, the corresponding detective control in the financial system was turned off (no control).  In a payroll audit, we identified an entry level clerk being paid $62K.  A review of the pay rate field determined that the manager had manually entered a higher pay rate for the employee (management override of controls).  In an A/R audit, the salesperson was creating customers and recording phony sales to these customers to obtain bonuses.  This was discovered when we analyzed customer returns (lack of separation of duties).

If you start with the audit objective and then define the risks to the achievement of the objectives, you can easily link the mitigating controls for the risks and the analytics to test these controls.  When examining the analytic results, it is important to review the controls that were being tested, and ask yourself, “Why did the control fail?”  The analytics are the evidence that the control failed, but further analysis is required to identify the cause: no control, override, separation of duties, or something else.  Do settle with a recommendation that says, “Don’t do A”.

Leave a Reply

Your email address will not be published. Required fields are marked *