- Identify IPE used in key controls and substantive procedures
- Test source data, report logic and parameters for completeness and accuracy
- Decide when ITGC reliance reduces the testing of a standard report
- Evaluate whether a report is precise and detailed enough for its use
Why IPE is its own problem
A control or audit procedure is only as good as the information it uses. A manager who reviews an aging report cannot detect a misstatement in an invoice the report left out. Auditors call this information produced by the entity (IPE).
The standards are direct. AS 1105.10 requires the auditor, when using information produced by the company as audit evidence, to test the accuracy and completeness of the information or test the controls over its accuracy and completeness, and to evaluate whether the information is sufficiently precise and detailed for the audit. For nonissuer audits, AU-C 500.08 requires the auditor to evaluate whether information used as audit evidence is sufficiently precise and detailed and to obtain evidence about its accuracy and completeness as necessary.
Two uses of IPE
- IPE used by the auditor. The auditor uses a client report directly, for example selecting a sample of receivables from an aging report.
- IPE used in a control. The client uses a report to perform a control, for example the user access review list (lesson 4) or a journal entry listing reviewed by the controller. When you test the control, you also need evidence the report was complete and accurate.
Both need testing. The second is easy to miss.
The three parts of a report
Break every report into three parts and get evidence over each.
| Part | Question | Evidence |
|---|---|---|
| Source data | Is the underlying data complete and accurate? | Tests of controls over input, reconciliation to the ledger, or tracing records both ways |
| Report logic | Does the query or program select and calculate correctly? | Inspection of logic, reperformance, or ITGC evidence that a tested standard report has not changed |
| Parameters and output | Were the right parameters used, and was the output not altered? | Observing the run, inspecting parameters, comparing totals to the ledger |
Standard, custom and spreadsheet reports
Standard reports shipped with packaged software and not modifiable by the client carry lower logic risk. If change management controls are effective, you can test the logic once and rely on it.
Custom reports written by the client need logic testing, and change management over the report.
End-user spreadsheets sit outside the application ITGCs. Test formulas, links and inputs each time you rely on them, or test a spreadsheet control (locked cells, version control, review).
Ad hoc queries run by the client for the audit need the most work: you observe the query, inspect the script, and reconcile the output.
Testing techniques
- Agree report totals to the general ledger at the same date.
- Trace a sample from the report to source documents (accuracy) and from source documents to the report (completeness).
- Rerun the report yourself, or observe it being run, with the parameters inspected.
- Recalculate derived fields such as aging buckets.
ITGC reliance
When ITGCs over the application are effective, you can test the logic of a standard or custom report once and rely on change management to show it has not changed. When ITGCs are deficient, you test the report each time you use it.
Precision and detail
The second half of the requirement is easy to skip. A report can be complete and accurate but too summarized for the purpose. A journal entry listing without the user who posted each entry is not detailed enough for a review of entries by unauthorized users. Ask what the control or procedure needs from the report, then check the report gives it.
Use the IPE testing worksheet to document each report once and reference it across workpapers.
Testing an aging report at Thistle Bay Wholesale
Thistle Bay Wholesale's controller reviews a monthly receivables aging to set the allowance. The audit team also uses the December 31 aging to select confirmations.
Source data: the report total of $8.42 million agrees to the receivables control account. The team traces 25 invoices from the sales journal into the aging (completeness) and 25 items from the aging back to invoices (accuracy). All agree.
Logic: the aging is a custom report written by the client's IT team three years ago. The team tested its logic in the prior year by recalculating aging buckets for 40 invoices. This year, the change management log shows no changes to the report, and the team tested change management with no exceptions. The team relies on that evidence instead of repeating the logic test.
Parameters: the team observes the controller run the report with an as-of date of December 31 and inspects that the parameter screen includes all customer types.
Precision: the allowance review needs aging by customer and by bucket. The report gives both.
Conclusion: the aging report is sufficiently reliable for the controller's review and the confirmation sample. The team documents this on one IPE workpaper and cross-references it from the allowance and confirmation sections.
Self-check
Answer each question before you open the answer.
When you test a control that uses a system report, what else must you obtain evidence about?
Show answer
The completeness and accuracy of the report the control relies on. Otherwise the control could operate perfectly on incomplete information.
Why do spreadsheets usually need fresh testing every time?
Show answer
Because they sit outside the ITGCs that protect application logic, so there is no change management evidence that formulas and links are unchanged since the last test.
Give an example of a report that is accurate but not precise enough.
Show answer
A journal entry listing without the posting user. It may be complete and accurate, but it cannot support a review aimed at entries posted by unauthorized users.
Use it on the file
- GuideIPE and IT-Dependent Controls: How to Test the Reports Behind Key Controls
- TemplateIPE Testing Worksheet (Information Produced by the Entity)
- StandardAU-C 500: Audit Evidence: SAS 142, Reliability, IPE and Selecting Items to Test
Sources
- PCAOB, Auditing Standards compilation including AS 1105, AS 2110, AS 2201, AS 2601 and AS 2605
- AICPA, Statements on Auditing Standards currently effective (AU-C sections, including AU-C 402 and AU-C 500)
Standards are paraphrased from the primary sources listed above; read the source before relying on a requirement. This lesson is training material, not professional advice. Report an error