What Is IPE in Audit? Risks, Testing, and Controls

In an audit, IPE stands for Information Produced by the Entity: any report, listing, schedule, spreadsheet, or other output that a company generates from its own systems and that an auditor then uses as evidence supporting a number in the financial statements. An accounts receivable aging, a fixed asset additions schedule, a payroll register, an inventory compilation, a query pulling revenue transactions for sampling — all IPE. Under PCAOB Auditing Standard 1105, the auditor cannot simply accept it. Before relying on IPE, the auditor has to test its accuracy and completeness directly, or test the controls that produce it.¹

What Counts as IPE

Two things make information IPE: it originates inside the company, and it feeds into the audit. 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 equally.

Common examples include transaction listings for revenue or cash disbursements, aging schedules that drive reserve estimates, depreciation schedules, and inventory summaries. Less obvious ones include the parameters someone typed into a report generator, a pivot table built from exported data, or an internally developed model used to calculate an allowance for doubtful accounts.

What Isn’t IPE

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. A bank statement reflects what the bank recorded, not what the company’s systems produced, so it doesn’t need the same validation procedures. Confusing the two categories is a common mistake, and it matters because external documents carry a reliability that internally produced reports do not.

Why IPE Matters to the Audit

IPE sits at the foundation of most substantive testing. When an auditor selects 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 contains incorrect amounts, the sample is contaminated and any conclusion drawn from it is unreliable. You cannot verify the details on top of a population you haven’t verified underneath.

PCAOB Auditing Standard 1105, paragraph 10, requires the auditor 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 also has to evaluate whether the information is precise and detailed enough for the specific procedure being performed.¹ For non-public company audits, the AICPA’s clarified standards impose a parallel requirement under AU-C Section 500. Different standard-setter, same logic.

Skipping IPE validation isn’t a shortcut. It’s a professional standards violation.

The Two Risks: Accuracy and Completeness

Every IPE validation comes down to two questions. Are the numbers in the report correct? And does the report contain everything it should?

Accuracy

Accuracy risk is the chance that values on the report don’t match what’s actually in the source system. A query pulls the wrong date range. A spreadsheet formula references the wrong cell. An aging calculation applies bucket thresholds inconsistently. Accuracy errors tend to originate in three places: poorly written extraction logic, manual manipulation after the initial pull, and formula errors in spreadsheets or models.

Completeness

Completeness risk is the chance that the report is missing data. A query excludes a subsidiary’s ledger. A filter drops transactions below a threshold. A parameter cuts off one day too early. Completeness failures are particularly dangerous because they create silent understatement of the population. If the auditor samples from an incomplete list and finds no errors, the clean result is meaningless — the problematic items may be sitting in the excluded data.¹

How Auditors Test Accuracy

Testing accuracy means confirming that the values on the IPE report faithfully reflect the underlying source records. The straightforward approach is tracing: pick a sample of line items from the IPE 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 pulls 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 calculated IPE. If the client produced an interest expense schedule, the auditor independently recalculates interest for a sample of loans using the stated principal, rate, and period. If the client’s reserve model applies loss percentages to aging buckets, the auditor rebuilds those calculations from scratch. The point is to verify both the formula logic and its application to the data.

Report Logic and Parameters

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 lets the auditor confirm that selection criteria, date ranges, and filters align with what the report is supposed to capture. A revenue listing intended to cover the full fiscal year should not have a WHERE clause that stops at November 30.

Capturing the parameters at the moment the report was generated also matters. Auditors look for evidence of the system it came from, what filters were applied, and a timestamp confirming when it was run. Without that evidence, there’s no way to know whether 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 in the opposite direction from accuracy testing. Instead of starting with the IPE and tracing back, the auditor starts with the source system and traces forward. Select transactions directly from the general ledger or subledger and confirm they appear on the IPE. If a fixed asset purchase shows up in the GL detail but not on the client’s additions schedule, the schedule is incomplete.

Often the most efficient completeness check is reconciling 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 a detailed cash disbursements listing totals $12.3 million but the GL shows $12.5 million, there’s a $200,000 gap that has to be explained before the listing can serve as a population.

For physical counts like inventory, completeness 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.

How System Controls Change the Picture

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 the system’s output. Effective ITGCs cover program change management, logical access restrictions, and computer operations. Taken together, they mean the programs generating IPE haven’t been improperly modified and the processing environment is stable.

This creates practical efficiency. If an aging report comes from an ERP with strong, tested ITGCs, the auditor may need only limited substantive testing of the IPE itself. Comfort shifts from “I verified this specific report” to “I verified the environment that produces this type of report.”

Benchmarking Automated Controls

For fully automated application controls, auditors can go further through benchmarking. The premise is that an automated control, once confirmed to work correctly, should continue to work the same way in future periods as long as the underlying program hasn’t changed. Under PCAOB AS 2201, the auditor assesses whether benchmarking is appropriate by evaluating factors including whether the control maps to a defined program, whether the application has been stable with few changes, and whether reliable evidence exists that the program hasn’t been modified since it was last tested.² Frequent updates, weak access controls, or a recent system migration undercut benchmarking, and the auditor falls back to direct testing.

Weak Controls Mean More Work

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. 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 bucket routinely.

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 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.

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. So auditors treat spreadsheet-based IPE as inherently higher risk. In practice, they re-perform key calculations, check formula logic cell by cell for critical calculations, verify that inputs tie to source records, confirm that all rows are captured in summary totals, and look for manual overrides or hard-coded values that bypass formulas.

IPE From a Service Organization

When a company outsources processes that affect financial reporting — payroll processing, benefits administration, loan servicing — some of the IPE the auditor needs comes from the service provider rather than the company itself. The auditor’s obligation to validate that information doesn’t disappear because a third party produced it.

Service Organization Control (SOC 1) reports are the primary mechanism for gaining comfort here. 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 it’s 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) — controls the client company must 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 platform to authorized personnel and the client hasn’t done that, the chain is broken. The user auditor has to test those CUECs as part of the financial statement audit.

How Management Can Make IPE Audit-Ready

Auditors test IPE, but management owns it. Companies that hand over clean, well-organized IPE make the audit faster and cheaper. A few practices carry most of the weight:

Maintain an IPE inventory. Know which reports, schedules, and spreadsheets the audit relies on, assign ownership to each, and document the system or process that produces it.
Preserve report parameters. Save screenshots or logs showing the system, filters, date ranges, and timestamps used to generate each report. Recreating that evidence 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 draws far more scrutiny.
Document management review controls. When a manager reviews IPE as part of a control, the workpaper should show what they compared it to, what threshold flagged exceptions, and what they did about anything unusual. A signature on a 200-page report with no evidence of what was actually checked provides little comfort.

None of this guarantees the auditor accepts the IPE without further testing. But it reduces surprises, shortens the audit, and shows that the company takes its own data seriously — which is exactly the posture an auditor is looking for when deciding how much work to do.