Information Produced by the Entity, or IPE, is any report, listing, schedule, spreadsheet, or other output a company generates from its own systems that an auditor then uses as evidence during a financial statement audit. In audit work, IPE might be an accounts receivable aging report, a fixed asset additions listing, a depreciation schedule, or an inventory count summary. Because audit conclusions get built on top of this information, auditors are required to test whether it is accurate and complete before relying on it. If the underlying data is wrong, every conclusion drawn from it is wrong too.
What Qualifies as IPE
IPE is defined by two things: it originates inside the company, and it supports a number or assertion in the financial statements. The format is irrelevant. A standard report pulled from an ERP system, a custom SQL query run against a database, and a formula-heavy Excel workbook all qualify. So do the parameters someone typed into a report generator, a pivot table built from exported data, and an internally developed model used to calculate an allowance for doubtful accounts.
Common examples include detailed transaction listings for revenue or cash disbursements, aging schedules that drive reserve estimates, and inventory compilation summaries. Less obvious IPE includes the specific selection criteria used to pull a report, or a working spreadsheet built on top of a system export.
Documents that originate outside the company are not IPE, even when management is the one handing them to the auditor. Bank statements, executed contracts, and vendor invoices are source documents. They carry a reliability that entity-produced reports do not, because they reflect what an outside party recorded rather than what the company’s own systems generated. That distinction changes which validation procedures apply.
Why Auditors Have to Validate It
IPE sits at the foundation of most substantive testing. When an auditor picks a sample of revenue transactions to verify, the population from which that sample is drawn is almost always an IPE listing. If the listing is missing transactions or has incorrect amounts, the sample is contaminated and the conclusion is unreliable.
PCAOB Auditing Standard 1105, paragraph 10, requires auditors to evaluate whether entity-produced information is sufficient and appropriate by either testing its accuracy and completeness directly or testing the controls over its accuracy and completeness. The auditor must also judge whether the information is precise and detailed enough for the specific procedure.1PCAOB. AS 1105: Audit Evidence This is not optional. An auditor who simply accepts a client’s report without validation has violated professional standards. For non-public company audits, the AICPA’s clarified auditing standards impose a parallel requirement under AU-C Section 500.
The Two Risks That Drive Every Procedure
Every IPE test comes back to two questions. Is the data in the report correct? And does the report contain everything it should? Accuracy and completeness are directional risks, and auditors address them with different procedures.
Accuracy
Accuracy risk is the possibility that the values in the report don’t match what’s actually in the source system. A query might pull the wrong date range. A spreadsheet formula might reference the wrong cell. An aging calculation might apply bucket thresholds inconsistently. Accuracy errors tend to originate from three places: poorly written extraction logic, manual manipulation after the initial pull, and formula errors in spreadsheets or models.
Completeness
Completeness risk is the possibility that the report is missing data. A query might exclude a subsidiary’s ledger. A filter might inadvertently drop transactions below a certain dollar threshold. A report parameter might cut off one day too early. Completeness failures are especially dangerous because they create a silently understated population. If the auditor samples from an incomplete list and finds no errors, the clean result is meaningless, because the problematic items may be sitting in whatever was excluded.1PCAOB. AS 1105: Audit Evidence
How Auditors Test Accuracy
Testing accuracy means confirming that the values on the IPE report faithfully reflect the underlying source records. The most direct approach is tracing. Pick a sample of line items from the report and verify each one against the source system or original documentation. If the aging report says Customer X owes $47,500 at 60 days past due, the auditor looks up that customer’s subledger in the ERP system and confirms the balance and the invoice dates.
Re-performance is the go-to procedure for IPE that depends on calculations. For an interest expense schedule, the auditor independently recalculates interest on a sample of loans using the stated principal, rate, and period. For a reserve model that applies loss percentages to aging buckets, the auditor rebuilds those calculations from scratch. The point is to verify both the formula logic and the way it was applied to the data.
When IPE comes from a custom query or report, auditors often ask to see the underlying extraction logic. Reviewing the query code or report parameters confirms that the selection criteria, date ranges, and filters match what the report is supposed to capture. A revenue listing meant to cover the full fiscal year should not have a WHERE clause that stops at November 30.
Capturing the report parameters at the moment of generation matters too. Auditors look for evidence of the system used, the filters applied, and a timestamp showing when the report ran. Without that evidence, there’s no way to confirm that the report the auditor received is the same one management actually used, or whether it was regenerated later with different parameters.
How Auditors Test Completeness
Completeness testing runs the opposite direction from accuracy testing. Instead of starting with the IPE and tracing back, the auditor starts with the source and traces forward. Select transactions directly from the general ledger or subledger and confirm they appear on the IPE listing. If a fixed asset purchase shows up in the GL detail but not on the client’s additions schedule, the schedule is incomplete.
The most efficient completeness check is often a reconciliation to a control total. The auditor compares the grand total of the IPE listing to an independent figure, typically the corresponding general ledger balance. If the detailed cash disbursements listing totals $12.3 million but the GL shows $12.5 million, there’s a $200,000 gap that needs an explanation before the listing can be used as a population. Any unexplained variance has to be investigated and resolved.
For physical counts like inventory, completeness testing means confirming that every storage location was counted and every count sheet was included in the final compilation. Missing a warehouse or dropping a count sheet creates the same problem as a filtered-out subledger. The population is silently incomplete.
IT Controls Change How Much Testing Is Needed
The amount of direct testing an auditor performs on IPE depends heavily on the strength of the system that produced it. When a company’s IT general controls (ITGCs) over the relevant application have been tested and found effective, the auditor can place more confidence in that system’s output. Effective ITGCs cover program change management, logical access restrictions, and computer operations, meaning the programs generating the IPE haven’t been improperly modified and the data environment is stable.
If the aging report comes from an ERP system with strong, tested ITGCs, the auditor may need only limited substantive testing of the report itself. Comfort shifts from “I verified this specific report” to “I verified the environment that produces this type of report.”
For fully automated application controls, auditors can go a step further through benchmarking. The logic is that an automated control, once confirmed to work correctly, should keep working the same way in later periods as long as the underlying program hasn’t changed. Under PCAOB AS 2201, the auditor assesses whether benchmarking is appropriate by looking at factors like application stability, change frequency, and evidence that the program hasn’t been modified since the last test.2PCAOB. AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements Benchmarking only works in stable environments. Frequent updates, weak access controls, or a recent system migration push the auditor back to direct testing.
The reverse scenario is expensive. When the system producing IPE has weak ITGCs, or when the IPE comes from a system outside the IT control framework entirely, the auditor cannot lean on the environment and has to validate the output directly. That means larger samples, more re-performance, and reconciliation to control totals for every listing from that source. Legacy systems, standalone databases, and spreadsheets fall into this category routinely.
Why Spreadsheets Get Extra Scrutiny
Spreadsheets combine high prevalence with low inherent controls. A standard ERP report runs through a controlled application with access restrictions, change management logs, and defined processing logic. A spreadsheet sits on someone’s desktop, or on a shared drive, with no audit trail for formula changes, no access controls beyond a file password, and no version history unless someone deliberately configures it.
The risks are well documented. A misreferenced cell, a hard-coded override buried in a formula, or a row accidentally excluded from a SUM range can silently corrupt the output. Because spreadsheets lack the native controls of enterprise applications, auditors treat spreadsheet-based IPE as inherently higher risk.
In practice, the auditor will typically re-perform the key calculations rather than relying on any system-level comfort. That means checking formula logic cell by cell for critical calculations, verifying that data inputs tie to source records, confirming that all rows are captured in summary totals, and looking for manual overrides or hard-coded values that bypass formulas. Companies with significant spreadsheet-based IPE increasingly adopt governance programs that inventory critical spreadsheets, assign ownership, and establish change-control procedures.
IPE From Service Organizations
When a company outsources processes that affect financial reporting, such as payroll processing, benefits administration, or loan servicing, some of the IPE the auditor needs comes from the service organization rather than the company’s own systems. The obligation to validate that information doesn’t disappear just because a third party produced it.
Service Organization Control (SOC 1) reports are the primary tool auditors use to get comfort over outsourced processes. A SOC 1 contains management’s assertion that specified controls are in place to meet defined control objectives, along with an independent CPA firm’s testing of those controls. A Type I report covers control design at a point in time. A Type II report covers both design and operating effectiveness over a period, and provides substantially more assurance. Type II is what most auditors need to support reliance across the audit period.
Reading the SOC 1 isn’t the end of the analysis. Most SOC 1 reports list Complementary User Entity Controls (CUECs), which are controls the client company has to implement on its end for the service organization’s controls to achieve their objectives. If the SOC 1 assumes the client restricts access to the service organization’s platform to authorized personnel, and the client hasn’t done that, the control chain is broken. The user auditor has to test those CUECs as part of the financial statement audit. Skipping them undermines the entire basis for relying on the SOC 1.
What Happens When IPE Validation Fails
When an auditor can’t get comfortable with the completeness or accuracy of a piece of IPE, the consequences cascade quickly. The report can’t be used as a population for substantive testing. Alternative procedures may exist, but they’re usually more time-consuming, more expensive, and sometimes not enough to close the gap.
In an integrated audit of a public company, pervasive IPE control failures can rise to the level of a material weakness in internal control over financial reporting. Under PCAOB AS 2201, a material weakness exists when there is a reasonable possibility that a material misstatement won’t be prevented or detected on a timely basis. If controls over key IPE are so deficient that the auditor has no basis for trusting the data flowing through the control environment, that can trigger an adverse opinion on internal controls.2PCAOB. AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements
In extreme cases, if the auditor cannot obtain enough evidence to support an opinion because the IPE is unreliable and no alternative procedures can compensate, the auditor may need to disclaim an opinion or withdraw from the engagement.2PCAOB. AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements This is rare, but it does happen, and the PCAOB’s inspection program continues to flag IPE testing as a recurring area of deficiency across firms of all sizes.
What Companies Can Do to Prepare Clean IPE
Companies that produce well-organized IPE make the audit faster and cheaper. A few practices help:
- Maintain an IPE inventory. Know which reports, schedules, and spreadsheets auditors rely on, assign ownership to each one, and document the system, query, or process behind it.
- Preserve report parameters. Save screenshots or logs showing the system, filters, date ranges, and timestamps used when a report was generated. Auditors will ask, and recreating it after the fact raises questions.
- Reconcile to control totals before handing anything over. If the detailed listing doesn’t tie to the general ledger, the auditor will send it back. Catching the variance yourself saves time.
- Lock down critical spreadsheets. Use cell protection, track changes, and limit editing access. A spreadsheet anyone can modify without a trail invites far more scrutiny.
- Document management review. When a manager reviews IPE as part of a control, the workpaper should show what they compared it to, what threshold they used to flag exceptions, and what they did about anything unusual.
None of this guarantees the auditor will accept the IPE without further testing. It does reduce surprises, shorten the audit timeline, and demonstrate that the company takes its own data seriously.