In the early 1900s, audits were performed by testing every transaction during the audit period. But the size of companies rapidly increased due to advancements in technology, transportation, and corporate structures. This created the need for sampling, as testing every transaction was no longer feasible – audits were still being done by pencil and paper.
Until today, sampling has been the primary basis for obtaining audit evidence sufficient enough to opine on the financial statements. But with another rapid increase in technological capabilities, it’s time to rethink how the audit is performed. Dare I say go back to our roots?
The number of transactions processed by a company is immense, the capability to commit fraud is easier, and the likelihood of human error due to complacency on system reliance is at an all-time high. These are all reasons why traditional sampling is becoming insufficient in a significant number of audits.
Now a test of details over every transaction today is not feasible, at least not yet. However, an analytic review of every transaction absolutely is with the assistance of technology. An analytic review is not surfacing errors, but indicators of risk.
A big pushback from auditors (including myself) when testing 100% of transactions is the fear that you’ll drown in exceptions. Once you see something, you can’t unsee it. Once you know an error exists, you have to address it. We all know that our financial statement audits are hiding errors, and we’re protected behind the mask of sampling. We’re too afraid to take that mask off.
How can we review every transaction but limit our hours and liability? That’s the question I asked myself. That’s what I was researching when I stumbled upon Audit Data Analytics (ADA).
I first read this concept in SAS 142 while preparing a presentation on audit documentation for the Nebraska Society of CPAs. The discussion was tucked away in an exhibit at the end of the standard; I questioned if it was an accident. After reading it a couple of times, because comprehension doesn’t always come easy for me, it quickly became my favorite piece of audit standards. I started feeling like a boomer, name-dropping audit standards, when passionately sharing what I found.
In 2024, I created presentations around this new (to me) world of ADA and how we could apply it to employee benefit plan (EBP) audits. I manually applied the discipline to real-world data in Excel to create case studies. At that time, my peers thought it was neat but left it at that. They had methodology and sampling standards to adhere to, and adopting a new way of auditing felt like an uphill battle with all the other changes they had to deal with.
Fast forward two years, and I’m tired of this sitting in my head. Tired of knowing there is a better way to audit, a more efficient way to audit, a more effective way to audit. Technology today allows us to perform a 100% review of transactions again, like the early 1900s, but on a much larger scale. We don’t have to worry about trying to unsee exceptions because we are seeing risks – not a pass/fail test.
I foresee a future where audit standards assume the analytical review of all transactions and require an explanation as to why it wasn’t performed. Similar to how auditors are required to document why revenue recognition is not a fraud risk.
AuditMiner is creating this opportunity for EBP auditors. We focused on ingesting and understanding data for the last five years, and it was no easy feat. But now that we have the data, we can give auditors the ability to perform a true risk-based audit without sinking fees into testing all exceptions. It’s called AuditMiner Beta, and it’s coming soon. If you’re thinking, “Okay, but what does this actually look like in an audit?” That’s the conversation we dig into in our webinar, Reduced Sampling Under SAS 142: Building a Defensible Audit Trail.
We walk through how audit data analytics can help you look at the full population, identify where the risk actually is, and focus your sampling there. We also get into the part I know auditors are going to ask about: how do you document all of this so you can defend your approach in review?
