Information produced by the entity (IPE), defined
Updated
Information produced by the entity (IPE) is any report, query output, or data extract generated from a company's own systems and used in performing or testing a control. Because a control is only as reliable as the information it consumes, every piece of IPE needs completeness-and-accuracy support.
IPE is where otherwise-sound control programs quietly fail audits. The control operated, the reviewer signed off — but the user list they reviewed came from a query nobody can produce, run with parameters nobody recorded. Without support for the report itself, the auditor treats the control as unevidenced, no matter how diligently it was performed.
What counts as IPE
IPE covers essentially every system output that a control touches: the user access list behind an access review, the change-ticket export behind change testing, an accounts-receivable aging report, a custom SQL extract, a spreadsheet built on top of any of these. The term comes from audit practice — auditors also say information produced by the company — and it applies in two directions: reports management uses to perform its controls, and reports handed to the auditor as evidence.
The defining feature is provenance, not format. A report is IPE because the entity's own systems and people produced it, which means its reliability cannot be assumed the way an independent third-party confirmation's can. Someone chose the source, the logic, and the parameters — so someone has to show those choices produce complete, accurate output.
Completeness and accuracy
Supporting IPE means answering three questions: is the source data itself reliable (an ITGC question — access and change controls over the system it came from); is the report logic correct (does the query or report definition actually select what it claims to); and were the parameters right for this use (the correct period, entity, and population, with nothing filtered out). Completeness gets special attention because it fails silently — an accurate report over half the population looks perfectly clean.
What support looks like varies with how the IPE is produced:
| IPE type | Examples | Typical C&A support |
|---|---|---|
| Standard system report | Vendor-delivered user list, standard aging report | Record the parameters used; rely on the vendor's report logic where ITGCs over the system are effective; tie record counts or totals to the source. |
| Custom report or query | SQL extract, report built in-house | Retain and test the query logic itself; record parameters and date ranges; reconcile counts or totals back to the source system. |
| End-user computing | Spreadsheet that filters, joins, or computes over an extract | Support the underlying extract first, then verify formulas, filters, and manual steps; keep the workbook versioned so the reviewed copy is reproducible. |
Why every report used in a control needs support
A control inherits the weaknesses of its inputs. An access review over an incomplete user list produces confident assurance about the wrong population; change testing against a partial change extract proves nothing about the changes that were excluded. From the auditor's side the logic is mechanical: if the IPE is unsupported, the control performed with it cannot be relied on, and the test of that control is effectively void — the finding is written against the control even though the control itself may have operated perfectly.
The recurring failure mode is not bad reports but undocumented ones: a query that lives only in someone's head or terminal history, parameters that were never recorded, a spreadsheet edited after the review it evidenced. Each of these turns a performed control into an unevidenced one.
Baselining
Testing every report's logic every time it is used does not scale, so mature programs baseline: test a report's logic thoroughly once, then rely on change-management ITGCs to establish that the logic has not changed since. Each subsequent use only needs the per-use support — parameters and completeness ties — not a full re-test. The baseline holds until the report is modified or the ITGCs it depends on fail; either event triggers rebaselining. This is the same reliance structure auditors apply to automated application controls, applied to reports.
What good looks like is a maintained IPE registry: the reports used in controls are registered and carried with their completeness-and-accuracy support, ideally on evidence collected read-only from source systems with an append-only trail. When evaluating any tool or process for this, look for a model that keeps a control backed by unsupported IPE marked as a gap until a named human accepts proper support, rather than one that estimates its way past a missing report. The goal is straightforward: when the auditor asks where a number came from, the answer is already on file.
Frequently asked questions
What does IPE stand for in auditing?
Information produced by the entity — any report, query result, or data extract generated from the company's own systems and used in performing a control or as audit evidence. Auditors sometimes call it information produced by the company (IPC); the concept is the same.
What is completeness and accuracy testing?
The support showing a piece of IPE can be trusted: the source system's data is reliable (backed by effective ITGCs), the report or query logic is correct, and the parameters used captured the complete, correct population. Completeness matters most because an accurate report over a partial population fails silently.
Is a screenshot enough to support IPE?
Usually not on its own. A screenshot shows that an output existed at a moment; it does not show what query produced it, what parameters were used, or whether the population is complete. Screenshots work as one layer of evidence alongside the recorded logic, parameters, and completeness ties — not as a substitute for them.
What is IPE baselining?
Testing a report's logic thoroughly once, then relying on change-management controls to establish the logic has not changed, so later uses only need per-use support like parameters and record-count ties. The baseline must be redone when the report changes or the ITGCs it relies on fail.
Why do auditors care so much about IPE?
Because every control conclusion chains back through the information it used. If the report behind a control is unsupported, the control test is void regardless of how well the control was performed — so unsupported IPE quietly converts operating controls into findings.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.