Audit raw, not "cooked," data

Internal Auditor, Dec, 1997 by Richard B. Lanza

When data in client-supplied reports is accepted without questioning its underlying basis, internal auditors risk flawed audit results. Unfortunately, this blind faith in report data is common. Typically, internal auditors receive printed reports, such as an accounts receivable subledger, from clients. Then they simply reconcile the report's total to the general ledger, manually recalculate the total, and "eyeball" it for discrepancies.

Such tests are beneficial, but not sufficient. By first understanding the nature of printed reports, and then learning some testing advantages afforded by file auditing software, the auditor can place more reliance on client-supplied information.

WHY VERIFY THE DATA?

A report is based on two components within the computer system: tables of data arranged in rows and columns, and the report writer's parameters that direct the computer to print certain data. However, these parameters can be altered by anyone with the appropriate access and knowledge - which in many organizations is a large group of individuals. In addition, the report writer program is similar to a spreadsheet program in functionality, making alterations rather simple. Intentional or unintentional report inaccuracies can occur as a result of:

* Columns or transactions that have been "hidden" to deter analysis.

* Transactions that have been added or deleted in an effort to "plug" a reconciliation.

* Calculations that have been altered to benefit the analysis at hand.

In the printed accounts receivable subledger, for example, an individual with access to the report writer can conceal receivables in the "electronic file" of a customer who has filed for bankruptcy and has no intention of ever paying. To prevent detection, the individual can then "plug" the total of the report by adding phony invoices. These efforts will be detected only if the auditor reviews the methodology for producing the report. If auditors do not test the basis of the report, audit findings or audit objectives based on it will be unfounded.

TWO VERIFICATION METHODS

Either of two approaches, parameter reviews or file auditing, can enhance the reliability of a report. A parameter review requires the auditor to learn the report writers for multiple applications, such as accounts payable and accounts receivable. If the information technology department cannot commit the time to "walk" the auditors through the process, the auditors must review the application documentation or attend appropriate training. The parameters of each report must then be reviewed for inaccuracies. Auditors may also need to run a new report based on their own parameters for comparison against the client's report. Unfortunately, such parameter reviews are often time-consuming and labor-intensive.

File auditing, on the other hand, allows internal auditors to produce their own reports by learning only one software. Furthermore, to ensure a reliable report, the auditors set the parameters after they receive the client's data. File auditing software also can perform detailed analysis and various manual tests with more efficiency and better precision than a parameter review allows.

The following example illustrates the differences between the two methods: An auditor receives a printed accounts receivable aged trial balance from the client. She immediately considers that it is in the client's best interest to report a more current aging of receivables because it will lower the bad debt expense calculation. Therefore, she must either test the report parameters or audit the file to ensure that all invoices are aged appropriately. Otherwise, there is no guarantee that the aging categories labeled "30 Days" and "60 Days" are reported accurately.

OPTION 1

Test the report parameters by reviewing the report writer documentation and deciphering the logic of the report.

For this report, a code has been placed next to certain old invoices. Due to the way the report is written, these coded transactions will print incorrectly in the "Current" aging category. The transaction will appear in this list as long as the code is in place, regardless of the actual age of the invoice. The program does not calculate the age but simply identifies a code. After identifying the code's existence, the auditor can rewrite the report, making sure that the code is not considered.

Without a strong grasp of the report's parameters, this irregularity might go undetected. However, this knowledge applies only to the accounts receivable report writer. Any additional report writers, like accounts payable or fixed assets, require the same level of comprehension prior to reliance.

OPTION 2

Audit the file by creating a report. The auditor constructs her own aged report by downloading a file of all open invoices as of the date of the report. Once obtained, she defines or "parses" the data, whereby an identification is made of all data fields, such as "Customer Name" or "Invoice Amount." She uses these labels when instructing the software to print the specific data for her report. Using the audit software's aging capabilities, the auditor then "ages" the file based on the invoice date. Any invoice codes are disregarded by this report, ensuring an accurate aging of the information.