What IPE is, and why it gets flagged
Information Produced by the Entity (IPE) is any report, extract, or query result that management or an auditor relies on as evidence: an AR aging report, a system-generated reconciliation, a user access listing pulled from an ERP. The moment you cite one of these as proof a control worked, you have to prove the report itself is trustworthy.
IPE Completeness & Accuracy Testing Template
A 16-column tracker with dropdown pass/fail scoring, a worked example row, and a Summary Dashboard tab that recalculates on its own.
That is not a formality. BDO's guidance on IPE ↗ puts it plainly: without a documented control over it, IPE “may contain inaccurate and/or incomplete information,” which then wastes everyone's time re-doing the work downstream. The fix is not more evidence. It is two specific, well-documented tests.
- Completeness . nothing relevant was left out of the report
- Accuracy . the numbers in the report tie back to source data and recalculate correctly
- A worked example row, already filled in, so you're not staring at a blank grid
- A Summary Dashboard that scores your pass rate and open exceptions automatically
Why completeness and accuracy are tested separately
PCAOB AS 1105 ↗, the standard that governs audit evidence, is specific about this: when an auditor uses information the company produced, they must “test the accuracy and completeness of the information, or test the controls over the accuracy and completeness of that information.” Two words, two different failure modes, two different tests.
You are checking that the report's population is whole. Nothing got filtered out by an over-tight query parameter, a wrong date range, or a status flag that silently excluded rows.
In practice this usually means tracing the report's total (or row count) to an independent source, like the general ledger trial balance for the same period.
You are checking that the data itself is right, not just present. Do the numbers agree with the originating transactions, and do any calculated fields (aging buckets, totals, percentages) recompute correctly?
In practice this usually means pulling a sample of lines and recalculating them by hand against source documents.
How to use the template
- List every IPE item you rely on as evidence, one per row, naming its source system and the control it supports
- Write the specific completeness test you performed, not just "checked it"
- Write the specific accuracy test you performed
- Score Pass, Fail, or Not Tested for both tests using the dropdown, and log where the evidence lives
- Check the Summary Dashboard tab, it updates automatically as you fill in rows
Where IPE testing usually goes wrong
- Testing the report, not the population . sampling three rows from the report tells you nothing about what the report might have left out
- No independent tie-out . a completeness test that only checks the report against itself is not a completeness test
- Vague test descriptions . "reviewed for reasonableness" will not survive an external audit or a PCAOB inspection; write down the actual source you traced to
- Skipping parameter review . a query filter or date range that quietly excludes rows is the single most common way IPE fails completeness
- Retesting from scratch every quarter . the same report, same source system, same control usually needs the same test logic each time; a template turns that into a five-minute update instead of a rebuild
How CueDev's control-testing builds handle this automatically
This template gets you a clean, defensible manual process. The next step, and the part we actually build for finance and compliance teams, is an agent that pulls the report itself, reruns the completeness tie-out against the source system, resamples lines for the accuracy check, and writes the result straight into a log your auditor can read without a walkthrough call.
We cover the same top-down, risk-based thinking behind that build in our piece on designing internal controls that actually hold up, and CUEC gaps often show up in the exact same evidence trail, see our CUEC mapping template if a vendor SOC report is part of your control story.
FAQ
Information Produced by the Entity. It covers any report, extract, or system-generated data that management or an auditor relies on as evidence, rather than evidence obtained directly from a third party.
Because they are different failure modes. A report can be perfectly accurate but still miss rows (a completeness failure), or include every row but calculate a field wrong (an accuracy failure). PCAOB AS 1105 requires both to be addressed.
Yes. It downloads directly with no email or signup, and you can adapt the columns to match your own control framework or your external auditor's specific requests.
Yes. The completeness and accuracy split is the same whether the test supports an internal control self-assessment, an internal audit finding, or evidence for an external auditor.
Testing the control checks whether the control activity (a review, an approval, a reconciliation) happened and worked. Testing IPE checks whether the underlying data that control relied on was trustworthy in the first place. You need both for the control to actually mean something.
Next step
If your evidence trail also includes a vendor's SOC report, pair this with our CUEC mapping template so vendor-side gaps show up before an auditor finds them.