Audit Finding Attribute: Condition

This is the fourth in a series of articles on data analytics and internal audit. This article looks at the audit finding statement: Condition. The focus will be on the use of data analytics and how the condition supports the development of the recommendation.

In simple terms, the condition is “what is.” Typically, the analytics are testing for the existence of something, and the results are the condition. For example, have we paid the same invoice twice? If there are results in the duplicate invoice file, then (according to the duplicate criteria) the condition is “invoices have been paid twice.” Sometimes, the analytic is simple: Identify invoice for more than $25K that do not reference a purchase order. But they can be more complicated: have any users performed incompatible duties, did we invoice for prices below the master sales price minus discounts, do we have anomalies in the pay amounts.

This result, condition, is highly dependent on the accuracy of the analytics. As mentioned in the post on criteria, using the correct source data and applying the correct logic is paramount to arriving at a valid conclusion. The condition also includes the notion of properly interpreting the results and (a question often asked) the integrity of the data. I have clients tell me that, “the data does not have integrity.” When the audit team leader tells me that, I usually respond with, “well, you have your first finding.”  When the client tells me that, I usually shake my head and sigh softly.

The availability of high-quality, authoritative information to decision makers supports the achievement of corporate goals and objectives. As recognition of this importance, that information and data must be managed as a strategic asset to support operations, service delivery, analysis, and management decision-making. According the IIA Standards (2130.A1), internal audit must “evaluate the adequacy and effectiveness of controls … regarding the reliability and integrity of financial and operational information…” If the data does not have sufficient integrity to allow internal audit to make assessments on the adequacy and effectiveness of the controls, how can it support management decision-making.

Another important aspect is the degree of integrity. If audit is relying solely on the results of the analytics, then the data would need to have a higher level of integrity than it the analytics were informing audit and additional work performed to verify the results. This is particularly true when using analytics to support a fraud investigation. The data is only a pointer of where to look; and the results must still be validated.

In support an HR audit, I used the corporate HR system as the source. The manager of the area stated that the data did not have sufficient integrity to be used. She stated that there was a 62 percent error rate in the HR data. When question further about what this meant, she stated that 62 percent of employee records contained at least one error in their information i.e., missing, or inaccurate data. At first this seemed inconceivable until I realized that the definition of ‘error’ included hundreds of fields for each employee. Many employees did not update their address after a move, their dependents after a birth, new phones numbers, etc. So, while the employee record has an error, it was not a significant error, and even more importantly, not a field used by the audit. An examination of the audit objective, the criteria and the required analytics identified 10-12 required fields, such as start date, birth date, job classification, salary rate. The manager assured us that they reviewed this data regularly and it had the necessary integrity.

Takeaway: the more you rely on the data to identify control weaknesses and risk, the higher the integrity required. But sometimes the lack of integrity is the evidence of the control weakness. In support of a P-Card audit at a policing organization, I used the bank credit card transactions as the source and was expecting a high-level of integrity. When the results showed a large transaction at a golf and country club, and purchases at a liquor store and a strip joint. I was certain we had something. My interpretation of the data was that a golf membership and alcohol was purchased with the corporate card. However, the interpretation was incorrect in two cases. The charge to the golf and country club was for repairs to a golf green and a search and rescue helicopter had landed to pickup a golfer who had been serious injured. The first liquor purchase was made by the person in charge of teaching the breathalyzer course (he had half the class drink so other half could administer the test). The second liquor purchase was by an undercover cop. Seemed OK until I thought about it further: why would an undercover cop ‘on duty’ be using the police credit card to make a purchased (busted).

In a private sector organization, I found many purchases of baseball, hockey, and basketball tickets. This was something not allowed at other organizations where I had worked. However, sales reps can take clients out to sporting events; and it was not a problem; until we noticed that two employees doing this were not sales reps.

I have also had cases where the merchant category code (MCC) was incorrect. So, an expense to a merchant with an MCC of “5183 – Bars, Cocktail Lounges, Discotheques, etc.” was really made at a stationary shop. Interpretation and validation of results is an important aspect of analytics. At the same time, I am often testing controls. If, in the previous example, the system was supposed to block purchases made at bars, then the existence of the previous expenses is an indication that the control is not working.

In an AP audit of an SAP system, I ran a variety of analytics to examine the reasonableness and completeness of critical date fields including the entry, invoice (document), and baseline dates. (Baseline is the latter of invoice received or goods received. The baseline date and payment terms determine the due date. You should not pay an invoice until you have both the goods and the invoice.)  I found instances where the baseline date was greater than the entry date and the invoice date was greater than the baseline date. These were obviously data entry errors; so, the data did not have integrity. However, it did show that the data entry controls were not effective. The system should prevent a user should from entering a baseline date that is in the future. The lack of data integrity can be evidence of a control failure.

The condition is highly dependent on the data, the criteria, the logic, the integrity, and the interpretation of results. This does not mean that you cannot rely on the results of data analytics, but it does mean that you must remain open and carefully validate all results. Linking your analytics to the risk and the mitigating controls will allow you to understand what the results are telling you. It is critically important to question the results and ask the question – does this make sense. In addition, you should ask yourself – what does this mean. In previous example, baseline date greater than the entry date means that we received the goods and invoice after the invoice was entered in system; invoice date greater than the baseline date means the invoice was created after it was received.

Dave Coderre

Leave a Reply

Your email address will not be published.