Audit clients who have not computerized their accounting systems to some extent are all but non-existent in today's marketplace. Probably as difficult to locate would be an auditor who had not questioned whether he or she had properly considered the impact of a computerized environment on audit strategy. One relevant question in a computerized environment that every auditor should ask is, "Does my audit approach result in inadvertent reliance on computer-based controls without having properly tested these controls?" This article identifies the types of situations in which an auditor could be unknowingly relying on untested computer controls, the possible actions to be taken by the auditor in such situations, and modifications required as a result of recent changes to the SASs.

SAS 48 makes it very clear that the auditor must consider the impact of computer processing of significant accounting information on audit design. However, SAS 48 only lists matters that the auditor should consider in making such an evaluation without giving any specifics of how the existence of a computer environment would effect audit design.

Neither SAS 48 nor newly issued SAS 55, "Consideration of Internal Control Structure in A Financial Statement Audit," require the auditor to rely on computer-based controls (i.e., controls that exist in machine readable format only; generally referred to as "programmed procedures") even in an EDP environment. The testing of programmed procedures requires audit techniques such as the use of test data, parallel simulation, or an Integrated Test Facility (ITF). Because these procedures require a degree of computer skills that many auditors do not feel they possess, auditors often choose not to perform them and therefore do not consider these controls in designing the audit (SAS 55 does not require the reliance on any control policies or procedures, since audit risk can always be assessed at maximum). In such a situation the auditor chooses to "audit around the computer" and increase the amount of substantive testing and/or otherwise change the timing and/or nature of substantive procedures.

The auditor might also choose to test and rely on user controls that are designed to control the quality of EDP processed data. Such a philosophy is not necessarily flawed. However, if the auditor chooses this approach because of either a lack of expertise or efficiency considerations, he or she should be very careful not to rely on the accuracy of computer output without first testing the integrity of the computer generated data through either properly designed substantive tests or tests of user controls.

User Controls or EDP Controls--Which is It?

In an environment in which accounting data is processed by computer, controls should exist in one of two forms: 1) user controls, or 2) EDP controls. User controls are entirely independent of the EDP process and are manually performed by groups using the EDP output. They typically consist of reconciling output to input.

EDP-based controls (i.e., application control procedures) rely on the existence of: 1) programmed control procedures, and 2) the manual follow-up of computer exception reports. These, in turn, rely upon the existence of general control procedures that are made up of three independent components: 1) access controls, 2) system development and program change controls, and 3)controls over computer operations.

The auditor in an EDP environment should recognize that although the components of EDP control function independently of one another, no single component of an EDP control can be relied upon to prevent or detect errors without the effective operation of the others. Furthermore, if the auditor fails to properly distinguish between user controls and the manual follow-up component of an EDP control, improper audit design will likely result. The audit design flaw occurs as follows:

1. The auditor mistakenly identifies the manual follow-up component of an EDP control as a user control. 2. The auditor fails to test the related access controls, systems development/program change controls, etc. because he or she feels that tests of computer controls are unnecessary in that he/she is auditing "around the computer." 3. The auditor tests the functioning of the control and relies on the control in designing the audit. Such reliance is unjustified because the components of the EDP controls have not been tested.

This mistake is easily made because both user controls and the manual component of an EDP control normally involve manual procedures.

For example, suppose that a client's EDP system produces an exception report listing all submitted sales transactions that cannot be matched with a shipping document in the computer file of processed shipping documents. These sales are not processed against the current file until the sales department performs a manual follow-up to identify the problem and submits the item(s) for reprocessing. Reports are maintained in the sales department on the resolution of all transactions appearing in the exception reports, and the computer maintains a suspense file of all flawed sales transactions that have not been resubmitted or otherwise cleared.

If, in this situation, the auditor does not desire to rely on (and therefore test) computer controls, the control just described (i.e., manual follow-up on all items appearing on the exception report) cannot be relied upon in auditing sales. Why not? Because the control described is not a user control. The effectiveness of the described process depends on the integrity of the computer generated exception report. If the auditor tests the performance of this control only and then relies on it in designing the audit, the audit will be improperly designed. Even though manual user follow-up is involved in the execution of this control, its effectiveness is dependent upon the quality of the computer generated exception report which, in turn, is dependent upon the adequacy of the computer generated control procedures.

Be Careful

Auditors should be particularly careful to avoid this type of error by carefully analyzing any control upon which he or she desires to rely that appears to be a user control, but involves the use of computer generated exception reports or totals. If the quality of the information being employed by the user is dependent upon the proper functioning of a computer program, it is not a user control and cannot be relied upon without first testing the computer generated control procedures related to that specific manual follow-up control.

Auditors should also be aware of the fact that many user controls that are based on batch or hash totals cannot be relied upon entirely to control the quality of computer output. For example, suppose the credit department calculates a total of accounts payable credits submitted for computer processing and then manually compares this total with the total of transactions processed on a subsequent computer printout and/or uses the control total to reconcile the before and after accounts payable totals on a computer printout. An auditor may, in such circumstances, conclude that the quality of the computer generated control totals for accounts payable has been validated by the user control. However, this is only partially true. While the user control can be relied upon to verify the accuracy of the total accounts payable, testing would be necessary to rely on the accuracy of individual balances making up the total of accounts payable. The accounts payable printout cannot be assumed to be accurate simply because the total of the listing has been subjected to a user control.

Lowell S. Broom, DBA, CPA, University of Alabama at Birmingham and Paul D. Warner, PhD, CPA, Pace University, Pleasantville, NY