PART 4-1B: OBJECTIVE 4: COMPUTER PROCESSING
Types of Error and Fraud
Fail to detect erroneous input
Improperly correct input errors
Process erroneous input
Improperly Distribute or disclose output
Control Procedures
Computer data editing routines
Proper use of internal and external file labels
Reconciliation of batch totals
Effective error correction procedures
Understandable operating documentation and run manuals
Competent supervision of computer operations
Effective handling of data input and output by data control personnel
File change listings and summaries prepared for user department review
Maintenance of proper environmental conditions in computer facility
Audit Process: Systems Review
Review administrative documentation for processing control standards
Review systems documentation for data editing and other processing controls
Review operating documentation for completeness and clarity
Review copies of error listings, batch total reports, and file change lists
Observe computer operations and data control functions
Discuss processing and output controls with operations and IS supervisory personnel
Audit Procedures: Test of Controls
Evaluate adequacy of processing control standards and procedures
Evaluate adequacy and completeness of data editing controls
Verify adherence to processing control procedures by observing computer operations and the data control function
Verify that selected application system output is properly distributed
Reconcile a sample batch totals, and follow up on discrepancies
Trace disposition of a sample of errors flagged by data edit routines to ensure proper handling
Verify processing accuracy for a sample of sensitive transactions
Verify processing accuracy for selected computer-generated transactions
Search for erroneous or unauthorized code via analysis of program logic
Check accuracy and completeness of processing controls using test data
Monitor online processing systems using concurrent audit techniques
Recreate selected reports to test for adequacy and completeness
Compensating Controls
- Auditors must periodically reevaluate processing controls to ensure their continued
reliability.
If controls are unsatisfactory, user and source data controls may be strong enough to compensate.
If not, a material weakness exists, and steps should be taken to eliminate the control deficiencies.
The purpose of the preceding audit procedures is to gain an understanding of the controls, evaluate its adequacy, and observe operations for evidence that the controls are in use.
Several specialized techniques allow the auditor to use the computer to test processing controls:
Processing test data
Using concurrent audit techniques
Analyzing program logic
Each has its own advantages and disadvantages:
Appropriateness of each technique depends on the situation
No one technique is good for all circumstances
Auditors should not disclose which technique they use.
Processing Test Data
Involves testing a program by processing a hypothetical series of valid and invalid transactions.
The program should:
Process all the valid transactions correctly
Identify and reject the invalid ones
All logic paths should be checked for proper functioning by one or more test transactions, including:
Records with missing data
Fields containing unreasonably large amounts
Invalid amount numbers or processing codes
Non-numeric data in numeric fields
Records out of sequence
The following resources are helpful when preparing test data:
A listing of actual transactions
The transactions that the programmer used to test the program
A test data generator program, which automatically prepares test data based on program specifications
In a batch processing system, the company’s program and a copy of relevant files are used to process the test data.
Results are compared with the predetermined correct output.
Discrepancies indicate processing errors or control deficiencies that should be investigated.
In an online system, auditors enter test data using a data entry device, such as a PC or terminal.
The auditor observes and logs the system’s response.
If the system accepts erroneous or invalid test transactions, the auditor reverses the effects of the transactions, investigates the problem, and corrects the deficiency.
Although processing test transactions is usually effective, it has the following disadvantages:
The auditor must spend considerable time understanding the system and preparing an adequate set of test transactions.
Care must be taken to ensure test data do not affect the company’s files and databases.
The auditor can reverse the effects of the test transactions or process them in a separate run, using a copy of the file or database.
Reversal procedures may reveal the existence and nature of the auditor’s test to key personnel.
A separate run removes some of the authenticity
Concurrent Audit Techniques
Millions of dollars of transactions can be processed in an online system without leaving a satisfactory audit trail.
In such cases, evidence gathered after data processing is insufficient for audit purposes.
Also, because many online systems process transactions continuously, it is difficult or impossible to stop the system to perform audit tests.
Consequently, auditors use concurrent audit techniques to continually monitor the system and collect audit evidence while live data are processed during regular operating hours.
Concurrent audit techniques use embedded audit modules.
These are segments of program code that:
Perform audit functions;
Report test results to the auditor; and
Store collected evidence for auditor review.
Are time-consuming and difficult to use, but less so if incorporated when programs are developed.
Auditors commonly use five concurrent audit techniques:
(1) An integrated test facility (ITF) technique
May represent a fictitious division, department, office, customer, or supplier.
Processing test transactions to update these dummy records will not affect actual records.
Because real and fictitious transactions are processed together, company employees don’t know the testing is taking place.
The system must:
Distinguish ITF from actual records;
Collect information on the effects of test transactions;
Report the results.
The auditor compares processing with expected results to verify system and controls are operating correctly.
In a batch processing system, the ITF technique
Eliminates the need to reverse test transactions
Is easily concealed from operating employees because test transactions don’t need to be reversed.
In online processing systems, test transactions can be:
Submitted on a frequent basis
Processed with actual transactions
Traced through every processing stage
Can all be accomplished without disrupting regular processing operations.
Care must be taken not to include dummy records in the reporting process.
(2) A snapshot technique - examines the way transactions are processed
Selected transactions are marked with a special code that triggers the snapshot process.
Audit modules in the program record these transactions and their master file records before and after processing.
The selected data are recorded in a special file and reviewed by the auditor to verify that all processing steps were properly executed.
(3) A system control audit review file (SCARF) - uses embedded audit modules to continuously monitor transaction activity and collect data on transactions with special audit significance.
Data recorded in a SCARF file or audit log include transactions that:
Exceed a specified dollar limit;
Involve inactive accounts;
Deviate from company policy; or
Contain write-downs of asset values.
Periodically the auditor:
Receives a printout of SCARF transactions;
Looks for questionable transactions among them; and
Investigates.
(4) Audit hooks - are audit routines that flag suspicious transactions.
• Example: State Farm Life Insurance looking for policyholders who change their name or address and then subsequently withdraw funds.
When audit hooks are used, auditors can be informed of questionable transactions as they occur via real-time notification, which displays a message on the auditor’s terminal.
(5) Continuous and intermittent simulation (CIS) - embeds an audit module in a database management system.
The module examines all transactions that update the Database Management System (DBMS) using criteria like those of SCARF.
When a transaction has audit significance, the module:
Processes the data independently (similar to parallel simulation);
Records the results;
Compares results with those obtained by the DBMS.
If there are discrepancies, details are written to an audit log for subsequent investigation.
Serious discrepancies may prevent the DBMS from executing the update.
Analysis of Program Logic
If an auditor suspects that a particular program contains unauthorized code or serious errors, a detailed analysis of the program logic may be necessary.
Done only as a last resort because:
It’s time-consuming
Requires programming language proficiency
To perform the analysis, auditors' reference:
Program flowcharts
Program documentation
Program source code.
The following software packages can help:
Automated Flowcharting programs
Interpret program source code and generate a corresponding flowchart.
Automated Decision Table Program
Generate a decision table that represent s a program logic.
Scanning Routines
Search programs for specified variable names or character combinations.
Mapping Programs
Identify unexecuted program code.
Program Tracing
Sequentially prints all programs steps executed during a program run.
This list is intermingled with regular output of auditors can observe the precise sequence of events that unfold during program execution.
Helps the auditor detect:
Unauthorized program instructions
Incorrect logic paths
Unexecuted program code
Types of Error and Fraud
Fail to detect erroneous input
Improperly correct input errors
Process erroneous input
Improperly Distribute or disclose output
Control Procedures
Computer data editing routines
Proper use of internal and external file labels
Reconciliation of batch totals
Effective error correction procedures
Understandable operating documentation and run manuals
Competent supervision of computer operations
Effective handling of data input and output by data control personnel
File change listings and summaries prepared for user department review
Maintenance of proper environmental conditions in computer facility
Audit Process: Systems Review
Review administrative documentation for processing control standards
Review systems documentation for data editing and other processing controls
Review operating documentation for completeness and clarity
Review copies of error listings, batch total reports, and file change lists
Observe computer operations and data control functions
Discuss processing and output controls with operations and IS supervisory personnel
Audit Procedures: Test of Controls
Evaluate adequacy of processing control standards and procedures
Evaluate adequacy and completeness of data editing controls
Verify adherence to processing control procedures by observing computer operations and the data control function
Verify that selected application system output is properly distributed
Reconcile a sample batch totals, and follow up on discrepancies
Trace disposition of a sample of errors flagged by data edit routines to ensure proper handling
Verify processing accuracy for a sample of sensitive transactions
Verify processing accuracy for selected computer-generated transactions
Search for erroneous or unauthorized code via analysis of program logic
Check accuracy and completeness of processing controls using test data
Monitor online processing systems using concurrent audit techniques
Recreate selected reports to test for adequacy and completeness
Compensating Controls
- Auditors must periodically reevaluate processing controls to ensure their continued
reliability.
If controls are unsatisfactory, user and source data controls may be strong enough to compensate.
If not, a material weakness exists, and steps should be taken to eliminate the control deficiencies.
The purpose of the preceding audit procedures is to gain an understanding of the controls, evaluate its adequacy, and observe operations for evidence that the controls are in use.
Several specialized techniques allow the auditor to use the computer to test processing controls:
Processing test data
Using concurrent audit techniques
Analyzing program logic
Each has its own advantages and disadvantages:
Appropriateness of each technique depends on the situation
No one technique is good for all circumstances
Auditors should not disclose which technique they use.
Processing Test Data
Involves testing a program by processing a hypothetical series of valid and invalid transactions.
The program should:
Process all the valid transactions correctly
Identify and reject the invalid ones
All logic paths should be checked for proper functioning by one or more test transactions, including:
Records with missing data
Fields containing unreasonably large amounts
Invalid amount numbers or processing codes
Non-numeric data in numeric fields
Records out of sequence
The following resources are helpful when preparing test data:
A listing of actual transactions
The transactions that the programmer used to test the program
A test data generator program, which automatically prepares test data based on program specifications
In a batch processing system, the company’s program and a copy of relevant files are used to process the test data.
Results are compared with the predetermined correct output.
Discrepancies indicate processing errors or control deficiencies that should be investigated.
In an online system, auditors enter test data using a data entry device, such as a PC or terminal.
The auditor observes and logs the system’s response.
If the system accepts erroneous or invalid test transactions, the auditor reverses the effects of the transactions, investigates the problem, and corrects the deficiency.
Although processing test transactions is usually effective, it has the following disadvantages:
The auditor must spend considerable time understanding the system and preparing an adequate set of test transactions.
Care must be taken to ensure test data do not affect the company’s files and databases.
The auditor can reverse the effects of the test transactions or process them in a separate run, using a copy of the file or database.
Reversal procedures may reveal the existence and nature of the auditor’s test to key personnel.
A separate run removes some of the authenticity
Concurrent Audit Techniques
Millions of dollars of transactions can be processed in an online system without leaving a satisfactory audit trail.
In such cases, evidence gathered after data processing is insufficient for audit purposes.
Also, because many online systems process transactions continuously, it is difficult or impossible to stop the system to perform audit tests.
Consequently, auditors use concurrent audit techniques to continually monitor the system and collect audit evidence while live data are processed during regular operating hours.
Concurrent audit techniques use embedded audit modules.
These are segments of program code that:
Perform audit functions;
Report test results to the auditor; and
Store collected evidence for auditor review.
Are time-consuming and difficult to use, but less so if incorporated when programs are developed.
Auditors commonly use five concurrent audit techniques:
(1) An integrated test facility (ITF) technique
May represent a fictitious division, department, office, customer, or supplier.
Processing test transactions to update these dummy records will not affect actual records.
Because real and fictitious transactions are processed together, company employees don’t know the testing is taking place.
The system must:
Distinguish ITF from actual records;
Collect information on the effects of test transactions;
Report the results.
The auditor compares processing with expected results to verify system and controls are operating correctly.
In a batch processing system, the ITF technique
Eliminates the need to reverse test transactions
Is easily concealed from operating employees because test transactions don’t need to be reversed.
In online processing systems, test transactions can be:
Submitted on a frequent basis
Processed with actual transactions
Traced through every processing stage
Can all be accomplished without disrupting regular processing operations.
Care must be taken not to include dummy records in the reporting process.
(2) A snapshot technique - examines the way transactions are processed
Selected transactions are marked with a special code that triggers the snapshot process.
Audit modules in the program record these transactions and their master file records before and after processing.
The selected data are recorded in a special file and reviewed by the auditor to verify that all processing steps were properly executed.
(3) A system control audit review file (SCARF) - uses embedded audit modules to continuously monitor transaction activity and collect data on transactions with special audit significance.
Data recorded in a SCARF file or audit log include transactions that:
Exceed a specified dollar limit;
Involve inactive accounts;
Deviate from company policy; or
Contain write-downs of asset values.
Periodically the auditor:
Receives a printout of SCARF transactions;
Looks for questionable transactions among them; and
Investigates.
(4) Audit hooks - are audit routines that flag suspicious transactions.
• Example: State Farm Life Insurance looking for policyholders who change their name or address and then subsequently withdraw funds.
When audit hooks are used, auditors can be informed of questionable transactions as they occur via real-time notification, which displays a message on the auditor’s terminal.
(5) Continuous and intermittent simulation (CIS) - embeds an audit module in a database management system.
The module examines all transactions that update the Database Management System (DBMS) using criteria like those of SCARF.
When a transaction has audit significance, the module:
Processes the data independently (similar to parallel simulation);
Records the results;
Compares results with those obtained by the DBMS.
If there are discrepancies, details are written to an audit log for subsequent investigation.
Serious discrepancies may prevent the DBMS from executing the update.
Analysis of Program Logic
If an auditor suspects that a particular program contains unauthorized code or serious errors, a detailed analysis of the program logic may be necessary.
Done only as a last resort because:
It’s time-consuming
Requires programming language proficiency
To perform the analysis, auditors' reference:
Program flowcharts
Program documentation
Program source code.
The following software packages can help:
Automated Flowcharting programs
Interpret program source code and generate a corresponding flowchart.
Automated Decision Table Program
Generate a decision table that represent s a program logic.
Scanning Routines
Search programs for specified variable names or character combinations.
Mapping Programs
Identify unexecuted program code.
Program Tracing
Sequentially prints all programs steps executed during a program run.
This list is intermingled with regular output of auditors can observe the precise sequence of events that unfold during program execution.
Helps the auditor detect:
Unauthorized program instructions
Incorrect logic paths
Unexecuted program code