IPE Testing: Completeness and Accuracy of Entity Reports

Every control that uses a report, and every audit test that uses a population, rests on an assumption that the information was complete and accurate. Information produced by the entity, IPE, is the name for that assumption once it has to be proved, and proving it is the part of SOX and internal audit work that programs most consistently underestimate, because a report looks like evidence and is, until someone asks what would happen if a row were missing. This guide sets out what IPE is, the two routes to testing it, how to build the report inventory that turns hundreds of report uses into a manageable set of tests, how to test each type of information from standard reports to spreadsheets to interface files, and how to document the work, with a test program, an IPE testing record template and a worked example at a bank whose report inventory had just doubled.

This guide was rewritten in September 2026 from a shorter version published in August 2026. Its anchors are PCAOB AS 1105 paragraph 10, which requires the auditor who uses information produced by the company to test its accuracy and completeness or the controls over them, and Staff Audit Practice Alert No. 11 of October 2013, whose inspection findings on system-generated data and reports are still the ones auditors are trying not to repeat.

In this guide

What IPE is, and the three attributes
The two routes: test the information or test the controls over it
The report inventory: test once, use everywhere
The baseline validation of a standard report
Testing by type of information
Completeness, accuracy and parameter techniques
Timing: interim, roll-forward and the instance problem
IPE in internal audit’s own evidence
The test program
The IPE testing record template
Worked example: Lakeshore Bancorp’s 74 reports
When IPE fails: evaluating the consequence
Common mistakes
Related guides

What IPE is, and the three attributes

Information produced by the entity is any data, report, listing, schedule, extract or calculation generated by the organization’s systems or people that a control relies on to operate or that an auditor relies on as evidence. The category is defined by use, not by form: an aging report used by a credit manager to review reserves is IPE for that control; the same report used by the auditor to select a sample is IPE for that test; a spreadsheet that turns the aging into a reserve calculation is IPE for the reserve review. The distinction that matters is between information whose reliability has been established and information whose reliability is assumed, and the whole discipline consists of moving items from the second category to the first.

Three attributes have to be established for each item. Completeness: the information includes everything it should, every transaction, account, user or period in the population it claims to represent, with nothing excluded by a filter, a cut-off, a status code or a join that dropped rows. Accuracy: the amounts, dates, classifications and calculated fields are correct, which means the source data was right and the logic that transformed it was right. And appropriateness of parameters, sometimes folded into accuracy but worth its own line: the instance of the information actually used was run with the right date range, entity, currency, status filters and version, because a perfectly accurate report run for the wrong period is a completeness failure in disguise. AS 1105 paragraph 10 frames the auditor’s obligation around the first two; Alert 11’s findings, which described report parameters and query logic that nobody had tested, are the reason the third is treated as a separate attribute in practice.

The two routes: test the information or test the controls over it

AS 1105 paragraph 10 offers two ways to satisfy the obligation: test the accuracy and completeness of the information itself, or test the controls over its accuracy and completeness. The choice is made per item, and each route has conditions. The controls route works when the information is a standard, unmodified output of an application whose general controls (change management, access, operations) are tested for the period, and the application controls that produce the report are known and tested, usually by a one-time validation of the standard report’s logic against documentation and a re-performance, plus a per-instance check of parameters. It is efficient for reports used many times and fragile in exactly the way Alert 11 described: it covers only what the general controls cover, so a report writer, a custom query, a data warehouse extract or a spreadsheet step outside the tested application is outside the route, whatever the application’s ITGC results say. The direct route works for anything: reconcile the information to an independent source for completeness, trace a selection to source and re-perform calculations for accuracy, inspect the parameters on the instance used. It costs more per instance and requires no reliance on general controls, which makes it the only route when the general controls are deficient and the default route for custom and end-user information.

Most programs use both, and the decision is recorded per report in the inventory: standard reports from tested applications on the controls route with a documented baseline validation; everything else on the direct route, with the direct tests designed once and repeated per instance where the control’s sample requires it. The ITGC versus application controls guide explains the reliance chain the controls route depends on and what happens to it when an ITGC fails; the control classification guide explains why every IT-dependent manual control carries at least one IPE item and how the report inventory is derived from the matrix.

The report inventory: test once, use everywhere

The report inventory is the document that makes IPE testing affordable. It lists every distinct item of information that any key control or audit test relies on, once, with its type, source, logic, parameters, owner and the route and test applied, and it cross-references every control and test that uses it. Without it, a program tests the same aging report eleven times under eleven controls or, more often, tests it under none because each control owner assumed another had. Building it starts from the matrix: for every IT-dependent manual control, list the information inputs; for every automated control, list the configuration reports used to evidence it; for every audit test, list the population source. Then de-duplicate by report identity (the same report with different parameters is one report with a parameter test per use), classify by type, and assign the route.

Inventory field	What it records	Why it matters
Report identity	Name, system report code or query name, version, owner	De-duplication; change tracking
Type	Standard application report; custom report or query; data warehouse or BI extract; spreadsheet; interface or file; manually compiled	Decides the route and the tests
Source and logic	Source system and tables; transformations; calculated fields; joins and filters	Completeness risks live in filters and joins; accuracy risks in calculations
Parameters	Each parameter and its expected value per use (period, entity, status, currency)	The per-instance test
General controls coverage	Whether the producing system and the report definition are inside tested ITGCs (change and access)	Whether the controls route is available at all
Controls and tests using it	Control references; audit test references; frequency of use	One test, many reliances; scoping of ITGCs
Route and test reference	Controls route (baseline validation reference) or direct route (test design reference); date last tested; result	The evidence trail
Change history	Report or logic changes in the period and the re-test performed	Roll-forward and the year-end conclusion

Two features of the inventory drive the ITGC scope. The general-controls-coverage field is the list of systems and report tools that must be inside the ITGC program, and it regularly adds a report writer or a data warehouse that the application-based scoping missed, as the SOX ITGC scoping guide discusses. And the change history field is what makes the year-end conclusion possible: a report whose logic changed in November has to be re-tested for the instances after the change, and a program that does not track report changes cannot know which instances those were.

The baseline validation of a standard report

The controls route rests on a baseline validation: a one-time demonstration that a standard report does what its name says, after which the program relies on general controls to establish that nothing changed. The validation has four parts. The specification: the vendor’s or IT’s documentation of what the report includes, how it selects records and how it computes each column, obtained and read, with any option settings that change its behavior recorded. The completeness proof: one instance reconciled to an independent total, with the reconciliation showing that the report’s population equals the source population under the parameters used, and every filter in the specification tested by confirming what it excludes. The accuracy proof: a selection of lines traced to source records and each calculated column recalculated. And the version record: the report version and the application version at validation, so that a version change triggers a re-validation. The validation is dated, retained and referenced from every control that uses the report, and it is repeated when the version changes, when the general controls fail, or on a cycle the program sets, usually every two to three years, because “standard” reports acquire customizations that nobody remembers making.

Three conditions have to hold for the baseline to carry the year. The report must be the unmodified standard object: a copy of a standard report saved with a new name and one added filter is a custom report, however familiar it looks. The general controls over the application must cover the report objects themselves, which means change management captures report changes and access to report design is restricted; where the application lets business users edit standard reports, the reports are custom for testing purposes. And the parameter test must still be performed per instance, because the baseline validates the logic for whatever parameters are supplied and says nothing about whether the reviewer supplied the right ones. Programs that skip the third condition are the ones that discover, in the fourth quarter, that a reviewer has been working from a report run for the wrong entity since March.

Testing by type of information

Type	Completeness	Accuracy	Parameters and logic	Route and frequency
Standard application report	Reconcile report totals to the application’s control totals or the ledger; confirm no status or date filter excludes items	Trace a selection to source transactions; re-perform calculated fields; compare to vendor documentation	Baseline validation of the standard logic once; inspect parameters on each instance used	Controls route if ITGCs tested; baseline annually or on version change; parameters per instance
Custom report, query or report-writer output	Reconcile to source tables independently (row counts, control totals); review the filter and join logic for exclusions	Inspect the query; re-perform on a sample or re-run independently; trace calculated fields	Test the definition’s change control and access; inspect parameters per instance	Direct route unless the definition is under tested change control; logic annually and on change; parameters per instance
Data warehouse or BI extract	Reconcile to the source system at the load; test the load’s completeness controls (record counts, rejected rows)	Trace measures to source; test measure definitions against the ledger’s definitions	Inspect refresh timing and filters applied in the view; test the transformation logic’s change control	Controls route only if the warehouse is inside tested ITGCs; otherwise direct
Spreadsheet	Tie inputs to source reports (which are themselves IPE); foot and cross-foot; check ranges cover all rows	Inspect formulas with a mapping tool; re-perform key calculations; test hard-coded values	Version and change log; access; the instance used at the control date	Direct route always; logic on implementation and change; inputs per instance
Interface or file	Reconcile record counts and hash or control totals between sender and receiver; test rejected and suspended records	Trace sampled records across the interface; test mapping and conversions	File version and date; extraction parameters; SOC 1 coverage where the sender is a service organization	Controls route via interface controls and SOC 1 reports; direct reconciliation per period as evidence
Manually compiled	Trace a sample of source items to the compilation and test for omissions from the source population	Trace compiled items back to documents	Compiler’s process and independence; cut-off applied	Direct route; per instance

The spreadsheet row is the one that consumes the most hours in most programs, and the end-user computing guide carries the full control set and test program for it; here the point is only that a spreadsheet inside a key control is an IPE item on the direct route, every time, whatever the ITGC results. The interface row is where service organizations enter: a payroll file from a provider, a loan servicing extract from a hosted core, a custody statement, each of which is complete and accurate only to the extent the provider’s controls, evidenced in its SOC 1 report, and the organization’s own reconciliation say so; the SOC 1 review guide covers the complementary user entity controls that make the reliance valid.

Completeness, accuracy and parameter techniques

Completeness is the attribute most often asserted and least often tested, because it requires an independent source to compare against, and the report is usually the only convenient source. Five techniques supply the independence. Reconciliation to control totals: the report’s total or count agrees to a total maintained outside the report, such as the ledger balance, a batch total or the sub-ledger’s own control account. Reconciliation to an upstream population: the user listing agrees to the identity store; the vendor listing to the payments made; the loan aging to the loan system’s portfolio total. Sequence and gap analysis: for numbered items, the report contains every number in the range or explains the gaps. Filter inspection: the query’s or report’s filters are read and each exclusion justified; a status filter that drops “pending” items is the classic silent omission. And negative testing: the tester identifies items that should appear (a transaction posted on the last day, a user created that morning, an invoice in dispute) and confirms they do.

Accuracy is tested by tracing and recalculating. A selection of lines is traced to source documents or system records for amount, date and classification; every calculated field is recalculated from its inputs on the selection; and where the report applies rates, thresholds or mappings, those are compared to the authorized values. The selection is sized as a substantive test rather than a control test, because the question is whether the data is right, and a selection of 25 to 40 lines is usual for a report of any size, per the sample sizes guide. Parameters are tested by inspection of the instance the control used, which means the program has to retain that instance, with its header showing the parameters, rather than re-running the report for the tester; a re-run with today’s data proves the logic and nothing about what the reviewer saw. Where the tool does not print parameters on the output, the instance is retained together with a screenshot of the parameter screen, dated.

Timing: interim testing, roll-forward and the instance problem

IPE testing has its own roll-forward logic, and it differs from the control’s. The logic tests (baseline validation, custom query inspection, spreadsheet formula review) are point-in-time tests of a definition, and they carry forward as long as the definition does not change; the roll-forward question is therefore whether any change occurred between the test and year-end, answered from the change history in the inventory, from the platform’s change log where the definition is under change control, and from a comparison of the current definition to the tested one where it is not. The per-instance tests (parameters, completeness tie-out) attach to the control’s sample: when the control test rolls forward with a fresh sample of instances, each new instance gets its parameter and tie-out check, and the retained instance is the evidence. A program that tests the report logic at interim and forgets to check the year-end instances has covered the logic and not the use, which is the more common failure.

The instance problem is the practical obstacle. For the per-instance test to be possible, the organization has to retain the report as the reviewer received it, with its parameters visible, for every performance of the control, and most review controls were not designed to do that; the reviewer opened the report, looked, and closed it. The fix is procedural and cheap: the control description requires the instance to be saved to the control’s evidence folder with a naming convention that includes the run date and parameters, or the close management tool captures it automatically, and the tester samples from those files. Where instances for the early part of the year were not retained, the tester can re-run the report for those periods only if the data is unchanged and the parameters are known, and the record says the instance was re-created rather than retained, which is a weaker form of evidence the auditor may or may not accept. For the year-end conclusion, the program’s own working rule should be that a key review with no retained instances is a control with no evidence of what it reviewed.

IPE in internal audit’s own evidence

The obligation runs to internal audit’s own work as much as to management’s controls. Every sample is drawn from a population, every analytic runs on an extract, and every conclusion about a population is only as good as the extract’s completeness. The sampling memo template requires the population’s source and its completeness test to be documented before selection, and the audit evidence guide places entity-produced information below externally obtained and auditor-generated evidence in the reliability hierarchy for exactly this reason. In practice the internal auditor applies the same techniques: record counts and control totals from the source system compared to the extract, a reconciliation of the extract’s total to the ledger, inspection of the extraction query, and a note of who ran it and when. An analytics program that does not do this produces findings that dissolve when the process owner points out that the extract excluded a company code, and the journal entry analytics guide and its siblings all begin with the population reconciliation for that reason.

The test program

#	Test	Method	Pass condition
1	Inventory completeness	Derive the information inputs from every IT-dependent manual and automated control and every audit test; compare to the inventory	Every input in the inventory; no control relying on untested information
2	Route assignment	For each item, confirm the route and its conditions (ITGC coverage for the controls route)	Controls route only where the producing system and report definition are inside tested ITGCs
3	Baseline validation (standard reports)	Inspect the validation of the standard report’s logic; re-perform on one instance	Validation documented, current for the version in use, re-performance agrees
4	Logic testing (custom, warehouse, spreadsheet)	Inspect definitions; re-perform or re-run independently; map formulas	Logic produces the intended population and values; no unexplained exclusions or inconsistencies
5	Completeness	Apply the techniques above per item; document the independent source	Report agrees to independent totals or populations within a documented tolerance; filters justified
6	Accuracy	Trace and recalculate on a selection of lines	No unexplained differences; rates and mappings agree to authorized values
7	Parameters per instance	Inspect the retained instance used by the control or test	Parameters match the control’s requirements; instance retained with parameters visible
8	Change control over definitions	Test access to and changes of report definitions, queries and spreadsheet logic in the period	Changes authorized, tested and re-validated; access restricted
9	Interface and service organization coverage	Inspect reconciliations across interfaces; map SOC 1 controls and CUECs to the files relied on	Reconciliations performed and exceptions cleared; CUECs operating
10	Roll-forward	Confirm no logic or version changes after the interim test; re-test instances after any change	Year-end instances covered by a valid test

The IPE testing record template

One record per item in the inventory, with the per-instance section repeated for each instance tested. The record is the cross-reference target for every control test that relies on the item.

IPE testing record

1. Identification. Inventory reference; report or item name; type; source system and tables; owner; controls and tests relying on it.

2. Route. Controls route (ITGC test references for the producing system and the report definition; baseline validation reference) or direct route; rationale.

3. Logic. Description of the report logic, filters, joins and calculated fields; validation or inspection performed; date; result; re-performance evidence.

4. Completeness test. Independent source used; reconciliation performed with amounts and counts; differences and their resolution; filter review; negative tests.

5. Accuracy test. Selection size and method; items traced; fields recalculated; rates and mappings compared; exceptions.

6. Per-instance section. Instance date; control or test that used it; parameters inspected (list); retained instance reference; completeness tie-out for the instance; result.

7. Change control. Changes to the definition in the period; authorization and testing evidence; re-validation performed; access to the definition.

8. Conclusion. Complete and accurate for the uses listed (or not, with the consequence recorded per control); preparer, reviewer, dates; roll-forward note.

Worked example: Lakeshore Bancorp’s 74 reports

Lakeshore Bancorp, the illustrative $9 billion regional bank used across this site, rebuilt its control classification in the year described in the control classification guide, and the report inventory grew from 31 items to 74 as 44 controls were reclassified from manual to IT-dependent manual. The SOX program office then had to test 74 items, 43 of them for the first time, in the same budget year. The inventory sorted them by type: 26 standard core banking and general ledger reports, 17 custom queries and report-writer outputs, 9 data warehouse extracts feeding the finance BI layer, 14 spreadsheets, 6 interface files (the hosted core’s nightly loan and deposit extracts, the payroll provider’s file, two custody statements) and 2 manually compiled listings. The route decision put the 26 standard reports on the controls route, because the core and the ledger were inside the ITGC program with clean results, and everything else on the direct route.

Item	Type and route	Test and result	Consequence
Interest income variance analysis (FIN-214)	Standard GL report into a spreadsheet; controls route for the report, direct for the spreadsheet	Baseline validation of the GL report; spreadsheet formulas mapped; portfolio totals reconciled to the ledger each month; one range in the yield column stopped two rows short of the newest portfolio	Formula corrected before the redesigned review (see the management review controls guide) went live; no misstatement, because the portfolio was new and small
Terminated-user listing for the wire platform review	Custom query against the platform database; direct route	Query inspected: the join to HR terminations used employee ID, and 38 contractor accounts had no HR record and were excluded by design; reconciled to the platform’s full user list	Completeness failure; the review had never seen contractor accounts; query rewritten and the review re-performed for the year, which fed the year-end deficiency evaluation described in the deficiency evaluation guide
Loan aging report	Standard core banking report; controls route	Baseline validated against the vendor’s report specification; totals reconciled to the loan control account monthly; parameters inspected on each instance used by the allowance review	Passed; the instance for September had been run with a status filter excluding non-accrual loans, and the reviewer had used it; instance re-run and review re-performed
Wire exception queue	Custom report from the platform’s report writer; direct route	Report writer found to be outside the ITGC program’s change management; two undocumented logic changes in the period; logic re-performed independently for the instances used	Report writer added to ITGC scope for the following year; the external auditor’s adjustment noted in the classification exercise
Hosted core nightly loan extract	Interface file; controls route via the service organization’s SOC 1 plus reconciliation	SOC 1 Type 2 covered the extract’s generation; the bank’s nightly record-count and balance reconciliation was tested for the period, with 3 rejected-record exceptions all cleared within a day	Passed; the complementary user entity control for the reconciliation was confirmed operating
Deferred loan fee amortization workbook	Spreadsheet; direct route	Inputs pasted from a loan system extract without tie-out; formula error in the amortization column found by the external auditor before the program’s test reached it	The $1.4 million error and the significant deficiency; workbook retired into the loan system’s module the following year, per the end-user computing guide

Across the 74 items the program recorded 11 exceptions: four completeness failures (three from filters, one from a join), three parameter failures on instances the reviewer used, two logic changes outside change control, one formula error, and one interface reconciliation that had not been performed for two weeks during a system upgrade. Nine of the eleven were in items that had never been tested before the reclassification, which was the sentence the program office put at the top of the memo to the audit committee. The testing hours for IPE came to roughly 560, against a plan of 480, and the overrun was entirely in the 17 custom queries, where the direct route’s logic inspection took longer than anyone had estimated because the queries had no documentation. The following year the program’s first request to IT was documentation and change control for the query library, which cut the IPE budget by a third.

When IPE fails: evaluating the consequence

An IPE failure is not a deficiency in itself; it is a deficiency in every control that relied on the information, evaluated control by control. A completeness failure in a listing means the review over that listing did not cover the excluded population, and the exposure is what the excluded population could contain: 38 contractor accounts with wire access is a very different exposure from 38 dormant read-only users. An accuracy failure means the review reached conclusions on wrong numbers, and the exposure is bounded by the size of the error and the review’s threshold. A parameter failure means the instance reviewed was the wrong population or period, evaluated like completeness. A logic-change failure removes the basis for the controls route for the instances after the change, and the direct route has to be applied to them retroactively before any conclusion is drawn. The deficiency evaluation guide walks the likelihood and magnitude analysis; the point specific to IPE is that the remediation is usually a re-performance of the control on corrected information for the period, not merely a fix to the report, because the control’s conclusions for the period were reached on the wrong data.

Common mistakes

Testing the reviewer and not the report. Treating a report from a tested application as covered when the report came from a report writer or a query the ITGCs did not touch. Re-running the report for the tester instead of retaining the instance the control used. Testing accuracy by re-adding the report to itself. Asserting completeness with no independent source. Reading the report’s filters and calling it a completeness test without checking what the filters excluded. Testing each report under each control instead of once per report. Ignoring the spreadsheet step between the system and the reviewer. Ignoring the change history of report definitions, so that a November logic change invalidates the interim test without anyone noticing. Drawing audit samples from extracts whose completeness was never established. And rating an IPE failure as a documentation matter when it left a review blind to a population for the year. The automated controls testing guide covers the configuration reports that evidence automated controls, which are IPE too, and the ITGC primer the general controls the controls route depends on.

Comments

Leave a Reply Cancel reply

Dark Towers by David Enrich: Summary and Lessons for Auditors

Blind Spots by Bazerman and Tenbrunsel: Summary and Lessons for Auditors

Black Box Thinking by Matthew Syed: Summary and Lessons for Auditors

The Field Desk Series

IPE: Testing the Completeness and Accuracy of Information Produced by the Entity