CHAPTER 7 Computer-Assisted Audit Tools and Techniques L E A R NI NG O B J E CT I V E S After studying this chapter, you should: • Be familiar with the classes of transaction input controls used by accounting applications. • Understand the objectives and techniques used to implement processing controls, including run-to-run, operator intervention, and audit trail controls. • Understand the methods used to establish effective output controls for both batch and real-time systems. • Know the difference between black box and white box auditing.
• Be familiar with the key features of the five CAATTs discussed in the chapter. T his chapter examines several issues related to the use of computer-assisted audit tools and techniques (CAATTs) for performing tests of application controls and data extraction. It opens with a description of application controls. These fall into three broad classes: input controls, processing controls, and output controls.
The chapter then examines the black box and white box approaches to testing application controls. The latter approach requires a de- tailed understanding of the application’s logic. Five CAATT approaches used for testing application logic are then examined: the test data method, base case system evaluation, tracing, integrated test facility, and parallel simulation. 289 Copyright 2011 Cengage Learning, Inc.
All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. 290 Chapter 7: Computer-Assisted Audit Tools and Techniques APPLICATION CONTROLS Application controls are programmed procedures designed to deal with potential expo- sures that threaten specific applications, such as payroll, purchases, and cash disburse- ments systems. Application controls fall into three broad categories: input controls, processing controls, and output controls.
Input Controls The data collection component of the information system is responsible for bringing data into the system for processing. Input controls at this stage are designed to ensure that these transactions are valid, accurate, and complete. Data input procedures can be either source document-triggered (batch) or direct input (real time). Source document input requires human involvement and is prone to clerical errors.
Some types of errors that are entered on the source documents cannot be detected and corrected during the data input stage. Dealing with these problems may require tracing the transaction back to its source (such as contacting the customer) to correct the mis- take. Direct input, on the other hand, employs real-time editing techniques to identify and correct errors immediately, thus significantly reducing the number of errors that enter the system. Classes of Input Control For presentation convenience and to provide structure to this discussion, we have divided input controls into the following broad classes: • Source document controls • Data coding controls • Batch controls • Validation controls • Input error correction • Generalized data input systems These control classes are not mutually exclusive divisions.
Some control techniques that we shall examine could fit logically into more than one class. Source Document Controls. Careful control must be exercised over physical source documents in systems that use them to initiate transactions. Source document fraud can be used to remove assets from the organization.
For example, an individual with access to purchase orders and receiving reports could fabricate a purchase transaction to a non- existent supplier. If these documents are entered into the data processing stream, along with a fabricated vendor’s invoice, the system could process these documents as if a legitimate transaction had taken place. In the absence of other compensating controls to detect this type of fraud, the system would create an account payable and subse- quently write a check in payment. To control against this type of exposure, the organization must implement control procedures over source documents to account for each document, as described next: Use Pre-numbered Source Documents.
Source documents should come prenumbered from the printer with a unique sequential number on each document. Source document numbers permit accurate accounting of document usage and provide an audit trail for trac- ing transactions through accounting records. We discuss this further in the next section. Copyright 2011 Cengage Learning, Inc.
All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Application Controls 291 Use Source Documents in Sequence. Source documents should be distributed to the users and used in sequence.
This requires that adequate physical security be main- tained over the source document inventory at the user site. When not in use, documents should be locked away. At all times, access to source documents should be limited to authorized persons. Periodically Audit Source Documents.
Reconciling document sequence numbers should identify missing source documents. Periodically, the auditor should compare the numbers of documents used to date with those remaining in inventory plus those voided due to errors. Documents not accounted for should be reported to management. Data Coding Controls.
Coding controls are checks on the integrity of data codes used in processing. A customer’s account number, an inventory item number, and a chart of accounts number are all examples of data codes. Three types of errors can cor- rupt data codes and cause processing errors: transcription errors, single transposition errors, and multiple transposition errors. Transcription errors fall into three classes: • Addition errors occur when an extra digit or character is added to the code.
For example, inventory item number 83276 is recorded as 832766. • Truncation errors occur when a digit or character is removed from the end of a code. In this type of error, the inventory item above would be recorded as 8327. • Substitution errors are the replacement of one digit in a code with another.
For example, code number 83276 is recorded as 83266. There are two types of transposition errors. Single transposition errors occur when two adjacent digits are reversed. For instance, 83276 is recorded as 38276.
Multiple trans- position errors occur when nonadjacent digits are transposed. For example, 83276 is recorded as 87236. Any of these errors can cause serious problems in data processing if they go unde- tected. For example, a sales order for customer 732519 that is transposed into 735219 will be posted to the wrong customer’s account.
A similar error in an inventory item code on a purchase order could result in ordering unneeded inventory and failing to order inventory that is needed. These simple errors can severely disrupt operations. One method for detecting data coding errors is a check digit. A check digit is a control digit (or digits) added to the code when it is originally assigned that allows the integrity of the code to be established during subsequent processing.
The check digit can be located anywhere in the code: as a prefix, a suffix, or embedded some- place in the middle. The simplest form of check digit is to sum the digits in the code and use this sum as the check digit. For example, for the customer account code 5372, the calculated check digit would be 5 3 7 2 17 By dropping the tens column, the check digit 7 is added to the original code to pro- duce the new code 53727. The entire string of digits (including the check digit) becomes the customer account number.
During data entry, the system can recalculate the check digit to ensure that the code is correct. This technique will detect only transcription errors. For example, if a substitution error occurred and the above code were entered as 52727, the calculated check digit would be 6 (5 2 7 2 16 6), and the error would be detected. However, this technique would fail to identify transposition errors.
For example, transposing the first two digits yields the code 35727, which still sums to 17 and produces the check digit 7. This error would go undetected. Copyright 2011 Cengage Learning, Inc. All Rights Reserved.
May not be copied, scanned, or duplicated, in whole or in part. 292 Chapter 7: Computer-Assisted Audit Tools and Techniques There are many check-digit techniques for dealing with transposition errors. A pop- ular method is modulus 11. Using the code 5372, the steps in this technique are as follows: 1.
Each digit in the code is multiplied by a different weight. In this case, the weights used are 5, 4, 3, and 2, shown as follows: Digit Weight 5 5 25 3 4 12 7 3 21 2 2 4 2. Sum the products (25 12 21 4 62). Divide by the modulus.
We are using modulus 11 in this case, giving 62/11 5 with a remainder of 7. Subtract the remainder from the modulus to obtain the check digit (11 7 4 [check digit]). Add the check digit to the original code to yield the new code: 53724. Using this technique to recalculate the check digit during processing, a transposition error in the code will produce a check digit other than 4.
For example, if the preceding code were incorrectly entered as 35724, the recalculated check digit would be 6. When Should Check Digits Be Used?. The use of check digits introduces storage and processing inefficiencies and therefore should be restricted to essential data, such as pri- mary and secondary key fields. All check digit techniques require one or more additional spaces in the field to accommodate the check digit.
In the case of modulus 11, if step three above produces a remainder of 1, the check digit of 10 will require two additional character spaces. If field length is a limitation, one way of handling this problem is to disallow codes that generate the check digit 10. This would restrict the range of available codes by about 9 percent. Batch controls are an effective method of managing high volumes of transaction data through a system.
The objective of batch control is to reconcile output produced by the system with the input originally entered into the system. This provides assurance that: • All records in the batch are processed. • No records are processed more than once. • An audit trail of transactions is created from input through processing to the output stage of the system.
Batch control is not exclusively an input control technique. Controlling the batch continues through all phases of the system. We are treating this topic here because batch control is initiated at the input stage. Achieving batch control objectives requires grouping similar types of input transac- tions (such as sales orders) together in batches and then controlling the batches throughout data processing.
Two documents are used to accomplish this task: a batch transmittal sheet and a batch control log.1 shows an example of a batch transmittal sheet. The batch transmittal sheet captures relevant information such as the following about the batch. • A unique batch number • A batch date Copyright 2011 Cengage Learning, Inc. All Rights Reserved.
May not be copied, scanned, or duplicated, in whole or in part. Application Controls 293 FIGURE 7.1 Batch Transmittal Sheet ABC Company Batch Transmittal Sheet Batch # 1 2 4 0 3 Transaction 0 1 9 Code Date 12 04 2010 1 2 6 Prepared User # J. S By Control Data Record Hash Control Count Total Total 0 5 0 4 5 3 7 8 3 8 1 2 2 6 7 4 8 7 • A transaction code (indicating the type of transactions, such as a sales order or cash receipt) • The number of records in the batch (record count) • The total dollar value of a financial field (batch control total) • The total of a unique nonfinancial field (hash total) Usually, the batch transmittal sheet is prepared by the user department and is sub- mitted to data control along with the batch of source documents. Sometimes, the data control clerk, acting as a liaison between the users and the data processing department, prepares the transmittal sheet.2 illustrates the batch control process.
The data control clerk receives transactions from users assembled in batches of 40 to 50 records.