Headaches on ICFR and Better Tech

My phone rang the other day, and on the line was my friend the tech vendor. He was calling to tell me about new whiz-bang software his firm is developing to identify internal control issues — and within a few minutes, we stumbled into a dilemma about effective internal controls that needs attention. Hear me out.

I won’t name the software firm here, since I’m not in the business of endorsing specific compliance software vendors. In broad strokes, however, my friend’s technology would do this: monitor your whole ERP software system for segregation-of-duties violations, which would be flagged and escalated for resolution as those violations happen. Internal control teams would then be able to log and resolve SoD violations immediately.

For example, say an employee in the accounting department gets reassigned or promoted. Thanks to an SoD glitch in your ERP software system, the provisioning of user privileges is screwy and that employee now has power to create a new vendor, generate an invoice, and pay said invoice. That’s a fraud risk, and it can’t be allowed to endure. 

A typical audit today, however, would manually review a sample of all the company’s transactions to see whether any of them fit the profile of that SoD violation. When the audit team finds evidence of those violations, they tell the company to remediate the glitch or risk them declaring it a deficiency. 

My friend the vendor’s technology would turn that dynamic on its ear. By identifying all violations as they happen and allowing internal control teams to remediate immediately, a company could then present all that evidence to the audit team and say, essentially: “Here’s every single violation we had, and how we remediated them. Knock yourselves out.” 

There would be nothing to “audit” in the traditional sense, because the very act of auditing implies searching for problems amid a sample group of transactions. This technology leapfrogs all that by providing a record of every problem that happened across all transactions. Access reviews and SoD reviews would no longer be necessary; everything those reviews might find would already exist in one report.

My question: How do we fit such a nifty idea into the existing rules and practices for audits of internal control over financial reporting?

Standards for Auditing and Evidence

The appeal of technology like this to CFOs and Sarbanes-Oxley compliance teams is clear. You get more accuracy in your analysis of SoD violations and a more automated approach to ICFR audits, which means lower audit fees from the external auditor. Then the audit committee rejoices and everyone is happy, right? 

Well, maybe. I’m just not sure whether current auditing standards from the Public Company Accounting Oversight Board can accommodate such a conceptual leap in assurance over ICFR. 

That is, could the auditors really rely on a company-generated report of all SoD violations? Would such evidence pass muster with PCAOB audit inspectors, the Securities and Exchange Commission, and investors? Conversely, could an audit firm decline to accept that evidence, and insist on re-performing all those reviews itself? In that case, what’s the point of automated controls monitoring, if the audit firm can just ignore the report and drive up your audit fees with manual testing anyway? 

In theory, PCAOB audit standards do allow an audit firm to rely on evidence from the client. The relevant standard, AS 1105, says this: 

When using information produced by the company as audit evidence, the auditor should evaluate whether the information is sufficient and appropriate for purposes of the audit by performing procedures to: test the accuracy and completeness of the information, or test the controls over the accuracy and completeness of that information; and evaluate whether the information is sufficiently precise and detailed for purposes of the audit.

Well, how does all that work in the scenario I outlined above? My friend the vendor’s technology would provide a report of every single SoD violation and how it had been remediated. That sounds like it meets all the criteria for sufficiency, completeness, precision, and accuracy to me. 

Or if that’s not the case, then exactly what procedures is the audit team supposed to apply to evaluate that evidence? Should they review the software code itself? Test the access controls of the vendor that developed the code? Do something else?

Even better: What if the audit firm uses its own software to analyze SoD violations, and gets different results? Whose software are we supposed to take as the superior tool with better results? Who has the expertise to make that judgment? 

Wanted: Better Standards on Technology

You can see the real issue here: that we have too many questions about how to use advanced technology in audits, and not enough answers. 

Right now the PCAOB is still researching the uses of technology in audits, and whether a new auditing standard might be necessary. Last year the agency published a project update that said this:

The results of our activities indicate that PCAOB auditing standards are not precluding or detracting from firms’ ability to use technology-based tools in ways that could enhance audit quality… But we have heard — and we acknowledge — that our current standards do not explicitly encourage the use of such tools, indicate when their use might be appropriate, or highlight related risks or pitfalls associated with their use.

No kidding. The questions I raised are just one slice of the whole issue. There are many, many more. 

Moreover, even if the PCAOB did issue an authoritative new auditing standard today, that’s still only half the battle. We still need similar guidance for corporate managements who want to build strong, automated ICFR systems but aren’t sure what they can do that will survive audit and regulatory scrutiny — and without that certainty, companies will be more hesitant to invest in next-generation technology. 

Just last week, for example, we saw a report exploring companies’ challenges with ICFR. One complaint companies had was that their audit firms demand extensive documentation of ICFR solely to keep PCAOB audit inspectors off their behinds, rather than because of legitimate concerns about internal control. Companies, however, don’t have any ICFR guidance of their own that they could cite to tell overly demanding auditors to buzz off.

That was all true long before my friend the vendor showed up, and he’s not the only one racing to deliver such whiz-bang ICFR solutions. Right now the technology infrastructure exists for stronger, more automated monitoring and remediation of internal controls — but the regulatory infrastructure to take full advantage of that is lagging behind. 

Food for thought as we all gear up for audit season. If I’m missing something or you have other thoughts, drop me a line any time at mkelly@radicalcompliance.com.

Leave a Comment

You must be logged in to post a comment.