The Trials and Tribulations of Automated Application Controls
We presume modern tools output the correct data with little skepticism. But what happens when we fail to perform the right tests?
By Brian A. Vazzana, CPA, CITP, CISA | Digital Exclusive - 2017
As accountants and auditors, we live in a heyday of computerized transactions. Gone are the days of ledger books, green-bar paper, and handwritten T-accounts. Today’s general ledgers are brought to us by machines that allow us to receive customer orders, allocate inventory, ship, bill, record revenue, and transfer sales ledgers with the push of a few buttons.
But with great machine power comes great responsibility. Accountants and auditors are increasingly relying on machines, software systems, and applications to perform various calculations and process various transactions. We presume these modern tools will output the correct data with little testing or skepticism. But what happens when we fail to perform the right tests?
These are the trials and tribulations of automated application controls.
We assume that just because a system performs a calculation, that calculation must be an automated application control that assures errors won’t occur or would, at least, be detected and corrected. In truth, the processing of a transaction may just be that—a process, the way something is done and nothing more.
A control is an element of a process that has a specific purpose; in the context of financial statement generation, it prevents or detects a material misstatement from being recorded. Consider the following: Depreciation charges are calculated correctly by the fixed asset module within System X based on the cost, depreciable lives, and methods used. As currently written, System X isn’t necessarily doing anything more than calculating information based upon data input within it. There’s no element that halts System X from recording an invalid transaction (a preventative control) or logs and reports when an invalid depreciation expense or asset value has resulted from its calculations (a detective control). System X is just processing data.
Some may argue that the calculations alone are more than a process because they allow for a result to be consistently achieved. One plus one should always be two; so, a control must be present in this process. I would argue that if we consider a calculation to be more than a process, we must consider its rules; we must consider the elements of the calculation that create the control.
Multiple elements will likely operate within the calculation. Perhaps System X is configured such that it won’t allow a depreciable life to be entered as negative. Maybe System X displays a warning if a cost of zero or a negative value is entered. Conceivably, the system will log and report any transaction processed where an asset’s resulting accumulated depreciation exceeds net book value. System X is still processing depreciation charges based upon cost, depreciable lives, and depreciation methods, but it’s calculating depreciation expense correctly because of these automated application controls.
In other words, we may need to dig deeper than the calculation itself and also consider what rules the calculation is subject to.
Exercising Skepticism
An automated application control is only as effective as the application that supplies it. Meaning, it’s incumbent that we not only test the automated application control but also understand the application it sits inside.
Is the control programmed by a developer as part of the code within the application? Who requests or authorizes changes be made to the code? Are those changes tested, approved, and monitored by end users? Are developers properly segregated such that they can’t migrate their own code and sneak other functionality into the application? These questions help us determine the overall segregation of duties with respect to parties who can manipulate automated application controls (a potential fraud risk) as well as whether the development and implementation of program changes, such as the application control, are reasonably protected against the risk of error.
If the control can be configured, who can turn that configuration on or off, or change the parameters of the configuration such that the control operates differently? Who approves, tests, or otherwise monitors that configuration? Consider an automated three-way match control that compares receipt information entered into a system to purchase order and invoice data. If that control can be disabled, or if a value can be changed such that the automatic matching of invoices greater than $50 becomes $50,000 for a period of time, the automated application control subject to testing may not be as effective as presumed, and that control may need to be tested more than once and at different times over the course of the audit period. So, logical access controls within the application also become important elements of the automated application control.
Automated application controls are sometimes more complex than a “yes/no” operation (e.g., perform a three-way match or don’t). They may operate according to various scenarios, and data processed may be impacted differently depending upon which scenario it follows.
In such a case, each scenario is an element of the control, so we can’t simply test the scenario that evidences the successful processing of the transaction; we must consider the hurdles provided by the system where another scenario is followed (such as where a warning is generated or a transaction refused). These other scenarios provide the auditor greater assurance that the automated application control is operating than the successful scenario alone; they prove the system is preventing erroneous or fraudulent transactions from processing and therefore serve to mitigate the risk of a material financial statement misstatement.
Certain critical success factors help us properly test automated application controls, but we must remember that while all controls are processes, not all processes are controls. Likewise, we must focus on those specific elements within processes—those key controls that, in their absence or failure, could prompt a material misstatement. Meanwhile, automated application controls are more complex than a simple test of one transaction. They are supported by their corresponding systems and in turn protected by those systems’ general IT controls. They may prompt a transaction to follow one of many scenarios, requiring us to not only understand the logical access and program change controls protecting the systems we use, but various scenarios the system is programmed or configured to follow as well.
Brian A. Vazzana, CPA, CITP, CISA, is an information systems and financial assurance services partner with BDO USA, LLP in Chicago, who oversees the central region IS assurance practice.