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 systems 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-holders 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 manufacturers 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.
8.

CONCURRENT AUDITING TECHNIQUES

8.1 Concurrent auditing techniques are the techniques developed to collect evidence at the
same time as an application system undertakes processing of its production data. Disappearing
paper-based audit trail, need for monitoring required by advanced systems, increasing difficulty
of performing transaction walk throughs are some of the reasons for deploying concurrent
auditing techniques more extensively. The following are important types of concurrent auditing
techniques:
8.2 Integrated test facility (ITF)
The ITF technique involves establishing a mini company or dummy entity on an
application systems files and processing audit test data against the entity as a means of verifying
processing authenticity, accuracy and completeness. Auditors would then use test data to update
the fictitious entities. This test data would be included with the normal production data used as
input to the application system. The application system must be programmed to treat the tagged
transactions in a special way. The presence of ITF transactions within an application system
affects the output results obtained. The effects of ITF transactions must be removed on
completion of audit.
8.3 Snapshot
The snapshot technique involves having software take "pictures" of a transaction as it
flows through an application system. Typically auditors embed the software in the application
system at those points where they deem material processing occurs. The embedded software then

captures images of a transaction as it progresses through these various processing points. To

validate processing at the different snapshot points, auditors usually have the embedded software
capture both before images and after images of the transaction. They then can assess the
authenticity, accuracy and completeness of the processing carried out on the transaction by
scrutinising the before images, after images and the transformation that has occurred on the
transaction.
8.4 System control audit review file (SCARF)
The SCARF technique involves embedding audit software modules within a host
application system to provide continuous monitoring of the systems transactions. These audit
modules are placed at predetermined points to gather information about transactions or events
within the system that auditors deem to be material. The information collected is written onto a
special audit file-the SCARF master file. Auditors then examine the information contained on
this file to see if some aspect of the application system needs follow up.
8.5 Continuous and intermittent simulation (CIS)
8.5.1 CIS is a variation of SCARF concurrent auditing technique, which can be used
whenever application systems use a database management system. CIS uses the database
management system to trap the expectations. When the database management system reads an
application system transaction, it invokes CIS and passes the transaction across to CIS. CIS then
determines whether it wants to examine the transaction further. If the transaction is selected, the
next three steps are executed; otherwise, CIS waits for a new transaction.
8.5.2
The database management system provide CIS with all data requested by
the application system to process the selected transaction. CIS replicates application system
processing in the same way that a parallel simulation program replicates application system
processing. Every update to the database that arises from processing the selected transaction will
be checked by CIS to determine whether discrepancies exist between the results it produces and
those the application system produces.