Internal control has always been important. However, passage of the Sarbanes-Oxley Act of 2002 by the U.S. Congress increased management’s awareness of this importance. Under this law, both the CEO and CFO must personally certify the adequacy of their organization’s system of internal control. An improper certification may result in criminal or civil charges against the certifier.
This chapter focuses on the internal controls within software systems. It is important for the tester to know that there are two general categories of controls: environmental (or general) controls, and controls within a specific business application (internal controls). This chapter covers three types of controls in the latter category (specific business application controls): preventive, detective, and corrective. The chapter then explains how to evaluate controls within an information system.
There are two systems in every business application: the system that processes transactions and the system that controls the processing of such (see Figure 17-1). From the perspective of the system designer, these two are designed and implemented as one system. For example, edits that determine the validity of input are included in the part of the system in which transactions are entered. However, those edits are part of the system that controls the processing of business transactions.
Because these two systems are designed as a single system, most software testers do not conceptualize the two systems. Furthermore, the system documentation is not divided into the system that processes transactions and the system that controls the processing of transactions.
When you visualize a single system, you may have difficulty visualizing the total system of internal control. If you look at edits of input data by themselves, it is difficult to see how the totality of control over the processing of a transaction is accomplished. Thus, you are at risk of processing invalid transactions. This risk occurs throughout the system, not just during data editing. A system of internal controls must address all the risk of invalid processing from the point that a transaction is entered into the system to the point that the output is used for business purposes.
The following three terms are associated with an undesirable occurrence during processing:
Risk. The probability that an undesirable event will occur
Exposure. The amount of loss that might occur if an undesirable event occurs
Threat. A specific event that might cause an undesirable event to occur
Controls are required to mitigate risks, exposure, and the specific threats that might cause loss. Therefore, to evaluate the adequacy of internal controls, testers must know the risks, exposures, and threats associated with the business application being tested. The objective of a system of internal controls in a business application is to minimize business risks.
As mentioned previously, one category of control is environmental controls. Such a system refers to the management-established and -maintained environment. Environmental (or general) controls are the means by which management manages the organization, including organizational policies and structures, hiring practices, training programs, supervisory/evaluation functions, and the day-to-day employee work processes, such as a system development methodology for building software systems.
Without strong environmental controls, transaction-processing (internal) controls may not be effective. For example, if passwords to access computer systems are not adequately protected, the password system will not work. Individuals will either protect or not protect their password based on environmental controls such as the attention management pays to password protection, the monitoring of the use of passwords, and management’s actions regarding failure to protect passwords.
Internal application controls are designed to meet the specific control requirements of each processing application. They contrast with and are complemented by environmental controls applicable where the processing occurs. Application controls are designed to ensure that the recording, classifying, and summarizing of authorized transactions and the updating of master files will produce accurate and complete information on a timely basis.
Normally, the processing cycle includes all the procedures in the source and user departments and in the IT departments to record and prepare source data and ultimately produce useful information during a specific time period. When you discuss application controls, it is useful to classify them according to whether they are preventive, detective, or corrective.
Note
Some input errors may be acceptable if they do not cause an interruption in the processing run—for example, a misspelling. When deciding tolerance limits, an organization must compare the cost of correcting an error to the consequences of accepting it. Such tradeoffs must be determined for each application. Unfortunately, however, no universal guidelines are available.
Controls typically are classified according to the location of their implementation: input, process, and output. However, the location of controls is not important to their evaluation. The auditor’s prime concern should be the objective of a control.
The objectives of internal application controls are to prevent, detect, or correct the various causes (assumed to always exist) of risk exposure, as follows:
To ensure that all authorized transactions are completely processed once and only once
To ensure that transaction data are complete and accurate
To ensure that transaction processing is correct and appropriate to the circumstances
To ensure that processing results are utilized for the intended benefits
To ensure that the application can continue to function
In most instances, controls can be related to multiple exposures. A single control can also fulfill multiple objectives. For these reasons, internal application controls are classified according to whether they prevent, detect, or correct causes of exposure. The following subsections describe these types of controls, using key controls as examples (instead of trying to present an exhaustive list).
Preventive controls are the most desirable (cost-effective, and from a PR perspective) controls because they stop problems from occurring. Therefore, application designers should focus on preventive controls. Preventive controls include standards, training, segregation of duties, authorization, forms design, prenumbered forms, documentation, passwords, consistency of operations, etc.
You might ask, “At what point in the processing flow is it most desirable to exercise computer data edits?” Computer data edits are one example of preventive control, and the answer to this question is this: “As soon as possible, to uncover problems early and avoid unnecessary computer processing.” Some input controls depend on access to master files and so must be timed to coincide with file availability. However, many input-validation tests may be performed independently of the master files. Preferably, these tests should be performed in a separate edit run at the beginning of the processing. Normally, the input-validation tests are included in programs to perform data-conversion operations such as scanning data into the computer. If these tests are included in programs performing such operations, the controls may be used without significantly increasing the computer run time.
Preventive controls are located throughout the entire IT system. Many of these controls are executed prior to the data entering the computer programs. This section discusses the following preventive controls:
Source-data authorization
Data input
Source-data preparation
Turnaround documents
Prenumbered forms
Input validation
File auto-updating
Processing controls
After data have been recorded properly, there should be control techniques to ensure that the source data have been authorized. Typically, authorization should be given for source data such as credit terms, prices, discounts, commission rates, overtime hours, and so forth.
The input documents, where possible, should have evidence of authorization and should be reviewed by the internal control group in data processing. To the extent practical, the computer should be utilized as much as possible to authorize input. This may be done through programmed controls.
Data input is the process of converting data from non-machine-readable form (such as hard-copy source documents) into a machine-readable form so that the computer can update files with the transactions. Because the data-input process is typically a manual operation, control is needed to ensure that the data input has been performed accurately.
In many automated systems, conventional source documents are still used and, therefore, no new control problems are presented prior to the conversion of source documents into machine-readable form. Specially designed forms promote the accuracy of the initial recording of the data. A pre-audit of the source documents by knowledgeable personnel to detect misspellings, invalid codes, unreasonable amounts, and other improper data helps to promote the accuracy of input preparation.
In IT systems where the source document is eliminated or is in a form that does not permit human review, control over source-data preparation should be such that access to, and use of, the recording and transmitting equipment is properly controlled to exclude unauthorized or improper use.
Other control techniques to promote the accuracy of input preparation include the use of turnaround documents, which are designed to eliminate all or part of the data to be recorded at the source. A good example of a turnaround document is a bill from an oil company. Normally, the bill has two parts: one part is torn off and included with the remittance you send back to the oil company as payment for your bill; the other you keep for your records. The part you send back normally includes prerecorded data for your account number and the amount billed so that this returned part can be used as the input medium for computer processing of the cash receipts for the oil company.
Sequential numbering of the input transaction form with full accountability at the point of document origin is another traditional control technique. This can be accomplished either by using prenumbered forms or by having the computer issue sequential numbers.
An important segment of input processing is the validation of the input itself. This is an extremely important process because it is really the last point in the input preparation where errors can be detected before files are updated. The primary control techniques used to validate the data are associated with the editing capabilities of the computer. Based on the characteristics of the computer, an IT system has unique capabilities to examine or edit each element of information processed by it. This editing involves the ability to inspect and accept (or reject) transactions according to validity or reasonableness of quantities, amounts, codes, and other data contained in input records. The editing ability of the computer can be used to detect errors in input preparation that have not been detected by other control techniques discussed previously.
The editing ability of the computer is achieved by installing checks in the program of instructions—hence, the term “program checks.” They include the following:
Validity tests. Validity tests are used to ensure that transactions contain valid transaction codes, characters, and field sizes. For example, in an accounts receivable system, if only PB through PL are valid transaction codes for input, then input with other codes is rejected by the computer. In a labor data collection system, all time transactions and job transactions could be checked by the computer against the random-access file of active job numbers, and nonmatches indicated on a report could be brought to the attention of the shop foreman.
Completeness tests. Completeness checks are made to ensure that the input has the prescribed amount of data in all data fields. For example, a payroll application requires that each new employee have data in all the fields in the input screen be valid data. A check may also be included to see that all characters in a field are either numeric or alphabetic.
Logical tests. Logical checks are used in transactions where various portions, or fields, of the record bear some logical relationship to one another. A computer program can check these logical relationships to reject combinations that are erroneous even though the individual values are acceptable.
Limit tests. Limit tests are used to test record fields to see whether certain predetermined limits have been exceeded. Generally, reasonable time, price, and volume conditions can be associated with a business event. For example, on one payroll application, the computer is programmed to reject all payroll rate changes greater than 15 percent of the old rate. The Hours field is checked to see whether the number of hours worked exceeds 44. In another application, an exception report is generated when a customer’s balance plus the total of his unfilled orders exceeds his credit limit.
Self-checking digits. Self-checking digits are used to ensure the accuracy of identification numbers such as account numbers. A check digit is determined by performing some arithmetic operation on the identification number itself. The arithmetic operation is formed in such a way that typical errors encountered in transcribing a number (such as transferring two digits) will be detected.
Control totals. Control totals are used to ensure that data is complete and/or correct. For example, a control total could indicate the number of active employees to be paid and the accumulated net pay for a weekly payroll.
The updating phase of the processing cycle is the auto-updating (via computer) of files with the validated transactions. Typically, auto-updating involves sequencing transactions, comparing transaction records with master-file records, performing computations, and manipulating and reformatting data for the purpose of updating master files and producing output data for distribution to user departments for subsequent computerized processing.
The accuracy of file updates depends on controls to ensure the programming, hardware checks designed and built in to the equipment by the manufacturer, and programmed controls included in the computer programs themselves.
Another control technique for the proper updating of files is file maintenance. File maintenance consists of the procedures involved in making changes to the permanent information contained in master files, such as an employee’s name, address, employee number, and pay rate. Because these data are so important to the proper computerized processing of files, formalized procedures are required to make changes to this type of permanent information. All master-file changes should be authorized in writing by the department initiating the change. A notice or register of all changes should be furnished to the initiating department to verify that the changes were made.
As discussed previously, programmed controls are an important part of application control. Programmed controls on the auto-updating of files are also important because they are designed to detect data loss, check mathematical computations, and ensure the proper posting of transactions. Programmed checks to detect data loss or incorrect processing include record counts, control totals, and has totals:
Record count. A record count is the number of records a computer processes, which can then be compared with a predetermined count. Typically, a record count is established when the file is assembled, and the record count is carried as a control total at the end of the file and adjusted whenever records are added or deleted. For example, a record count may be established for all new hires or fires processed. This record count can then be compared internally (if a control card is included with the input transactions) or manually to predetermined totals of new hires or fires. Each time the file is processed, the records are recounted and the quantity is balanced to the original or adjusted total. Although the record count is useful as a proof of processing accuracy, it is difficult to determine the cause of error if the counts are out of balance.
Control total. A control total is made from amount or quantity fields in a group of records and is used to check against a control established in previous or subsequent manual or computer processing.
Has total. A has total is another form of control total made from data in a non-quantity field (such as vendor number or customer number) in a group of records.
Programmed checks of mathematical calculations include limit checks, cross-footing balance checks, and overflow tests.
Some calculations produce illogical results, such as million-dollar payroll checks or negative-amount payroll checks. Such calculations can be highlighted in exception reports with the use of limit checks, which test the results of a calculation against predetermined limits. For example, a payroll system may include limit checks to exclude from machine payroll check preparation all employees with payroll amounts greater than $500 or less than $0.
Cross-footing balance checks can be programmed so that totals can be printed and compared manually or internally during processing. For example, the computer-audit program is used in testing accounts receivable and in selecting accounts for confirmation. Each account is aged according to the following categories: current, 30, 60, and 90 days. The aged amounts for each account are temporarily stored in accumulators in the central processing unit. When all open items for the account have been aged, the aged totals for the account are compared to the account balance stored elsewhere in the central processing unit. Any difference results in an error. The program also includes for all accounts the accumulation and printout of aged amounts for manual comparison with the total accounts receivable balance.
The overflow test is widely used to determine whether the size of a result of a computation exceeds the registered size allocated to hold it. If so, there must be a means of saving the overflow portion of the results that otherwise would be lost. Overflow control may be programmed or may be available as a hardware or software control provided by the equipment manufacturer.
Programmed checks for proper postings may be classified as file checks. Basically, these are controls used to ensure that the correct files and records are processed together. The problem of using the correct file is significant in IT systems because of the absence of visible records and because of the ease with which wrong data can be stored electronically. The increase in the size and complexity of modern data processing systems has resulted in the growth of large system libraries containing data that can cost thousands of dollars to generate. For the purpose of preserving the integrity of data, various labeling techniques have been devised to provide maximum protection for a file to prevent accidental destruction or erasure and to ensure proper posting, updating, and maintenance. Two types of labels are used, external and internal. (External labels are a physical safeguard that properly falls under the category of documentation and operating practices. They are attached to the exterior of data processing media.)
Detective controls alert individuals involved in a process of a problem so that action can be taken. One example of a detective control is a listing of all paychecks for individuals who worked more than 80 hours in a week. Such a transaction may be correct, or it may be a systems error, or even fraud.
Detective controls will not prevent problems from occurring, but rather will point out a problem once it has occurred. Examples of detective controls include batch control documents, batch serial numbers, clearing accounts, labeling, and so forth.
This section discusses the following detective controls:
Data transmission
Control register
Control totals
Documentation and testing
Output checks
After the source data have been prepared, properly authorized, and converted to machine-processable form, the data usually are transmitted from the source department to the data processing center. Data transmission can be made by conventional means (such as messenger and mail) or by data transmission devices that allow data transmission from remote locations on a timelier basis.
One important control technique in data transmission is batching, the grouping of a large number of transactions into small groups. Batching typically is related more to sequential-processing systems where transactions have to be put into the same order as the master files; however, batching may also apply to many direct-access systems where it may be desirable to batch input for control purposes.
Let us consider a payroll example as an illustration of batching. The source document may include time cards (source-data preparation), which should have been approved by a foreman (data authorization). For batching, these data time cards could be divided into groups of 25, with a control total for hours worked developed for each batch along with the total for all batches. Each batch transaction and its control totals could then be sent (data transmission) to the internal control group in the IT department for reconciliation with the batch control totals. Thus, batching and controls totals are useful techniques for the control of both data conversion and data transmission. These control totals could also be used during the computer processing phase during which the payroll files would be updated (as discussed later in this chapter).
Control totals should be developed on important fields of data on each record to ensure that all records have been transmitted properly from the source to the data processing center. Controls might be developed on the number of records in each batch or could be based on some quantitative field of data such as invoice amount or hours worked, and so on. Such controls serve as a check on the completeness of the transaction being processed and ensure that all transactions have been received in the data processing center.
Another technique to ensure the transmission of data is the recording of control totals in a control log so that the input processing control group can reconcile the input controls with any control totals generated in subsequent computer processing.
Control totals are normally obtained from batches of input data. These control totals are prepared manually, prior to processing, and are then incorporated as input to the computer processing phase. The computer can be programmed to accumulate control totals internally and make a comparison with those provided as input. A message confirming the comparison should be printed out, even if the comparison did not disclose an error. These messages are then reviewed by the internal processing control group.
Accuracy of programming is ensured by properly documenting and extensively testing program procedures. Good documentation aids in locating programming errors and facilitates correction even in the absence of the original designer or programmer. Extensive program test procedures under real-life conditions, testing all possible exceptions without actual programmer involvement, minimizes the possibilities of hidden program bugs and facilitates the smooth running of the system.
The output checks consist of procedures and control techniques to do the following:
Reconcile output data, particularly control totals, with previously established control totals developed in the input phase of the processing cycle
Review output data for reasonableness and proper format
Control input data rejected by the computer during processing and distribute the rejected data to appropriate personnel
Distribute output reports to user departments on a timely basis
Proper input controls and file-updating controls should give a high degree of assurance that the computer output generated by the processing is correct. However, it is still useful to have certain output controls to achieve the control objectives associated with the processing cycle. Basically, the function of output controls is to determine that the processing does not include any unauthorized alterations by the computer operations section and that the data are substantially correct and reasonable. The most basic output control is the comparison of control totals on the final output with original input control totals such as record counts or financial totals. Systematic sampling of individual items affords another output control. The testing can be done by the originating group or the control group.
One of the biggest controls in any system occurs when the originating group reviews reports and output data and takes corrective action. Review normally consists of a search for unusual or abnormal items. The programmed controls discussed previously, coupled with exception reporting, actually enhance the ability of responsible personnel to take necessary corrective action.
Another form of output control in some organizations is the periodic and systematic review of reports and output data by an internal audit staff. This group normally has the responsibility to evaluate operating activities of the company, including computer operations, to determine that internal policies and procedures are being followed.
Corrective controls assist in the investigation and correction of causes of exposures that have been detected. These controls primarily collect evidence that can be used to determine why a particular problem has occurred. Corrective action is often a difficult and time-consuming process; however, it is important because it is the prime means of isolating system problems. Many systems improvements are initiated by individuals taking corrective actions on problems.
Note that the corrective process itself is subject to error. Many major problems have occurred in organizations because corrective action was not taken on detected problems. Therefore, detective control should be applied to corrective controls.
Examples of corrective controls are audit trails, discrepancy reports, error statistics, backup and recovery, and so on. This section discusses two corrective controls: error detection and resubmission, and audit trails.
Until now we have talked about data control techniques designed to screen the incoming data to reject any transactions that do not appear valid, reasonable, complete, and so on. We also must deal with these errors upon detection. We must establish specific control techniques to ensure that all corrections are made to the transactions in error and that these corrected transactions are reentered into the system. Such control techniques should include the following:
Having the control group enter all data rejected from the processing cycle in an error log by marking off corrections in this log when these transactions are reentered; open items should be investigated periodically.
Preparing an error input record or report explaining the reason for each rejected item. This error report should be returned to the source department for correction and resubmission. This means that the personnel in the originating or source department should have instructions on the handling of any errors that might occur.
Submitting the corrected transactions through the same error detection and input validation process as the original transaction.
Another important aspect of the processing cycle is the audit trail. The audit trail consists of documents, journals, ledgers, and worksheets that enable an interested party (for example, the auditor) to trail an original transaction forward to a summarized total or from a summarized total backward to the original transaction. Only in this way can he determine whether the summary accurately reflects the business’s transactions.
In information systems, a cost is associated with each control. Because no control should cost more than the potential errors it is established to detect, prevent, or correct, the cost of controls must be evaluated. As part of that evaluation, remember that the extent to which controls are poorly designed or excessive, they become burdensome and may not be used. This failure to use controls is a key element leading to major exposures.
Preventive controls are generally the lowest in cost. Detective controls usually require some moderate operating expense. On the other hand, corrective controls are almost always quite expensive. Prior to installing any control, some cost/benefit analysis should be done.
Controls need to be reviewed continually. This is a prime function of the auditor, who should determine whether controls are effective. As the result of such a review, an auditor will recommend adding, eliminating, or modifying system controls.
If software testers perform tests to evaluate the adequacy of a system of internal controls, the work of internal auditors is lessened. The internal auditors would be able to rely on the work performed by the software testers. However, it is recommended that software testers confine their tests to identifying strengths and weaknesses of internal controls. The identified weaknesses can form the basis of improving the system of controls within an application system.
Figure 17-2 illustrates the workbench for assessing internal controls.
Testing the adequacy of a system of internal controls begins with a tester understanding the objectives and implementation of an application system. When preparing for any type of test of an application system, the tester needs this background information on the application system. The background information can be obtained in two ways:
Study the system documentation. The documentation from the user area about the application system, as well as the documentation prepared by the system development team, provides information on the application system. This documentation will not only help the tester understand the system but will also be an important component in performing Task 3, which is a review of the application system controls.
Interview the application system stakeholders. The tester may want to talk to various individuals/groups that have a stake in the processing of the application system. The types of people interviewed may include the following:
Customer personnel. Those who have requested the info system for their processing purposes.
System users. Those individuals who will use the system to perform their day-to-day responsibilities
Control personnel. Those that have the responsibility to ensure that the application system is under control and, if not, to take appropriate action.
Internal auditors. If the organization’s internal auditors have reviewed the application system in the user area, they have knowledge that would help the tester determine the types of tests to perform.
Work Paper 17-1 is an application internal-control questionnaire. Section A of this questionnaire defines a minimum acceptable level of documentation for the tester to understand the application system using system documentation.
Table 17-1. Internal Control Questionnaire
QUESTION | YES | NO | COMMENTS | |
A. | Documentation | |||
Documentation consists of work papers and records that describe the system and procedures for performing a processing task. It is the basic means of communicating the essential elements of the data processing system and the logic followed by the computer programs. Preparing adequate documentation is a necessary, although frequently neglected, phase of data processing. A lack of documentation indicates a serious weakness within the management control over a data processing installation. | ||||
| ||||
B. | Input Controls | |||
Input controls are designed to authenticate the contents of source documents and to check the conversion of this information into machine-readable formats or media. Typically, these controls will not be designed to detect 100 percent of all input errors because such an effort would be either too costly or physically impractical. Therefore, an economic balance must be maintained between the cost of error detection and the economic impact of an undetected error. This should be considered when evaluating input control. Judgment must be used when identifying essential information, the accuracy of which must be verified. The following questions can also be used to evaluate internal control practices: | ||||
| ||||
C. | Program and Processing Controls | |||
Programs should be written to take the maximum advantage of the computer’s ability to perform logical testing operations. In many cases, tests that could be employed are not used because the programmer does not know the logical limits of the data to be processed. | ||||
| ||||
D. | Output Control | |||
Output control is generally a process of checking whether the operation of input control and program and processing controls has produced the proper result. The following questions should be answered regarding all controls in effect: | ||||
| ||||
E. | File Control | |||
Because data files can be destroyed by careless handling or improper processing, proper file control is vital in all data processing installations. | ||||
|
Ideally, system documentation includes the application system risks. This is normally a component of the process system developers use to help define requirements. If the system developers have not done this, those assigned testing responsibilities for the application system should have completed a risk-assessment activity. The seven-step software-testing process presented earlier in this book provides a methodology for identifying application system risks.
These risks become the requirements for designing controls. First the risk must be identified, and then the exposure estimated and the threats identified. When you know the exposure and threats, a decision can be made as to the importance of controlling the risk. For example, if the risk is minor (for example, $100 or less), no controls may be needed. On the other hand, if the risk is high, in the hundreds of thousands of dollars, significant strong controls are needed.
Testers should not make decisions about whether a specific risk requires controls. That is the responsibility of the customer/user of the application system. However, if the customer/users have not determined whether controls are needed, and estimated the strength of controls that might be needed, testers should merely identify this as a weakness in the system of internal controls. It would not be necessary for the testers to estimate the exposure, but rather just indicate a specific risk that has not been controlled through the application system’s internal controls.
A detailed review of the system should encompass an understanding of both the details of the processing and the major controls over the major phases of the application (namely, input, processing, and output). A useful starting point to enable the tester to determine the details of processing is the review of the system’s documentation, such as systems flowcharts, narrative description, and record layouts of transactions being processed and the master files being updated. The review of the system’s documentation should be followed by interviews with user and system personnel about the specific control aspects of the application. Work Paper 17-1 provides questions that the tester should ask when reviewing a specific application. The tester should be involved in reviewing documentation for the specific application to determine the nature of the input controls, processing controls, output controls, and file controls (types of controls discussed earlier in this chapter).
After the tester has reviewed the system documentation and has interviewed relevant IT and user personnel, the tester should have a pretty good understanding of the nature of the specific application and the types of controls included. The information obtained through the initial review of the system should then be supplemented by tracing different types of transactions through the system. The tracing of transactions is designed to establish the existence of system procedures and to confirm the tester’s understanding of the system obtained through discussions with responsible personnel and through the review of systems documentation.
The tester may be able to test the system in a non–computer-processing way; in other situations, it may be desirable, if not necessary, to test with the use of computer processing.
If the processing application being evaluated is well documented and a visible audit trail exists, the tester may test the existence and effectiveness of the client’s controls and processing procedures by checking source data, control reports, error listings, transaction registers, and management reports. The tester, in effect, views the computer program as a black box and makes an inference about what goes on in the program by looking at known input (source documents) and known output (i.e., error listings or transaction registers).
Testing without using computer processing or by using conventional source documents and printed outputs is a process quite familiar to testers and requires no further discussion.
When testing the applications system, dynamic testing is used primarily to obtain information about the operation of the application and the programmed controls. Basically, there are two ways to test a system with the computer: the test-data approach and the mini-company approach.
The test-data approach is one of the methods available to the tester to evaluate computer-based systems. This approach is primarily used to obtain information about the operation of the computer program or set of programs in an application and about the program controls.
The test-data method is probably most applicable when:
A significant part of the system of internal control is embodied in the computer program.
There are gaps in the audit trail making it difficult or impractical to trace input to output or to verify calculations.
The volume of records is so large that it may be more economical and more effective to use test-data methods instead of manual testing methods.
Because most accounting and financial processing systems involve the updating of records, the use of test data usually involves the use of master records. So, as Figure 17-3 suggests, the sample transactions processed with master records determine how the computer system and programmed controls update the master files and generate output.
As the diagram indicates, the tester, with an understanding of how the computer program (including the programmed controls) should operate, develops predetermined processing results that he compares to the actual results from his testing process. Based on the comparison of actual results to predetermined results, he makes some conclusions about the effectiveness and existence of the system and programmed controls.
The inherent advantage of creating test transactions over selecting actual transactions is that the tester may include representative types of transactions in his tests with relative ease. Conventionally, to test the system, the tester selects actual accounting transactions previously processed by the client. Typically, this approach calls for tracing several transactions from the recording of the source documents, through whatever intermediate records might exist, to the output reports or records produced. Often this approach is incomplete and inexact, and the transactions do not include the ones requiring exception handling. By creating transactions, the tester can process data that are truly representative and that can include any type of transactions.
By several methods, the tester can determine the types of transactions to be included in his test data. One approach is to analyze the data used to test the computer programs. Much of such test data tests the processing steps and controls that the tester is interested in. Such a method is the most expedient because many transactions can be devised by mere duplication or slight modification of the system test data. This method has the added advantage of reviewing the system procedures in testing. Such a review might prove highly informative and beneficial to user/personnel by uncovering outdated tests and areas in the program not being tested at all. Another and more time-consuming way to determine the types of transactions to include in the test data involves analyzing the input records and creating simulated transactions in accordance with the test objectives. Typically, a combination of the two approaches is necessary to include all the transactions that the tester is interested in processing.
Regardless of the approach used to determine the types of transactions to be processed, several observations should be made. All possible combinations within all data fields need not be set out as separate transactions. Distinguish between data fields that merely represent identification data (that is, account numbers, social security numbers) and those that involve invariable data. In the case of the former, only a limited number of possibilities needs be included to test the identification routines in the program. For example, to test sequence checking and identification comparison routines, a transaction with a valid transaction code and employee number and containing valid information could be placed out of sequence in the test deck. Additional tests for sequence checking and identification comparison would not be necessary. Not all combinations within variable data fields need testing either.
The tests should include transactions that determine the processing and handling of the following general conditions:
Valid conditions
Out-of-sequence conditions
Out-of-limits conditions
Routines arising from a major decision point where alternative processing takes place as a result of comparing transaction records with master records (that is, where the transaction identification number can be greater, equal to, or less than the identification number on the master record)
Units of measure differences (that is, tons instead of pounds)
Incomplete, invalid, or missing input information
Wrong master and/or transaction files
Numeric characters in fields where alphabetic characters belong and vice versa
Characters in certain fields that exceed prescribed length (an overflow condition)
Illogical conditions in data fields where programmed consistency checks test the logical relationship between the fields
Conditions where transaction codes or amounts do not match the codes or amounts established in tables stored in internal memory
Obviously, all these conditions cannot be tested with each type of transaction, but the majority of them may be tested in processing all transactions included in the test data.
Obtaining master records. The tester must obtain master records with which to process the test transactions. The contents of the master records must also be available in visible form to compute the predetermined results for comparison with output resulting from the processing of test data.
Although actual master records may be readily obtained in many systems, getting the same records in printed form without advance planning is difficult. One method is to time the tests so they are processed with the output master file used to prepare a printed report, such as the accounts receivable aged trial balance or an inventory report. Another method is to have an inquiry program prepared that will print out selected master records from the master file to be used in processing the test transactions.
Control of client’s program. One of the important procedures for testing a system is to make sure that the program being tested is the one the company actually uses to process data.
The mini-company approach appears to have great potential for fast-response systems. This approach overcomes some of the limitations of the test-data approach and enables remote entry of test data, online testing, and surprise testing of systems.
The mini-company approach can be defined as a means of passing fictitious test transactions through a computer system simultaneously with live data, without adversely affecting the live files or outputs. In other words, it is a small subsystem of the regular system. A separate set of outputs, including statistics and reports, are produced for the mini-company.
Consider how the mini-company approach could be used in a payroll system. In the time-recording system, a fictitious department could set up records for fictitious employees included as part of the live master file. The test transactions or mini-company transactions could be entered into the system through the terminals used for time recording and run with normal transactions. Exception reports on clock-in transactions and job transactions could be prepared for the mini-company for unusual or error transactions entered. The valid transactions for the mini-company recorded on the daily transactions tape could be separated from the actual data and then processed in a normal manner, generating daily labor reports and providing input for payroll processing and preparation of payroll reports, including payroll checks. The results of the mini-company’s input could be compared with results predetermined to indicate any irregularities in controls or processing.
Transaction flow testing is a method used to document controls in computerized applications. This control review method requires the auditor to identify the following:
The organization’s cycles of business activities
The types of transactions that flow through each cycle (for example, in the payroll cycle are new employee transactions, employee rate increase transactions, hours worked transactions, absences transactions, and so on)
The functions that are performed within each cycle to recognize, authorize, process, classify, and report transactions (activities performed within each cycle; for example, in a payroll system activities include authorizing a change to pay rates, the classification of absences by type, and the preparation of output such as payroll checks)
Specific internal control objectives for each cycle
The internal control techniques used to achieve each stated objective
Transaction flow testing requires the tester to develop a flowchart showing what transactions flow through the business activity being tested. As the tester traces the transaction flow, the tester would indicate the various functions performed on that transaction in the order in which they occur. The control objective at each point is identified, as well as the technique used to achieve that objective.
Using this flowchart of transaction processing, documented in accordance with the transaction flow testing methodology, provides the auditor with the type of information needed to assess the adequacy of internal control.
Objectives of internal control for an entity’s cycles and its financial planning and control function can be developed using a step-down analysis. As shown in Figure 17-4, the analysis begins with the broad objectives of internal control contained in professional accounting literature.
From such an analysis, two levels of objectives can be identified:
Systems control and financial planning and control objectives
Cycle control objectives
The systems control and financial planning and control objectives are more specific than the broadly stated objectives of internal control contained in professional accounting literature. Cycle control objectives can be developed from the systems control objectives by refining them for the different categories of transactions found within a cycle.
This section identifies ten systems control objectives that apply to all accounting systems in all industries. For convenience in reference, the systems control objectives are identified as A through J. The first four (A through D) are pervasive and deal with authorization, classification, substantiation and evaluation, and physical safeguards. The final six (E through J) address the flow of transactions through a system.
The systems control objectives are as follows:
Authorizations should be in accordance with criteria established by the appropriate level of management.
Transactions should be classified in a manner that permits the preparation of financial statements in conformity with generally accepted accounting principles and management’s plan.
Report and database contents should be periodically substantiated and evaluated.
Access to assets should be permitted only in accordance with management’s authorization.
Economic events should be recognized and submitted for acceptance on a timely basis.
All, and only, economic events meeting management’s criteria should be accurately converted to transactions and accepted for processing on a timely basis.
All accepted transactions should be processed accurately, in accordance with management’s policies, and on a timely basis.
The results of processing should be reported accurately.
Database elements should accurately reflect the results of processing.
Events affecting more than one system should result in transactions that are reflected by each system in the same accounting period.
Systems control objectives apply to all cycles. They are not intended, however, to be used directly in evaluating an entity’s internal control techniques. Rather, they represent a base from which specific cycle control objectives applicable to an individual entity can be developed.
In addition to the ten systems control objectives, four financial planning and control objectives may be used to evaluate the techniques employed by management to define and communicate the objectives and business of the entity; the long- and short-range plans for the entity; and the framework for reporting to the designated representatives of stockholders, owners, or members. Figure 17-5 shows the relationship between these control objectives and transaction processing. These financial planning and control objectives are as follows:
The objectives of the entity and the nature of its business activities should be defined and communicated.
A strategic (long-range) plan should be maintained and communicated.
A short-range plan should be developed and communicated.
Management’s plans and the performance of the entity should be regularly reported to the designated representatives of the shareholders, owners, or members
The relationship of these matters to internal accounting controls may seem remote, particularly since the management planning process extends beyond accounting and financial disciplines and embraces marketing, productions, public relations, and legal and legislative considerations. A financial plan is, however, a quantification of an entity’s total planning process. A well-developed, properly communicated, and effectively administered financial plan is a powerful tool for controlling economic events.
Specific internal control objectives can be derived for each of an entity’s recognized cycles from the systems control objectives. Cycle control objectives should address authorization, transaction processing, classification, substantiation and evaluation, and access to assets within each cycle, as follows:
Authorization objectives derived from systems control objective A. These objectives address controls for securing compliance with policies and criteria established by management as part of the financial planning and control function.
Transaction processing objectives derived from systems control objectives E through J. These objectives address the controls over recognition, processing, and reporting of transactions and adjustments.
Classification objectives derived from systems control objective B. These objectives address controls over the source, timeliness, and propriety of journal entries.
Substantiation and evaluation objectives derived from systems control objective C. These objectives address periodic substantiation and evaluation of reported balances and the integrity of processing systems.
Physical safeguard objectives derived from systems control objective D. These objectives address access to assets, records, critical forms, processing areas, and processing procedures.
The illustrative cycle control objectives are oriented toward a manufacturing entity in which the following cycles are recognized:
Treasury
Expenditure (Purchasing)
Expenditure (Payroll)
Conversion
Revenue
Financial Reporting
The illustrative objectives make certain assumptions about the entity. For example, the functions that are assumed to be part of the expenditure (purchasing) cycle are purchasing, receiving, accounts payable, and cash disbursements. In the conversion cycle, as another example, it is assumed that the entity has a cost accounting system.
Although the illustrative cycle control objectives have a particular industry orientation and are based on a number of assumptions, they probably are usable, with only minor modifications, by many entities in a wide variety of industries.
Modifications should be made to recognize the nature of economic activity in an entity’s industry and the terminology and transaction-processing methods that are unique to the industry. For example, objectives identified for a particular retail company that makes only cash sales may address controls over cash registers (which are not much of a problem to most manufacturers) while ignoring customer accounts receivable. Similarly, the objectives for a utility might recognize that services delivered are billed on the basis of meter readings rather than delivery tickets. Whatever modifications are made, however, the internal control objectives for a cycle should derive from the control objectives for a cycle, which should derive from the ten systems control objectives to ensure coverage of each major control within each significant flow of activity.
At the completion of Tasks 1 through 4, testers have gathered the following information about the test performed on internal controls:
Risks for which there were no controls
Controls for which there were no risks
Controls that were not adequate to control the risk to the level specified by the stakeholders of the application system
Interfaces to other systems that are not adequately controlled (see the material on control cycles)
Risks that appear to be adequately controlled
Most testers do not have sufficient training to determine the adequacy of internal controls, which normally is an audit/management responsibility. What the testers can do is identify strengths and weaknesses that customer management can use to determine whether more controls are needed.
The following guide should prove helpful to testers to determine whether controls are strong, average, weak and or non-effective.
Strong controls. An automated preventive control with an automated corrective action—for example, a control that checks the customers credit limit and denies a purchase if that credit limit is exceeded.
An automated detective control with a monitored corrective action. A detective control might identify a customer ordering more than the normal number of a product, with a message going to marketing personnel that must be responded to.
A manual preventive control with a monitored corrective action. An instructor in a warehouse checks to ensure that the products shipped are those on the invoice, and if not, stops shipment until the correct shipment can be determined.
Weak controls. A manual preventive control with a manual corrective process but not a required process—for example, a guard checks employees’ badges manually but does not have to stop an employee from entering if the guard is busy with other actions (for example, a telephone call) or if the guard recognizes that individual as an employee.
Non-effective controls. A detective control with no action required—for example, a computer compiler message does not require the programmer to take action.
If risks have been identified, and exposures estimated, the tester’s report of strengths and weaknesses should be based on level of risk. This is consistent with a concept of internal controls. The tester would look at the totality of controls from the initiation of the source information to the use of the output deliverables.
If risks are not identified in the system documentation, testers would use the risks determined in Task 2 of this process to report strengths and weaknesses.
Testers should use the questionnaire in Work Paper 17-1 as a quality-control checklist for assessing their organization’s level of internal control.
This chapter examined a five-step process to test the adequacy of internal controls in an application system. The chapter also discussed preventive, detective, and corrective control categories to help the tester understand controls and determine control strength and weaknesses. For more information on building and/or testing systems of internal control, visit www.internalcontrolinstitute.com.