Home > News&Advocacy > Professional accountants - the future

Understanding Robotic Process Automation in Audits

Understanding Robotic Process Automation in Audits


Robotic process automation (RPA) is a class of businesses processes that uses software, that utilizes variants of artificial intelligence to perform tasks that are either repetitive or learnable by a software algorithm. Historically, RPA started as a form of “data scraping,” which obtained data from a fixed-format output (such as screens or paper printouts). Robotic software evolved to be both an enhanced graphic visualization software as well as an underlying data gathering technique. With enhanced data gathering came software whose logic was primarily addressing repetitive activity such as tracing, matching, and vouching. Adding a layer of software-learned intelligence, exceptions, anomalies, and implicit-rule based analysis followed.

Today, RPA has application in banking, mortgage application process, sales, generic big-data applications such as optical character recognition (OCR) and data extraction, and—increasingly—audits. A 2017 PricewaterhouseCoopers article estimated that 45% of worldwide workforce task can be automated, and in November 2019, Deloitte disclosed that it utilizes RPA extensively in its financial audit process . The rapid adoption response from 2017 to 2019 indicates not only a near-perfect match between the technology and the need; it also indicates that the return-on-investment argument has been substantially demonstrated.

Understanding Robotic Process Automation in Audits


The application of RPA to an audit is—like many smart software applications—a layered framework that begins with data gathering (a simple, repetitive task), and culminates with visualized deliverables (a changing, intelligent task):

· Data gathering underlies the RPA process. This is done by various techniques, such as OCR, extracting data from human-readable reports, importing data from data sources, or connecting to an existing database using open database connectivity (ODBC) methods. Although all these functions require human set-up and initial analysis, once the data gathering is set up, the learning of the robot software is generic, specific, and—most telling—it is repetitive.

· Rule-based activity is the matching, vouching, and tracing that can occur once data has been gathered. For example, once a set of invoices and delivery reports are obtained, either by OCR or some form of extraction from ledgers, rule-based software can create a matching set between the two, eliminating the need for a human to do so. The software can also be programmed to attempt to match multiple deliveries to a single invoice (or vice versa), by either obtaining details such as delivery dates from the underlying paper documents, or by assuming a certain date proximity. Of course, for entities that utilize extensible markup language (XML) or its business derivative format extensible business reporting language (XBRL), OCR is less relevant, and direct data extraction will result in fewer errors in the underlying process and the rule-based application that follows.

· Sample selection for auditor action is one of the top-level actionable phases that RPA can deliver: either by creating an explicit rule, or having exceptions to the vouching, tracing, or matching, a set of risk-ranked exceptions can be delivered for human interaction. Vouching, tracing, and matching are simple repetitive RPA tasks, which either result in a perfect result, or imperfect results with exceptions. These exceptions can be acted upon by a human in a manual business process or as otherwise applicable—for example, by an auditor. This phase is suitable for audits by creating implicit rules that can also be an audit procedure because it can ascertain what the expected behavior of the data set is, and then seek exceptions to it. Depending on their nature, exceptions can either represent a breakdown in internal controls or a basis for the substantive testing of specific transactions. For example, take the implicit rule that “adjusting journal entries’ time stamp to 20 days after the period they purport to adjust”; this exception would make sense. The month-end closing generally happens somewhere around three weeks after the end of the month. However, if adjusting journal entries appear significantly later than 20 days, then the auditor may be skeptical about these exceptions to the implicit rule, and select these exceptions for additional analysis by the audit team.

· Visual delivery for decisionmakers originated in the data visualizations for decisionmakers on static historical, unmodified data, or data that is rapidly changing while being analyzed. Overlayed into RPA, the visualized deliverable can provide, for example, risk-based visualization to assist in the audit process. For example, colors, shapes, and volume can assist the audit team in ascertaining areas of increased risk of misstatement, as well as areas for which such a risk has been addressed by audit procedures. The RPA algorithm can learn the issues in for example, auditing fixed assets, which are different than those of auditing revenues. Once the algorithm knows how to tell which implied rules and exceptions are more susceptible to risk, it can provide a smarter, even more focused deliverable for the auditor to review. For example, revenue overstatement and early recognition are a constant risk for most financial audits. If 10 implicit rules are derived and have a constant class of rules, the RPA may be able to rank them based on past audit responses. If an implicit rule regarding exceptions in the late booking of revenues by adjusting journal entries is consistently attended to by the human auditor, the RPA will learn to maximize its effort in this area—as compared to rounding errors that appear due to large invoice amounts, which auditors will generally be reluctant to be skeptical about.