Concurrent auditing techniques are tools that auditors use to collect audit evidence on the reliability of a computer-based application system at the same time as the application system carries out live operational processing of transaction data. They are implemented via program instructions that are embedded within the application software or within the system software, such as the database management system, that supports the application system (Clark et al., Groomer & Murthy, 1989). In sensitive, high-materiality application systems, concurrent auditing techniques may be executed continuously. Alternatively, they may be executed periodically e.g. during random intervals or during high-risk intervals. The evidence they collect can be reported immediately to the auditor, which is likely to be the case if high-risk errors or irregularities are identified during application system processing. Alternatively, the evidence they collect can be stored and reported periodically, which is likely to be the case when the expected losses associated with the exceptions identified are low.
Development of Concurrent Auditing Techniques
Concurrent auditing techniques are not new. They were developed in the late 1960s and early 1970s to address certain problems that were emerging in conducting audits of computer systems. These problems were as follows:
Disappearing Paper-Based Audit Trail – Historically, auditors have placed substantial reliance on the paper trail used to document the events that occur in accounting systems. They have referenced this paper trail to determine whether errors or irregularities have occurred within a system. With the emergence of computer systems, much of the paper-based audit trail has disappeared. Without purposeful design, adequate recording of events may not occur in a computer system. Concurrent auditing techniques provide a means for auditors to ensure that a system records the events in which they are interested.
Difficulty of Performing Transaction Walkthroughs – One way in which auditors have sought to understand an application system is to trace material transaction types through the various processing steps in the system. In most manual systems, this technique is fairly straightforward to use. With increasing use of computer systems, however, the range of functions that could be provided on a cost-effective basis within application systems has expanded. As a result, application systems have become more complex, and transaction walkthroughs have become more difficult to undertake. Auditors have used concurrent auditing techniques to collect evidence on a transaction as it passes through an application system and to assemble and report this evidence in a way that can be easily understood.
The Need for Timely Identification of Errors and Irregularities – Because of the speed with which computers operate, errors or irregularities have not always been identified on a timely basis. In some cases, organizations have suffered substantial losses as a result. Traditional ex post or retrospective auditing has sometimes been inadequate as a means of identifying errors or irregularities on a timely basis. Auditors have used concurrent auditing techniques to identify errors or irregularities immediately they have occurred.
The above reasons for using concurrent auditing techniques remain valid today. Several recent other factors, however, have emerged that motivate more extensive use of concurrent auditing techniques. These factors include the following:
Increased Integration of Information Systems – Information systems are becoming increasingly integrated, both within an organization and externally via links to systems in other organizations. As a result, the complexity of information systems is increasing. Concurrent auditing techniques help auditors to understand how the reliability of different components of an information system impacts on the reliability of other components.
Increased Incidence of Distributed Information Systems – The locations where information systems functions are performed are becoming increasingly dispersed. The infrastructure that now supports many information systems comprises physically remote, heterogeneous hardware and software platforms. Auditors may be unable to visit all sites where information processing is conducted. Concurrent auditing techniques can be installed at remote sites to collect evidence on their behalf.
Increased Exposures When Errors and Irregularities Occur – As systems become increasingly integrated and perform a greater range of functions (sometimes safety-critical functions), the expected losses from errors and irregularities increase. For example, a computer virus that is introduced into one system can propagate quickly to other systems via communication networks. As a result, timely identification of errors becomes more important. Concurrent auditing techniques permit errors and irregularities to be identified as they occur.
Presence of Entropy in Systems – All systems suffer entropy i.e., the tendency toward disorder and eventual collapse. Information systems experience entropy for a variety of reasons. For example, system design errors or programming errors may exist such that they would slowly undermine the effectiveness and efficiency of the system. User information requirements can also change and, as a result, an information system may no longer meet its users’ needs. Concurrent auditing techniques provide a means of detecting entropy as it occurs. For example, they can be used to detect increasing error rates during data capture and input.
The Need for More Effective and Efficient Audits – During the 1980s and 1990s, auditors have been placed under substantial pressure to improve the effectiveness and efficiency of their audits. Many of their clients have suffered from prolonged periods of economic recession. Moreover, institutional and regulatory changes have occurred that have substantially increased competition in the market-place for audit services. Concurrent auditing techniques sometimes provide a more cost-effective way of performing some types of audit functions, thereby allowing auditors to better cope with client and market place pressures.
Types of Concurrent Techniques
Over the years, a large number of different types of concurrent auditing techniques have been proposed. Nevertheless, Mohrweis (1988) argues that they all fall into three general categories: (1) those that can be used to test an application system with test data during normal processing; (2) those that can be used to select transactions during normal processing for audit review; and (3) those that can be used to trace, map, or document the state of a system during normal processing.
The subsections below provide a brief description of five concurrent auditing techniques. The first, ”Integrated Test Facility” is an example of a concurrent auditing technique that is used to collect test data during normal processing. The second and third, “System Control Audit Review Files” and “Continuous and Intermittent Simulation“, are examples of concurrent auditing techniques that are used to select transactions during normal processing for subsequent audit review. The fourth and fifth, “Snapshots” and “Extended Records” are examples of concurrent auditing techniques that trace, map, or document the state of a system during normal processing.
Let me describe each of the above techniques in more detail. Read on…
Integrated Test Facility
The integrated test facility technique (ITF) involves auditors establishing a mini company or dummy company on the live files processed by an application system. For example, in a payroll system, auditors might establish a master-file record for a fictitious employee. Auditors then submit test data to the application system as part of the normal transaction data entered into the system. They monitor the effects of their test data on the dummy entity they have established.
Two major design decisions must be made when auditors use ITF. First, auditors must determine what method will be used to enter test data. One approach is to select and tag live transactions. The tagged transactions then update not only their target records but also the dummy entity that has been established. An alternative approach is to design and create test transactions specifically for the application. These test transactions update only the dummy entity. Second, auditors must determine how the effects of test transactions will be masked within the application system being tested. One approach is to submit transactions that have immaterial amounts and which, therefore, are unlikely to be noticed by application system users. A second approach is to submit reversal entries so that the net effect of the test transactions is zero. A third approach is to modify the application system so the test transactions are not counted in the application system’s control totals. This third approach is the most expensive, but it is often the most effective.
System Control Audit Review File
With a system control audit review file (SCARF), auditors embed audit routines into an application system and collect data on events that are of interest to them. This data is then written to a file (hence the name of the technique) for subsequent review or subsequent use in other tests that auditors may wish to conduct.
Leinicke et al. (1990) describe an example of how SCARF might be used within an insurance company to detect unauthorized changes to policyholder master records followed by subsequent fund withdrawals. When a name-and-address change is made to a policyholder record, the change can be recorded via SCARF. Any subsequent withdrawal of funds above a material amount can then be monitored by SCARF and reported for audit scrutiny. In this way a fraudulent withdrawal of funds can be detected. For example, without authorization, an insurance company employee may change a policy-holder’s name and address to their own name and address. The employee then may fraudulently borrow money against the policy or withdraw funds against the policy.
Continuous and Intermittent Simulation
Continuous and intermittent simulation (CIS) has been proposed by Koch (1981) as a means of collecting audit evidence concurrently with application system processing when the application system uses a database management system to support updating and querying of application files.
CIS has two major components. First, like SCARF, the database management system must be able to trap transactions that are of interest to the auditor. Koch initially proposed that the database management system be modified to capture transactions. Some current database management systems, however, provide facilities that allow auditors to write their own software routines that the database management system will execute on their behalf. Second, auditors must write software modules that will replicate the application system processing that is of interest. The database management system then passes the transactions it captures across to these modules. These modules in turn determine the results that should be produced as a result of the transaction. The results produced by the audit modules are then compared with the results produced by the application system. Deviations are written to a file for scrutiny by the auditor.
To illustrate the use of CIS, consider a financial application where auditors are concerned about the accuracy of the calculations relating to the payout value when a customer of the financial institution pays out a loan early. The database management system would identify a payout transaction as being one of the transactions that interest the auditor. It would capture the payout transaction and pass the transaction across to the audit modules. The modules would then calculate the payout value. In the meantime, the application system also would have calculated the payout value. The payout value calculated by the audit modules would then be compared with the payout value calculated by the application system. If a discrepancy existed between the two values, an exception would be written to an audit file.
The snapshot technique is straightforward. As the name implies, it involves taking “snapshots” or “pictures” of a transaction as it winds its way through an application system. In essence, it is an automated version of a manual transaction walkthrough. Snapshots are taken at material processing points in the application system.
Auditors must first identify these points and then embed audit modules within the application system at these points. At each of these points, the audit modules typically take a snapshot of the transaction just prior to processing and a snapshot just after processing. The auditor then has the before-image of the transaction and the after-image of the transaction as a basis for evaluating the authenticity, accuracy, and completeness of the application processing carried out. These snapshots are written away to an audit file for subsequent scrutiny by the auditor.
To illustrate use of snapshot, consider an order that is input to a manufacturer’s order entry system. The order may pass through a number of processing points that are of audit significance. For example: the customer has to be an authorized customer; the amount of the purchase must be within certain credit limits; a discount might be given depending upon the status of the customer and the type of product that the customer is wanting to purchase; the order might be “exploded” via a bill-of-materials to determine the parts required to make the product ordered; shortages of parts may invoke a purchase order being placed on a supplier. At some or all of these points, snapshots might be taken so the auditor can examine the veracity of processing at each point.
Extended records are a simple extension of the snapshot technique. Using conventional snapshot, individual snapshots are simply written to an audit file. Auditors then must assemble all the snapshots that pertain to a particular transaction and a particular stream of processing that the transaction undergoes. If a large number of snapshots are taken, assembling related snapshots can be onerous.
The extended records technique collects all related snapshots together in a single record. As a transaction passes through the various snapshot points, the snapshots are appended to a record that is eventually written to a file for audit scrutiny. Auditors then do not bear the overheads of sorting related snapshots together. More timely scrutiny of veracity of the transaction and the application processing stream is possible.
Users of the Concurrent Techniques
In spite of the apparent benefits of concurrent auditing techniques, they have had a checkered history. Below table reports the results of a number of surveys taken periodically since 1978 (Reeve, 1984). A common definition for the different types of concurrent auditing techniques has not been used in the surveys. Moreover, in some cases, data was not collected on a particular technique, and different types of auditors were surveyed.
Nevertheless, a common theme emerges namely, concurrent auditing techniques are not in widespread use, and usage has not increased over the years.
The results of the surveys also indicate that several factors seem to affect usage of concurrent auditing techniques:
- First, internal auditors are more likely to use concurrent auditing techniques than external auditors. Concurrent auditing techniques can require substantial resources to establish and maintain them, and internal auditors are better placed to support and use concurrent auditing techniques.
- Second, concurrent auditing techniques are more likely to be used if auditors are involved in the development work associated with a new system. It is easier to install concurrent techniques from the outset rather than to retrofit an application system with a concurrent auditing technique.
- Third, concurrent auditing techniques are more likely to be used if other types of computer-based audit techniques are also in use. Auditors are more likely to have the knowledge to employ concurrent auditing techniques if they use a portfolio of computer-based audit techniques.
- Fourth, concurrent auditing techniques are more likely to be used as the incidence of automatically-generated transactions increases. The audit trail is less visible for these types of transactions, and there can be high exposures if an error or irregularity occurs.
Limitations of Concurrent Auditing Techniques
Use of concurrent auditing techniques often is not straightforward. A number of drawbacks exist:
- Auditors must have a reasonable level of knowledge about computer systems if they are to design and implement concurrent auditing techniques effectively. In addition, they must have a good knowledge of the application system.
- Stakeholders in the application system must support the use of concurrent auditing techniques. For example: management must provide the resources needed to design, implement, and use concurrent auditing techniques; information systems personnel must keep auditors abreast of changes to the application system that might impact any concurrent auditing techniques that have been implemented; application system users must be prepared to bear the costs sometimes associated with the disruption that occurs when concurrent auditing techniques are used.
- Concurrent auditing techniques are unlikely to be effective unless they are implemented n application systems that are stable. If application systems are subject to frequent change, the costs of maintaining concurrent auditing techniques are likely to be prohibitive.