Systems Development,Program Changes, and Application Controls:Application Controls

Application Controls

In addition to IT general controls, SOX requires management and auditors to consider application controls relevant to financial reporting. Application controls are associated with specific applications, such as payroll, purchases, and cash disbursements systems. These fall into three broad categories: input controls, processing controls, and output controls.

INPUT CONTROLS

Input controls are programmed procedures (routines) that perform tests on transaction data to ensure that they are free from errors. Input control routines should be designed into the system at different points, depending on whether transaction processing is real time or batch. Input controls in real-time systems are placed at the data collection stage to monitor data as they are entered from terminals. Batch systems often collect data in transaction files, where they are temporarily held for subsequent processing. In this case, input control tests are performed as a separate procedure (or run) prior to the master file update process. In any case, transaction data should never be used to update master files until the transactions have been tested for validity, accuracy, and completeness. If a record fails an input control test, it is flagged as an error record. Later, we will see how to deal with these records. The following are examples of input controls.

CHECK DIGIT. Data codes are used extensively in transaction processing systems for representing such things as customer accounts, items of inventory, and general ledger accounts in the chart of accounts. If the data code of a particular transaction is entered incorrectly and goes undetected, then a transaction processing error will occur, such as posting to the wrong account. Two common classes of data input errors cause such processing problems: transcription errors and transposition errors.

Transcription errors are divided into three categories:

1. Addition errors occur when an extra digit or character is added to the code. For example, inventory item number 83276 is recorded as 832766.

2. 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.

3. Substitution errors are the replacement of one digit in a code with another. For example, code number 83276 is recorded as 83266.

Transposition errors are of two types.

1. Single transposition errors occur when two adjacent digits are reversed. For instance, 83276 is recorded as 38276.

2. Multiple transposition errors occur when nonadjacent digits are transposed. For example, 83276 is recorded as 87236.

These problems may be controlled using a check digit. This is a control digit (or digits) added to the data 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 someplace 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 produce 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.

A popular check digit technique for dealing with transposition errors is modulus 11. Using the code 5372, the steps in this technique are outlined next.

1. Assign weights. 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:

2. Sum the products: (25 + 12 + 21 + 4 = 62).

3. Divide by the modulus. We are using modulus 11 in this case, giving 62/11 = 5 with a remainder of 7.

4. Subtract the remainder from the modulus to obtain the check digit: (11 - 7 = 4 [check digit]).

5. 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 code above was incorrectly entered as 35724, the recalculated check digit would be 6.

MISSING DATA CHECK. Some programming languages are restrictive as to the justification (right or left) of data within the field. If data are not properly justified or if a character is missing (has been replaced with a blank), the value in the field will be improperly processed. In some cases, the presence of blanks in a numeric data field may cause a system failure. When the control routine detects a blank where it expects to see a data value, the error is flagged.

NUMERIC–ALPHABETIC CHECK. This control identifies when data in a particular field are in the wrong form. For example, a customer’s account balance should not contain alphabetic data, and the presence of it will cause a data processing error. Therefore, if alphabetic data are detected, the error record flag is set.

LIMIT CHECK. Limit checks are used to identify field values that exceed an authorized limit. For example, assume the firm’s policy is that no employee works more than 44 hours per week. The payroll system input control program can test the HOURS WORKED field in the weekly payroll records for values greater than 44.

RANGE CHECK. Many times, data have upper and lower limits to their acceptable values. For example, if the range of pay rates for hourly employees in a firm is between $8 and $20, this control can exam- ine the pay rate field of all payroll records to ensure that they fall within this range. The purpose of this control is to detect keystroke errors that shift the decimal point one or more places. It would not detect an error where a correct pay rate of, say, $9 is incorrectly entered as $15.

REASONABLENESS CHECK. The error above may be detected by a test that determines if a value in one field, which has already passed a limit check and a range check, is reasonable when considered along with data in other fields of the record. For example, an employee’s pay rate of $18 per hour falls within an acceptable range. This rate is excessive, however, when compared to the employee’s job skill code of 693; employees in this skill class should not earn more than $12 per hour.

VALIDITY CHECK. A validity check compares actual field values against known acceptable values. This control is used to verify such things as transaction codes, state abbreviations, or employee job skill codes. If the value in the field does not match one of the acceptable values, the record is flagged as an error.

This is a frequently used control in cash disbursement systems. One form of cash disbursement fraud involves manipulating the system into making a fraudulent payment to a nonexistent vendor. To prevent this, the firm may establish a list of valid vendors with whom it does business exclusively. Thus, before payment of any trade obligation, the validation program matches the vendor number on the cash disbursement voucher against the valid vendor list. If the code does not match, payment is denied, and management reviews the transaction.

PROCESSING CONTROLS

After passing through the data input stage, transactions enter the processing stage of the system. Processing controls are programmed procedures and may be divided into three categories: batch controls, run-to- run controls, and audit trail controls.

Batch controls are used to manage the flow of high volumes of transactions through batch processing systems. The objective of batch control is to reconcile system output 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 begins at the data input stage and continues through all data processing phases of the sys- tem. Batch control involves grouping together into batches similar types of transactions (such as sales orders) and controlling them as a unit of work throughout data processing. To achieve this, a batch control record is created when the batch of transactions is entered into the system. This may be a user department action or a separate data control step. The control record contains relevant information about the batch, such as:

• A unique batch number.

• A batch date.

• A transaction code (indicating the types 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).

Figure 17-5 depicts a batch control record in relation to the batch of transactions it describes. The data in the control record are used to assess the integrity of the batch during all subsequent processing. For example, the batch control record in the figure shows a batch of 50 sales order records with a total dollar value of $122,674.87 and a hash total of 4537838.

Run-to-run control is the use of batch figures to monitor the batch as it moves from one programmed procedure (run) to another. Thus, at various points throughout processing and at the end of processing, the batch totals are recalculated and compared to the batch control record. This ensures that each run in the system processes the batch correctly and completely.

Figure 17-6 illustrates the use of run-to-run control in a sales order system. This application comprises four runs: (1) data input, (2) accounts receivable update, (3) inventory update, and (4) output. At the end of the accounts receivable run, batch control figures are recalculated and reconciled with the control totals passed from the data input run. These figures are then passed to the inventory update run, where they are again recalculated, reconciled, and passed to the output run. Errors detected in each run are flagged and placed in an error file. The run batch control figures are then adjusted to reflect the deletion of these records.

Notice from Figure 17-6 that error records may be placed on the error file at several different points in the process. In a separate procedure (not shown), an authorized user representative will make corrections to the error records and resubmit them as a special batch for reprocessing. Errors detected during processing require careful handling because these records may already be partially processed. Simply resubmit- ting the corrected records to the system at the data input stage may result in processing portions of these transactions twice. Two methods are used to deal with this complexity. The first is to reverse the effects of the partially processed transactions and resubmit the corrected records to the data input stage. The sec- ond method is to reinsert corrected records into the processing stage at which the error was detected.

The term hash total, which was used in the preceding discussion, is the summation of a nonfinancial field to keep track of the records in a batch. Any numeric field, such as a customer’s account number, a purchase order number, or an inventory item number, may be used to calculate a hash total. In the following example, the sales order number (SO#) field for an entire batch of sales order records is summed to produce a hash total.

Let’s see how we can use this seemingly meaningless number. Assume that after this batch of records is created, someone replaced one of the sales orders in the batch with a fictitious record of the same dollar amount. How would the batch control procedures detect this irregularity? Both the record count and the dollar amount control totals would still balance. However, the hash total that the batch control procedures calculated would not balance. The irregularity would thus be detected.

Audit trail controls in an IT environment ensure that every transaction can be traced through each stage of processing from its economic source to its presentation in financial statements. The following are examples of audit trail control.

TRANSACTION LOGS. Every transaction the system successfully processes should be recorded on a transaction log, which serves as a journal. Figure 17-7 shows this process. Two reasons underscore

 the importance of this log. First, the transaction log is a permanent record of transactions, although the input transaction file is typically a temporary file. Once processed, the records on the input file are erased to make room for the next batch of transactions. Second, not all of the records in the input file may be successfully processed. Some of them will fail tests during subsequent processing and will be passed to an error file. A transaction log contains only successful transactions—those that have changed account balances. The transaction log and error files combined should account for all the transactions in the batch. The validated transaction file may then be scratched with no loss of data.

LOG OF AUTOMATIC TRANSACTIONS. The system triggers some transactions internally. For example, when inventory drops below the reorder point, the system automatically generates a purchase order. To maintain an audit trail of these activities, all internally generated transactions must be placed in a transaction log.

TRANSACTION LISTINGS. The system should produce a (hard-copy) transaction listing of all successful transactions. These listings should go to the appropriate users to facilitate reconciliation with input. In addition, the responsible end user should receive a detailed listing of all internally generated transactions.

OUTPUT CONTROLS

Output controls are a combination of programmed routines and other procedures to ensure that system output is not lost, misdirected, or corrupted and that privacy is not violated. Exposures of this sort can cause serious disruptions to operations and may result in financial losses to a firm. For example, if the checks a firm’s cash disbursements system produces are lost, misdirected, or destroyed, trade accounts and other bills may go unpaid. This could damage the firm’s credit rating and result in lost discounts, interest, or penalty charges. If the privacy of certain types of output is violated, a firm could have its business objectives compromised or could become exposed to litigation. Examples of privacy exposures include the disclosure of trade secrets, patents pending, marketing research results, and patient medical records. This section examines output exposures and controls for both hard-copy and digital output.

Controlling Hard-Copy Output

Batch systems usually produce hard copy, which typically requires the involvement of intermediaries in its production and distribution. Figure 17-8 shows the stages in this output process and serves as the basis for this section.

OUTPUT SPOOLING. In large-scale data processing operations, output devices such as line printers can become backlogged with many programs simultaneously demanding limited resources. This can cause a bottleneck and adversely affect system throughput. To ease this burden, applications are often designed to direct their output to a magnetic disk file rather than print it directly. This is called spooling. Later, when printer resources become available, the output files are printed.

The creation of an output file as an intermediate step in the printing process presents an added exposure. A computer criminal may use this opportunity to:

1. Access the output file and change critical data values (such as dollar amounts on checks). The printer program will then print the fallacious output as if the system produced it.

2. Access the file and change the number of copies of output to be printed. The extra copies may then be removed without notice during the printing stage.

3. Make a copy of the output file to produce illegal output reports.

4. Destroy the output file before output printing takes place.

The management and auditors need to be aware of these potential exposures and ensure that proper access and backup procedures are in place to protect output files. We discussed file access and backup controls in Chapter 15.

PRINT PROGRAMS. When a printer becomes available, the print run program produces hard-copy output from the output file. Print programs are often complex systems that require operator intervention. Four common types of operator actions are:

1. Pausing the print program to load the correct type of output documents (check stocks, invoices, or other special forms).

2. Entering parameters that the print run needs, such as the number of copies to be printed.

3. Restarting the print run at a prescribed checkpoint after a printer malfunction.

4. Removing printed output from the printer for review and distribution.

Print program controls should be designed to deal with two types of exposures present in this environ- ment: (1) the production of unauthorized copies of output and (2) employee browsing of sensitive data. Some print programs allow the operator to specify more copies of output than the output file calls for, which allows for the possibility of producing unauthorized copies of output. One way to control this is to employ output document controls. This is feasible only when dealing with prenumbered invoices for bill- ing customers or prenumbered check stock. At the end of the run, the number of copies the output file specifies should be reconciled with the actual number of output documents used.

To prevent operators and others from viewing sensitive output, special multipart paper can be used, with a grayed-out top copy to prevent the print from being read. This type of product is often used for payroll check printing. An alternative privacy control is to direct the output to a special remote printer that can be closely supervised.

WASTE. Computer output waste is a potential source of exposure. Aborted reports and the carbon copies from multipart paper need to be disposed of properly. Computer criminals disguised as janitorial staff have been known to sift through trash cans searching for carelessly discarded output that is presumed to be of no value. From such trash, computer criminals may obtain information about a firm’s market research, credit ratings of its customers, or even trade secrets, which they can sell to a competitor. Computer waste is also a source of passwords that a perpetrator may use to access the firm’s computer system. To control against this threat, all sensitive computer output should be passed through a paper shredder.

REPORT DISTRIBUTION. The primary risks associated with the distribution of sensitive reports include their being lost, stolen, or misdirected in transit to the user. The following control techniques can be used:

1. The reports may be placed in a secure mailbox to which only the user has the key.

2. The user may be required to appear in person at the distribution center and sign for the report.

3. A security officer or special courier may deliver the report to the user.

END-USER CONTROLS. Once in the hands of the user, output reports should be examined for correctness. Errors the user detects should be reported to the appropriate computer services management. Such errors may be symptoms of an improper systems design, incorrect procedures, errors accidentally inserted during systems maintenance, or unauthorized access to data files or programs. Once a report has served its purpose, it should be stored in a secure location until its retention period has expired and then it should be shredded.

Controlling Digital Output

Digital output can be directed to the user’s computer screen or printer. The primary output threat is the interception, disruption, destruction, or corruption of the output message as it passes across the communications network. This threat comes from two types of exposures: (1) exposures from equipment failure and (2) exposures from subversive acts. We discussed techniques for controlling communications exposures in Chapter 16.