Concurrent Auditing Techniques
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.
Snapshot
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
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.