Information System Audit: Revenue Cycle

REVENUE CYCLE AUDIT OBJECTIVES, CONTROLS, AND TESTS OF CONTROLS

The discussion in this section presumes that the reader is familiar with general control and application control in IT environment, and the objectives of audit. Recall that computer application controls fall into three broad categories: input controls, process controls, and output controls. Within this framework, we examine application controls, tests of controls, and the audit objectives to which they relate. Substantive tests and their relationship to audit objectives are considered later in next posting.

1. Input Controls

Input controls are designed to ensure that transactions are valid, accurate, and complete. Control techniques vary considerably between batch and real-time systems. The following input controls relate to revenue cycle operations.

• Credit Authorization Procedures
  The purpose of the credit check is to establish the creditworthiness of the customer. Only customer transactions that meet the organization’s credit standards are valid and should be processed further.
  • In POS systems, the authorization process involves validating credit card charges and establishing that the customer is the valid user of the card. After receiving online approval from the credit card company, the clerk should match the customer’s signature on the sales voucher with the one on the credit card.
  • When credit checks are computerized, the organization’s credit policy is implemented through decision rules that have been programmed into the system. For routine transactions, this typically involves determining if the current transaction plus the customer’s current AR balance exceeds a pre-established credit limit. If the credit limit is exceeded by the transaction, it should be rejected by the program and passed to an exception file, where it can be reviewed by management. The credit manager will decide either to disapprove the sale or to extend the credit limit consistent with the manager’s authority.

  Testing Credit Procedures

  Failure to apply credit policy correctly and consistently has implications for the adequacy of the organization’s allowance for uncollectible accounts. The following tests provide evidence pertaining to the valuation/allocation audit objectives and, to a lesser extent, the accuracy objective.
  • The auditor needs, therefore, to determine that effective procedures exist to establish appropriate customer credit limits; communicate this information adequately to the credit policy decision makers; review credit policy periodically; and monitor adherence to current credit policy.
  • The auditor can verify the correctness of programmed decision rules by using either the test data or integrated test facility (ITF) approaches to directly test their functionality. This testing is easily accomplished by creating several dummy customer accounts with various lines of credit and then processing test transactions that will exceed some of the credit limits. The auditor can then analyze the rejected transactions to determine if the computer application correctly applied the credit policy.

• Data Validation Controls


• Input validation controls are intended to detect transcription errors in transaction data before they are processed. Since errors detected early are less likely to infiltrate the accounting records, validation procedures are most effective when they are performed as close to the source of the transaction as possible. 
• In the batch system, data validation occurs only after the goods have been shipped. Extensive error logs, error correction, and transaction resubmission procedures characterize such systems.
• By contrast, validity tests performed in real time and POS systems can deal with most errors as they occur. This approach also minimizes human data entry and thus reduces the risk of data entry errors. For example, when the clerk enters the customer’s account number, the system automatically retrieves his or her name and mailing address. When the clerk enters the product number and quantity sold, the data entry system automatically retrieves the product description and price, and then calculates the extended price plus tax and shipping charges.

Examples that are relevant to the revenue cycle include the following:

• Missing data checks are used to examine the contents of a field for the presence of blank spaces. Missing product numbers, missing customer account numbers, or incomplete mailing or billing addresses will cause the transaction to be rejected. When the validation program detects a blank where it expects to see a data value, this will be interpreted as an error.
• Numeric-alphabetic data checks determine whether the correct form of data is in a field. For example, an invoice total should not contain alphabetic data. As with blanks, alphabetic data in a numeric field may cause serious processing errors.
• Limit checks determine if the value in the field exceeds an authorized limit. For example, an organization may allow its sales personnel to negotiate prices with customers up to a maximum discount percentage. The order entry validation program can interrogate the discount field in the sales order records for values that exceed the threshold.
• Range checks assign upper and lower limits to acceptable data values. For example, the actual sales price charged for a product can be compared to a range of acceptable prices. The purpose of this control is to detect keystroke errors that shift the decimal point one or more places.
• Validity checks compare actual values in a field against known acceptable values. This control is used to verify such things as product codes, shipping company codes, and state abbreviations in customer addresses. If the value in the field does not match one of the acceptable values, the record is determined to be in error.
• Check digit controls identify keystroke errors in key fields by testing their internal validity. This check is often used to control data entry errors that would otherwise cause the wrong customer’s account to be charged for a transaction.
  

Testing Validation Controls

• Data entry errors that slip through edit programs undetected can cause recorded accounts receivable and revenue amounts to be materially misstated. The audit procedures described here provide evidence about the accuracy assertion.
• Performing substantive tests of detail to identify customers with excessive credit limits can do this. Substantive tests traditionally follow tests of controls because the results of tests of controls are used to determine the nature, timing, and extent of the substantive tests. In this case, however, the central audit issue is whether the validation programs in the data editing system are functioning correctly and have continued to function as intended throughout the period. Testing the logic of a validation program, however, represents a significant undertaking.
• The auditor may decide to rely on the quality of other controls to provide the assurance needed to reduce substantive testing. For example, after reviewing systems development and maintenance controls, the auditor may determine that controls over original program design and testing and subsequent changes to programs are effective. This evidence permits the auditor to assess the risk of material program errors at a low level and thus reduce the substantive tests related to the audit objective of accuracy.
• If controls over systems development and maintenance are weak, however, the auditor may decide that testing the data editing controls would be more efficient than performing extensive substantive tests of details. In such a case, ITF or the test data approach would enable the auditor to perform explicit tests of the logic. This type of testing would require the auditor to gain a familiarity with all of the validation procedures in place. The auditor would need to create a comprehensive set of test transactions that include both valid and erroneous data values that fall within and outside of the test parameters. An analysis of the test results will show the auditor which types of errors, if any, can pass undetected by the validation program. This evidence will help the auditor determine the nature, timing, and extent of subsequent substantive tests. 
• In addition to direct testing of program logic, the auditor can achieve some degree of assurance by reviewing error listings and error logs. These documents provide evidence of the effectiveness of the data entry process, the types and volume of errors encountered, and the manner in which the errors are corrected and reentered into the system. 
• Error listings and logs do not, however, provide evidence of undetected errors. An analysis of error conditions not present in the listing can be used to guide the auditor in designing substantive tests to perform. For example, assume that the error listing of the sales invoice file contains no price limit errors. On the one hand, this situation might simply mean that sales personnel strictly adhere to pricing guidelines. On the other hand, it may mean that the validation program does not test for this type of error. To determine whether material price discrepancies exist in the sales invoice file, the auditor can perform substantive tests that compare the actual price charged with the suggested retail price.

• Batch Controls


• Batch controls are used to manage high volumes of transaction data through a system. The objective of batch control is to reconcile output produced by the system with the input originally entered into the system. While initiated at the data input stage, batch control continues through all phases of data processing. For example, in the revenue cycle sales invoices are gathered together and enter the system at data entry. After each subsequent processing stage in the system, the batch is reviewed for completeness. 
• An important element of batch control is the batch transmittal sheet, which captures relevant information about the batch, such as the following:
  
  • A unique batch number.
  • A batch date.
  • A transaction code (indicating the type of transactions, such as a sales order or cash receipt).
  • The number of records in the batch (record count).
  • The total dollar value of a financial field (batch control total).
  • The total of a unique nonfinancial field (hash total)

Batch Transmittal Sheet

• The information contained in the transmittal sheet is entered as a separate control record that the system uses to verify the integrity of the batch. The task of reconciling processing with the control record provides assurance that:
  
  • All sales invoices and cash receipts records that were entered into the system were processed.
  • No invoices or cash receipts were processed more than once.
  • All invoices and cash receipts entered into the system are accounted for as either successfully processed or rejected because of errors.

Testing Batch Controls.

• The failure of batch controls to function properly can result in records being lost or processed multiple times. Tests of batch controls provide the auditor with evidence relating to the management assertions of completeness and accuracy.
• Testing batch controls involves reviewing transmittal records of batches processed throughout the period and reconciling them to the batch control log. The auditor needs to investigate out-of-balance conditions to determine the cause. For example, assume that a batch’s transmittal record shows 100 sales invoices with a total dollar value of $182,674.87 were entered into the system, but the completed batch log shows that only 96 records were processed with a batch total of $172,834.60. What caused this? Is the problem due to lost or changed invoices? Did the data entry clerk incorrectly calculate the batch control totals? Were error records rejected in processing and removed from the batch? Were rejected records corrected and resubmitted for processing?
• The auditor should be able to obtain answers to these questions by reviewing and reconciling transaction listings, error logs, and logs of resubmitted records. Gathering such evidence, however, could involve scanning literally thousands of transactions. In modern systems, batch control logs are stored online in text files that can be read by word processing and spreadsheet programs. Modern audit software such as ACL is capable of searching log files for out-of-balance conditions. 
• Batch control totals, such as those on the batch transmittal sheet, are also a valuable tool in doing IT audits and fraud audits. For example, it is typical in IT audits to download a copy of the database or sets of data files from a real-time, online system to a microcomputer for analysis and audit procedures by the auditor. One technique for assuring that the data being downloaded are the same data as those being analyzed and tested is to perform batch controls on the live system, which will then be used as control totals for the data loaded on a separate system. Thus, throughout the audit processes, the auditor can be assured that the data are the same (i.e., they have integrity) by checking totals of the test data against the control totals obtained from the live system. This process is particularly helpful to auditors who use generalized audit software, such as ACL.

2. Process Controls

Process controls include computerized procedures for file updating and restricting access to data. Depending on the level of computer technology in place, process controls may also include physical manual tasks. We begin by examining three control techniques related to file updating. Access and physical controls are then examined.

• File Update Controls

  Run-to-run controls use batch control data discussed in the previous section to monitor the batch as it moves from one programmed procedure (run) to another. These controls ensure that each run in the system processes the batch correctly and completely. After each major operation in the process, key fields such as invoice amount and record counts are accumulated and compared to the corresponding values stored in the control record.
  A discrepancy may indicate that a record was lost in processing, a record in the batch went unprocessed, or a record was processed more than once.
  
  • Transaction Code Controls. Revenue cycle systems are often designed to process multiple record types. For example, the order entry application may process both sales orders and returns and allowances transactions. The actual tasks performed by the application are determined by a transaction code assigned to each record. Errors in transaction codes, or in the program logic that interprets them, can cause incorrect processing of transactions and may result in materially misstated sales and accounts receivable balances.
  • Sequence Check Control. In systems that use sequential master files, the order of the transaction records in the batch is critical to correct and complete processing. As the batch moves through the process, it must be re-sorted in the order of the master file used in each run. An out-of-sequence sales order record in a batch may prevent the remaining downstream records from being processed. A more serious problem can occur when the sequencing error is not detected and the downstream records are processed against the wrong customer accounts. A sequence check control should be in place to compare the sequence of each record in the batch with the previous record to ensure that proper sorting took place. Out-of-sequence records should be rejected and resubmitted for subsequent processing to allow the other records in the batch to be properly processed.
  • Testing File Update Controls. The failure of file update controls to function properly can result in records going unprocessed, being processed incorrectly (i.e., returns are treated as sales), or being posted to the wrong customer’s account. Tests of file update controls provide the auditor with evidence relating to the assertions of existence, completeness, and accuracy.
  • We examined the audit procedures for reviewing batch controls previously as part of the discussion of input controls. Testing run-to-run controls is a logical extension of these procedures and needs no further explanation. Tests of transaction codes and sequence checks can be performed using ITF or the tests–data approach. The auditor should create test data that contain records with incorrect transaction codes and records that are out of sequence in the batch and verify that each was handled correctly.
  • Implicit in this test is verifying the mathematical correctness of the computer operation. For example, consider a sales order for five units of product valued at $100. Assume that before the transaction is processed, the current value of the customer’s account is $1,000 and the inventory in question shows 250 units on hand. After processing, this transaction should increase the customer balance to $1,100 and reduce the inventory to 245 units.
  • The efficient use of logic-testing CAATTs like ITF requires careful planning. By determining in advance the input and process controls to be tested, a single audit procedure can be devised that performs all tests in one operation. For example, a single test designed to examine credit authorization controls, transaction code controls, and the mathematical accuracy of the update program can provide evidence that supports multiple audit objectives.

• Access Controls

  Access controls prevent and detect unauthorized and illegal access to the firm’s assets. Inventories and cash are the physical assets of the revenue cycle. Traditional techniques used to limit access to these assets include the following:
  
  • Using warehouse security, such as fences, alarms, and guards
  • Depositing cash daily in the bank
  • Using a safe or night deposit box for cash
  • Locking cash drawers and safes in the cash receipts department
  Controlling access to accounting records is no less important. An individual with unrestricted access to data can manipulate the physical assets of the firm and cause financial statements to be materially misstated. Accounting files stored on magnetic media are particularly vulnerable to unauthorized access, whether its cause is accidental, an act of malice by a disgruntled employee, or an attempt at fraud. The following are examples of risks specific to the revenue cycle:
  
  1. An individual with access to the AR subsidiary ledger could remove his or her account (or someone else’s) from the books. With no record of the account, the firm would not send the customer monthly statements.
  2. Access to blank sales orders may enable an unauthorized individual to trigger the shipment of a product.
  3. An individual with access to both cash and accounting records could remove cash from the firm and cover the act by adjusting the cash account.
  4. An individual with access to physical inventory and inventory records could steal products and adjust the records to cover the theft.
     

  Remote Access Configuration

  Testing Access Controls.

  Access control is at the heart of accounting information integrity. In the absence of controls, invoices can be deleted, added, or falsified. Individual account balances can be erased, or the entire AR file can be destroyed. Evidence gathered about the effectiveness of access controls tests the management assertions of existence, completeness, accuracy, valuation and allocation, right and obligations, and presentation and disclosure.
  Computer access controls are both system-wide and application-specific. Access control over revenue cycle applications depends on effectively controlling access to the operating systems, the networks, and the databases with which they interact. The control techniques —including passwords, data encryption, firewalls, and user views—apply also in preventing unauthorized access to revenue cycle processes. The auditors will typically test these controls as part of their review of general controls.

• Physical Controls

  • Segregation of Duties.
    Proper segregation of duties ensures that no single individual or department processes a transaction in its entirety. The number of employees in the organization and the volume of transactions being processed will influence how tasks are divided. In general, the following three rules apply:
    1. Rule 1.
       Transaction authorization should be separate from transaction processing. For example, within the revenue cycle, the credit department is segregated from the rest of the process, so that the formal authorization of material transactions is an independent event. The importance of this separation is clear when one considers the potential conflict in objectives between the individual salesperson and the organization. Often, sales staff compensation is based on their sales levels. To achieve their personal objective of maximizing sales volume, sales personnel may not always consider the creditworthiness of the prospective customer. The credit department, acting as an independent authorization group, detects risky customers and discourages poor and irresponsible sales decisions. 
    2. Rule 2.
       Asset custody should be separate from the record-keeping task. In the salesorder processing system, the inventory warehouse clerk with custody of the physical assets should not also maintain the inventory records. Similarly, the cash receipts clerk (with custody of cash) should not record accounts receivable. 
    3. Rule 3.
       The organization should be so structured that the perpetration of a fraud requires collusion between two or more individuals. The record-keeping functions must be carefully divided. Specifically, the subsidiary ledgers (AR and inventory), the journals (sales and cash receipts), and the general ledger should be separately maintained. An individual with total record-keeping responsibility, in collusion with someone with asset custody, is in a position to perpetrate fraud. By separating these tasks, collusion must involve more people, which increases the risk of detection and is, therefore, less likely to occur.
  • Supervision.
    Some firms have too few employees to achieve an adequate separation of functions and must rely on supervision as a compensating control. By closely supervising employees who perform potentially incompatible functions, a firm can compensate for the exposure inherent in a system.
    Supervision can also provide control in systems that are properly segregated. For example, the mailroom is a point of exposure for any firm. The individual who opens the mail has access both to cash (the asset) and to the remittance advice (the record of the transaction). A dishonest employee may use this opportunity to steal the check, cash it, and destroy the remittance advice, thus leaving no evidence of the transaction. Ultimately, this sort of fraud will come to light when the customer receives another bill and, in response, produces the canceled check. However, by the time the firm gets to the bottom of this problem, the perpetrator may have committed the crime many times over and left the organization. Detecting crimes after the fact accomplishes little. Prevention is the best solution. The deterrent effect of supervision can provide an effective preventive control.
  • Independent Verification.
    The purpose of independent verification is to review the work performed by others at key junctures in the process to identify and correct errors. Following are two examples in the revenue cycle:
    
    1. The shipping department verifies that the goods sent from the warehouse are correct in type and quantity. Before the goods are sent to the customer, the stock release document and the packing slip are reconciled to identify discrepancies.
    2. The billing department reconciles the shipping notice with the sales invoice to ensure that customers are billed only for the items and quantities that were actually shipped.

  Testing Physical Controls.

  • Inadequate segregation of duties and the lack of effective supervision and independent verification can result in fraud and material errors. Inappropriate access privileges are often associated with incompatible duties. Similarly, the purpose of collusion is to achieve unauthorized access to assets as well as the information needed to conceal the crime. In the absence of supervision and independent verification activities, errors and fraud may go undetected.
  • The auditor’s review of job descriptions and organizational charts, and by observing physical processes, should disclose the more egregious examples of incompatible tasks, such as one individual opening the mail, depositing the check, and recording receipts in the customer accounts. Covert relationships that lead to collusion may not be apparent from an organizational chart. For example, married employees (or those otherwise related) who work in incompatible areas go unnoticed. The auditor should verify that the organization has rules for appropriately dealing with nepotism issues.
  • Many tasks that are normally segregated in manual systems are consolidated in the data-processing function of computer-based systems. Computer programs in the revenue cycle perform inventory control, accounts receivable, billing, and general ledger tasks. In this situation, the auditor’s concern should focus on the integrity of the computer programs that perform these tasks. The following questions need answers: Is the logic of the computer program correct? Has anyone tampered with the application since it was last tested? Have changes been made to the program that could have caused an undisclosed error? Answers to these questions come from the auditor’s review of systems development and maintenance controls and by reviewing organizational structure. Duties pertaining to the design, maintenance, and operation of computer programs need to be separated. Programmers who write the original computer programs should not be responsible for making program changes. Also, individuals who operate the computer system should not be involved in systems design, programming, or maintenance activities. Personal relationships (i.e., marriage) between individuals in these incompatible areas may require further investigation.

3. Output Controls

Output controls are designed to ensure that information is not lost, misdirected, or corrupted and that system processes function as intended. For example, managers receive daily summaries of sales orders placed by customers, goods shipped, and cash received, and use such data to monitor the status of their operations. Output control can be designed to identify potential problems. For example, an exception report derived from the customer open order file listing end-of-day open sales orders can identify orders placed but not shipped.

• Reconciling the general ledger is an output control that can detect certain types of transaction processing errors. For example, the total of all credit sales recorded by billing should equal the total increases posted to the AR subsidiary accounts. A sales transaction that is entered in the journal but not posted to the customer’s account would be detected by an imbalance in the general ledger. Finding the error may require examining all the transactions processed during the period. This could be time consuming. For this reason, rather than summarizing an entire day’s transactions in a single batch, entities often group transactions into small batches of 50 to 100 items. This facilitates reconciling balances by isolating a problem to a specific batch.
• Another important element of output control is the maintenance of an audit trail. It is not sufficient to know that 100 transactions entered the system and only 99 came out. Details of transaction processing produced at intermediate points can provide an audit trail that reflects activity through every stage of operations. 
• The following are examples of audit trail output controls:

• Accounts Receivable Change Report

  This is a summary report that shows the overall change to accounts receivable from sales orders and cash receipts. These numbers should reconcile with total sales, total cash receipts (on account), and the general ledger.

• Transaction Logs

  Every transaction successfully processed by the system should be recorded on a transaction log, which serves as a journal. A transaction log serves two purposes:
  1. The transaction log is a permanent record of valid transactions.
  2. Not all of the records in the temporary transaction file will always be successfully processed. Some of these records may fail validity tests and will be rejected. A transaction log should contain only successful transactions. Rejected transactions should be placed in an error file. The transaction log and error files combined should account for all the transactions in the batch.

• Transaction Listings

  The system should produce a (hard copy) transaction listing of all successful transactions. These listings should go to the appropriate users to facilitate reconciliation with input. For example, a listing of cash receipts processed will go to the controller to be used for a bank reconciliation.

• Log of Automatic Transactions

  Some transactions are triggered internally by the system. For example, EDI sales orders are accepted and processed without human authorization. To maintain an audit trail of these activities, all internally generated transactions must be placed in a transaction log, and a listing of these transactions should be sent to the appropriate manager.

• Unique Transaction Identifiers

  Each transaction processed by the system must be uniquely identified with a transaction number. This control is the only practical means of tracing a particular transaction through a database of thousands or even millions of records. In systems that use physical source documents, the unique number printed on the document can be transcribed during data input and used for this purpose. In real-time systems, which do not use source documents, each transaction should be assigned a unique number by the system.

• Error Listing

  A listing of all error records should go to the appropriate user to support error correction and resubmission.

• Testing Output Controls

  The absence of adequate output controls has adverse implications for operational efficiency and financial reporting. Evidence gathered through tests of output controls relates to the completeness and accuracy assertions.
  
  • Testing output controls involves reviewing summary reports for accuracy, completeness, timeliness, and relevance to the decisions that they are intended to support. In addition, the auditor should trace sample transactions through audit trail reports, including transaction listings, error logs, and logs of resubmitted records. Gathering such evidence, however, may involve sorting through thousands of transactions.
  • In modern systems, audit trails are usually stored online in text files. Data extraction software such as ACL can be used to search log files for specific records to verify the completeness and accuracy of output reports. Alternatively, the auditor can test output controls directly using ITF.

Reference:

James A. Hall, Assurance, Third Edition, 2011, South-Western, Cengage Learning