IPE and IT-Dependent Controls: How to Test the Reports Behind Key Controls

Many manual controls are really two controls: a person reviews a report, and the system produced the report. If the report is wrong or incomplete, the review is worthless however carefully it was done. Testing the report is what auditors and internal testers call IPE testing, short for information produced by the entity. This post lays out a method and a complete example, grounded in the SEC's guidance for management and the IIA Standards on reliable information.

What the SEC guidance says about IT dependence

The SEC's interpretive guidance for management recognizes that controls that address financial reporting risks may be automated, dependent upon IT functionality, or a mix of manual and automated procedures. It gives examples: application controls that perform automated matching or edit checks; consistent application of a formula or posting to the correct ledger accounts, which depend on IT functionality; and a control that manually investigates items in a computer-generated exception report. In those situations, management's evaluation generally considers the design and operation of the automated or IT-dependent application controls and the relevant IT general controls over the applications providing the functionality. The guidance adds that IT general controls alone ordinarily do not adequately address financial reporting risks, but that the proper and consistent operation of automated controls often depends on them.

It also says management needs to evaluate only those IT general controls necessary for the proper and consistent operation of other controls that address financial reporting risks. That scoping principle is how you decide which reports matter: start from key controls, find the reports they depend on, and then find the ITGCs behind those reports.

What internal audit standards add

IIA Standard 14.1 sets the test for any information an auditor relies on: relevant, reliable and sufficient. It says reliability is strengthened when information is obtained directly by an internal auditor or from an independent source, corroborated, or gathered from a system with effective governance, risk management and control processes, and it requires auditors to use professional skepticism in evaluating reliability. Those are the same ideas applied to a report.

A five-step IPE method

1. Identify the report and its use. Name the report, the control that uses it, the system, and whether it is standard or custom.
2. Identify the source data and the logic. Which tables, which filters, which date parameters, which calculations.
3. Test completeness. Does the report include all the records it should? Compare record counts or control totals to an independent source, such as the general ledger balance or a system-wide count.
4. Test accuracy. Do the fields match source documents? Agree a sample of rows to invoices or contracts, and recompute calculated fields such as aging buckets.
5. Test the parameters and the logic. Confirm the filters, the date range and the report code were the intended ones when the control operated, and that the code was not changed. For a custom report, inspect the query. For a standard report, confirm no change to the report and rely on ITGC over program changes.

Then link to the ITGCs: access to alter the report logic and the underlying data, and change management over the report and the application.

Worked example: AR aging used in the allowance review

Control. Each quarter-end the credit manager reviews the accounts receivable aging report and proposes the reserve based on aging buckets. The controller approves.

Report. Custom ERP report "AR_AGING_QE", run on the last business day of the quarter, aging by invoice date, grouped by customer.

Completeness.

• Agree the report total to the AR control account in the general ledger: report $14,982,400; ledger $14,982,400.
• Agree the count of open invoices to the system's open item table via an independent query run by IT with the tester present: 3,412 both.
• Confirm that unapplied cash and credit memos are included. The report omitted unapplied credits of $212,600 in an earlier year because of a filter. The tester confirms the filter now includes document types for credits.

Accuracy.

• Select 25 invoices from the report. Agree invoice date, amount and customer to the source invoice.
• Recompute aging buckets for 25 items from invoice date to period end. One item was aged from the due date rather than invoice date. Determine whether the error is systematic by recomputing 25 more. If the code ages from the due date for one customer class, that is a defect that moves balances between buckets and changes the reserve.

Parameters.

• Review the saved report parameters for the run: the as-of date, company code and document types.
• Compare the version of the report code to the prior quarter. There is no change record. Ask IT for the program change log for the report, and examine it.

ITGC link. The report depends on access to modify report code, and on change management over reports. If ITGC testing found that three developers could change production reports without approval, the tester cannot conclude that the report logic stayed constant between runs without re-inspecting the code at the time of the control.

Conclusion. The reviewer's control depends on this report. If the aging defect is real and the effect on the reserve exceeds the amount that could be material, the deficiency is evaluated as a control deficiency in the design of the report-related controls, not only in the review.

Reducing the effort

The SEC guidance says that when ITGCs are effective, an automated control may be more efficient to evaluate than a manual one, and that management can consider the efficiency with which a control's operation can be evaluated when choosing among controls that address a risk. For reports, that supports testing a standard report once, with change management over it, and relying on that test across periods when the ITGCs have not changed. A custom report with frequent edits needs more frequent testing.

Common failures

• Testing the review and ignoring the report.
• Testing a report run for the auditor on a different day, with different parameters, than the one used in the control.
• Accepting a screenshot of the report as evidence of completeness.
• Missing spreadsheets: a user extracts data into a spreadsheet, applies formulas and uses the result in a control. The spreadsheet is IPE, and its formulas and inputs need testing.

Related reading

• /us/blog/it-audit-guide-itgc-program-and-checklist
• /us/blog/management-review-controls-precision-design-and-evidence
• /us/blog/audit-data-analytics-full-population-testing

CORAA prepares ready-to-review audit files for US CPA firms from client books; the firm keeps the client, the review and the signature. See /us.

Sources

• SEC, Release No. 33-8810, Sections II.A.1.b and II.A.1.d (identification of controls; role of information technology general controls), including footnotes 34 to 36: https://www.sec.gov/rules/interp/2007/33-8810.pdf
• The IIA, Global Internal Audit Standards (2024), Standard 14.1 Gathering Information for Analyses and Evaluation: https://www.theiia.org/en/standards/2024-standards/global-internal-audit-standards/

AU-C references are to AICPA Professional Standards, paraphrased here; read the standard itself before relying on a requirement. This page is guidance, not professional advice. Report an error