APPLICATION SOFTWARE AND APPLICATION CONTROLS (STUDY OBJECTIVE 5)

Applications software accomplishes end user tasks such as word processing, spreadsheets, database maintenance, and accounting functions. All application software runs on top of the operating system software and uses the basic input, output, and data storage functions of the operating system. Any accounting software is considered application software. Application software represents another entry point through which unauthorized users or hackers could gain access. As is true of the eight exposure areas described so far, the application software has security, confidentiality, availability, and processing integrity risks. Many of the general controls listed in Exhibit 4-5 can help minimize those risks. For example, authentication of the user through user IDs and passwords can reduce the chance of unauthorized access. Application software processes inputs into accounting information and therefore carries specific processing integrity risks not inherent in the eight previous IT components described. The specific processing risks are inaccurate, incomplete, or unsecure data as it is input, is processed, or becomes output. Another risk of application software is the addition and processing of unauthorized transactions. For these specific risks, application controls should be part of accounting applications.

Many of the general controls in Exhibit 4-5 can help limit access to application software; specific application controls should also be incorporated. Application controls are internal controls over the input, processing, and output of accounting applications. Exhibit 4-1 illustrated that application controls apply to specific accounting applications such as payroll, sales processing, or accounts receivable processing. In any of these accounting applications, data are entered through some method of input, those data are processed, and outputs such as reports or checks are produced. Application controls intended to improve the accuracy, completeness, and security of input, processing, and output are described as follows:

1. Input controls are intended to ensure the accuracy and completeness of data input procedures and the resulting data.
2. Processing controls are intended to ensure the accuracy and completeness of processing that occurs in accounting applications.
3. Output controls are intended to help ensure the accuracy, completeness, and security of outputs that result from application processing.

INPUT CONTROLS

In IT systems, data must be converted from human-readable form to computer-readable form. This process is called data input. Data can be input into a computer application in many different ways. For example, data can be keyed into blank fields on a computer screen from a keyboard; data can be read from bar codes; or data can be received electronically via EDI or the Web. No matter the manner of input, controls should be in place to ensure that the data entered are accurate and complete. You probably know the old computer acronym GIGO, which stands for “Garbage in, garbage out”—a short-hand method of saying that if you enter incorrect data, you will obviously get incorrect results. Input controls are intended to prevent or detect the “garbage in” so as to avoid incorrect output, or “garbage out.”

To illustrate some input controls, Exhibit 4-8 presents a Microsoft Dynamics GP^® screen capture of the input screen to add a new employee to the payroll records.

As the data input person prepares to enter data for a new employee, input controls should be in place to ensure the authorization, accuracy, and completeness of that data input. These input controls are of four types:

1. Source document controls
2. Standard procedures for data preparation and error handling
3. Programmed edit checks
4. Control totals and reconciliation

Exhibit 4-8 Employee Maintenance Screen in Microsoft Dynamics^® GP

Source Document Controls

In many IT systems and applications, data are keyed in to input screens similar to the Microsoft Dynamics GP^® example in Exhibit 4-8. Before those data can be keyed in, the data must be captured and recorded on a source document. A source document is the paper form used to capture and record the original data of an accounting transaction. For example, before filling in the blank fields in Exhibit 4-8, the data entry person needs to know the new employee's name, address, hire date, and many other pieces of information. For new employees, the source document would be a personnel action form, a sample of which appears as Exhibit 4-9.

The data entry person often refers to a copy of the source document to enter the data into the blank fields on the screen. It should also be noted that many IT systems do not use source documents. In cases where the input is automatic, such as Web-based sales, no source documents are generated. Where no source documents are used, the general controls described earlier, such as computer logging of transactions and making and keeping backup files, become more important. Where source documents are used, to minimize the potential for errors, incomplete data, or unauthorized transactions as data are entered from source documents, several source document controls should be used.

Form design: Both the source document and the input screen should be well designed so that they are easy to understand and use, logically organized into groups of related data. For example, notice that employee name and address blanks, or fields, are located very close to each other, since they are logically related. Source documents should have clear and direct instructions embedded into the form. The personnel action form in Exhibit 4-9 has the following instruction line: “Please check the status of the employee.” Finally, the source document design and input screen design should match each other. Ideally, the fields on both forms should be the same and the fields should be in the same order. The closer the source document matches the input screen, the easier it is for the data entry person to complete the input screen without uncertainty and errors.

In many applications, it is not possible to fit all necessary data on a single input screen. This problem is solved by having several related input screens to enter all data. Exhibit 4-10 illustrates a second screen for new employees that allows the input of pay rate data on a pay code screen.

Form authorization and control: The source document should contain an area for authorization by the appropriate manager, such as the bottom left of the form in Exhibit 4-9. The source document forms should be prenumbered and used in sequence. Prenumbering allows for ongoing monitoring and control over blank source documents. If the source document sequence is monitored to ensure that there are no missing numbers in the sequence, most likely no transactions will be lost. Finally, blank source documents should be controlled by being kept in a secure area so as to prevent their being misused to initiate an unauthorized transaction.

Retention of source documents: After data from source documents have been keyed into the computer, the source documents should be retained and filed in a manner that allows for easy retrieval. Filed source documents serve as the historical, original records of transactions and can be used to reconstruct transactions if necessary, or can be used to answer questions that arise about transaction processing. These source documents are part of the audit trail. The audit trail, defined in Chapter 3, is defined here also as a reminder. The audit trail re-creates the details of individual transactions at each stage of the business process in order to establish whether proper accounting procedures for the transaction were performed.

Exhibit 4-9 Personnel Action Form

Exhibit 4-10 Related Input Screens for a New Employee

Standard Procedures for Data Input

Data preparation: The procedures to collect and prepare source documents are called data preparation procedures. Without well-defined source data preparation procedures, employees would be unsure of which forms to use, as well as when to use them, how to use them, and where to route them. For example, when a new employee is hired, the human resources department must know which form to use to document the hiring, how to complete the form, and which department to send the form to after it is completed. The standard data collection procedures reduce the chance of lost, misdirected, or incorrect data collection from source documents. Employees who complete source documents must understand these data preparation procedures. If employees are not well trained in these procedures, errors in data collection are likely to result.

Error handling: As data are collected on source documents or entered on screens, errors may occur. It is not possible to eliminate all errors. Therefore, an organization should have error handling procedures. As errors are discovered, they should be logged, investigated, corrected, and resubmitted for processing. The error log should be regularly reviewed by an appropriate manager so that corrective action can be taken on a timely basis. Corrective action might require more training for employees, better form design, or better data collection procedures.

Programmed Input Validation Checks

Data should be validated and edited as close as possible to the time of obtaining the data from its original source. In many IT systems that process transactions in real time, editing can take place during data entry. Real-time systems must have access to data in master files, such as balances and employee pay rates. Since these data are online and available in real time, editing can be completed by checking data input against data in master files. For example, when the data entry person enters an employee number in the corresponding field, a real-time system would find the employee record and fill in the appropriate fields with the employee data such as name, address, and pay rate. If an invalid employee number is entered, the real-time system can alert the user that the entry is invalid. In addition to real-time data editing, the application software can include input validation checks to prevent or detect input errors. These checks are pre-programmed into accounting application software and are intended to check a field, or fields, for errors. Exhibit 4-2 illustrated an example of an input validation called a validity check. Input validation checks include the following:

1. Field check
2. Validity check
3. Limit check
4. Range check
5. Reasonableness check
6. Completeness check
7. Sign check
8. Sequence check
9. Self-checking digit

Any particular field may require only numbers, only letters, or a combination of numbers and letters. A pay rate field should accept only numbers, while the last name field should be only letters. A field check examines a field to determine whether the appropriate type (alpha or numeric) of data was entered. If the wrong data type is entered, the application should reject that data and alert the user with an error message. There are some fields, such as inventory part numbers, that might be a combination of alpha and numeric data. For those fields, a field check would not be an appropriate input validation. A validity check examines a field to ensure that the data entry in the field is valid compared with a preexisting list of acceptable values. For example, there may be only two choices for acceptable values for a field named Pay Type: “hourly” and “salary.” The application can be preprogrammed to check input into that field to make sure it is either “h” or “s.” Any other values should be rejected as not valid, and the user should see an error message on the screen if the data are not valid. Exhibit 4-2 shows such a message. Limit checks and range checks are very similar. Both check field input against a preestablished limit or limits. A limit check has only an upper limit; for example, hours worked cannot exceed a value of 70 hours per week. Hours worked would never be negative, and it is conceivable that it could be zero in some cases. Therefore, there is no need for a lower limit in that field, and a limit check would be appropriate. A range check has both an upper and a lower limit. Some fields, such as quantity requested, may logically suggest that the entry cannot be less than 1. Therefore, a range check could be preprogrammed into the application to accept values between one and some upper limit. A reasonableness check compares the value in a field with those fields to which it is related to determine whether the value is reasonable. For example, pay rate could be compared with a job category code. A completeness check assesses the critical fields in an input screen to make sure that a value is in those fields. For example, when a new employee is processed, a Social Security number must be entered. The completeness check scans only to make sure that a value has been entered; it cannot ensure that the correct value was entered. A sign check examines a field to determine that it has the appropriate sign, positive or negative. All of these checks examine a field or fields against some preestablished expected values.

Programmed input checks can be used not only for data input that is keyed in but also for some forms of electronic input such as EDI transactions or Web-based sales. In the case of Web sales, the customer enters data into fields, where programmed input validations can ensure proper input. In EDI transactions, data are imported into the application software through the EDI translation software. These programmed checks can help confirm the accuracy and completeness of imported data.

The programmed input checks just described are appropriate for real-time or batch systems. The final two programmed input validation checks discussed next are more appropriate for transactions that are processed in batches. In batch systems with legacy software and hardware, the master files are not necessarily always online and/or available in real time. Transactions are entered and edited as a batch and run against a master file as a batch. Therefore, the batch of transactions must be in the same order as the master file. For payroll, both transaction and master files are probably sorted by employee number. A sequence check ensures that the batch of transactions is sorted in order, but does not help find missing transactions because it checks only sequence, not completeness. In any particular pay period, there may be employees who will not be paid, perhaps because they are on a monthly, rather than bi-weekly, pay period, or because they are on unpaid leave. The sequence check just skips over the missing employee number and verifies only that the remaining employees in the batch are sorted in the correct order. A self-checking digit is an extra digit added to a coded identification number, determined by a mathematical algorithm. For example, if a vendor number is to be 6453, then an extra digit is added to the end to make it 64532, where the “2” is generated by a mathematical formula. For any data entry tasks, the vendor number 64532 is always used. During an edit run, the computer recomputes the same formula to ensure that the self-checking digit still equals 2. If the data entry person accidentally typed 65432 rather than 64532, the self-checking digit would not match and the input could be flagged as erroneous.

Control Totals and Reconciliation

Control totals are useful in any IT system in which transactions are processed in batches. Control totals are subtotals of selected fields for an entire batch of transactions. For a batch of similar transactions, such as payroll transactions for a pay period, control totals can be calculated before data are processed. For example, the total number of hours worked on all time cards can be summed. After the time card data are keyed into the application software, a printed report can provide the computer-generated subtotal of hours worked. This reconciliation of manually generated subtotals to computer-generated subtotals should result in the same total from both sources. If they do not agree, this indicates that an error has occurred, such as adding extra transactions, skipping transactions, or entering the wrong hours for one or more transactions. Control totals are of three types: record counts, batch totals, and hash totals. Record counts are a simple count of the number of records processed. The records can be counted prior to and after input, and the totals should agree. Batch totals are totals of financial data, such as total gross pay or total federal tax deducted. Hash totals are totals of fields that have no apparent logical reason to be added. For example, the summation of all Social Security numbers in a batch of payroll transactions would provide a control total for comparison, but the total would have no other practical use. Both batch and hash totals are subtotals of certain fields.

PROCESSING CONTROLS

Processing controls are intended to prevent, detect, or correct errors that occur during the processing in an application. First and foremost, it is important to ensure that the application software has no errors. Software that incorrectly processes data can be dangerous, because it can consistently make the same errors and thus cause many errors in the data. To verify the accuracy of application software, the company should be sure the software is tested prior to implementation; and it must be regularly tested thereafter. Application software can be tested by reprocessing actual data with known results or by processing test data. Whether actual or test data are used, the results of processing the data are compared with known results to make sure that there are no errors in processing.

Many input controls also serve as processing controls. Control totals, limit and range tests, and reasonableness and sign tests can prevent or detect processing errors. Control totals such as record counts, batch totals, and hash totals can be reconciled during stages of processing to verify the accuracy and completeness of processing. This reconciliation of control totals at various stages of the processing is called run-to-run control totals. During processing, some calculations such as addition or multiplication must occur. Limit, range, and reasonableness checks can be used to ensure that the results of these mathematical manipulations are within expected ranges or limits.

Computer logs of transactions processed, production run logs, and error listings can be regularly examined to prevent, detect, and correct other errors. These logs allow management to find patterns of errors and take action to correct erroneous procedures or application software.

OUTPUT CONTROLS

Many outputs in an IT system are reports from the various applications. An example of an output report is a payroll check register. There are two primary objectives of output controls: to ensure the accuracy and completeness of the output, and to properly manage the safekeeping of output reports to ascertain that security and confidentiality of the information is maintained. To ensure accuracy and completeness, the output can be reconciled to control totals. In addition, it is extremely important that users of the reports examine the reports for completeness and reasonableness. Users of the reports are the most familiar with the nature of the output reports and are therefore most likely to notice if there are errors. Any errors detected must be logged and corrected. Management should watch for patterns of errors and follow up with corrective action.

Output reports contain data that should not fall into the wrong hands, as much of the information is confidential or proprietary. Therefore, an organization must maintain procedures to protect output from unauthorized access, in the form of written guidelines and procedures for output distribution. In the case of sensitive data, the procedures might include a requirement that users sign off on the receipt of outputs. Under this procedure, users must sign a log to indicate that they received the output, and the output is not released without the signature. The organization should also establish procedures to guide the retention and disposal of output, such as how output reports are to be stored and the length of time they are to be retained. Outputs scheduled for disposal should be properly removed, depending on the nature of the output. Sensitive output reports should be shredded.

In many cases, the output from IT systems is viewed on a screen rather than examined from a printed copy. In the case of screen outputs, the authentication of user controls described earlier help protect the security and confidentiality of output. Authentication controls help assure that only authorized users have access to such output.