IPE in the Age of AI: Validating Completeness and Accuracy Under SOX

Teams are increasingly turning to AI models to automate report generation, perform data analysis, and surface insights that once required hours of manual effort. But this efficiency comes with a critical and often underappreciated challenge: how do you ensure that the data and reports produced by AI are complete and accurate when used in internal controls under Sarbanes-Oxley (SOX)?

When AI enters that workflow, the traditional approach to IPE validation is no longer sufficient. This guide explains why, and provides practical, actionable steps for control owners and preparers to address the gap. Our focus is on Information Produced by the Entity (IPE): the data files, reports, and outputs generated within or by systems used by an organization, which are then relied upon in the execution of internal controls.

What Is IPE and Why Does It Matter?

Information Produced by the Entity (IPE) refers to any report, data file, or output that an entity generates from its own IT systems and uses in the performance of a control. Classic examples include:

• An accounts payable aging report pulled from an ERP to support the AP review control
• A transaction listing exported from a procurement system to verify authorization of purchase orders
• A journal entry population report used as the basis for the journal entry review control

For IPE to be reliable, it must be both complete (all relevant records are included, with no records missing) and accurate (the data correctly reflects the underlying transactions and system records). If the IPE used in a control is incomplete or inaccurate, the control itself is undermined, regardless of how well the control procedure itself is executed.

Auditors and management under SOX have long been required to validate the completeness and accuracy of IPE. The methodology for doing so has been well-established for traditional IT system-generated reports. As AI enters the picture, however, that methodology needs to evolve.

AI as a Report Producer: A Different Kind of Risk

Traditionally, data files and reports used in controls are produced by IT systems such as ERP platforms, procurement systems, sub-ledgers, and the like. In most cases, control owners can obtain comfort over the completeness and accuracy of these outputs by reviewing the service organization's SOC 1 (System and Organization Controls) report. A SOC 1 report, issued by an independent auditor, provides assurance that the service organization has effective controls over its IT systems. An unqualified SOC 1 opinion, combined with complementary user entity controls, gives the control owner reasonable confidence in the integrity of reports produced by that system.

AI models do not produce SOC 1 reports. This is a fundamental gap in the assurance chain. When a company uses an AI model to generate a report or analyze a data set that feeds into a SOX control, the control owner cannot rely on a SOC 1 to validate the completeness and accuracy of that AI-generated output. The AI model, for SOX purposes, must be treated as an out-of-scope system.

Any data file or report produced by an AI model that is used in the execution of an internal control must be subject to manual control activities specifically designed to address completeness and accuracy. The responsibility for validating AI outputs cannot be delegated to the AI itself.

The AI-Integrated Data Lifecycle

To understand where completeness and accuracy risks arise, it helps to trace the full lifecycle of data from initial entry through AI-assisted analysis to final output.

The lifecycle consists of seven stages, each with its own risk profile and corresponding control considerations. The first four stages mirror the traditional IPE framework; the final three reflect the additional complexity introduced by AI. The stages are sequential and cumulative: a weakness early in the chain flows downstream, so each stage assumes the ones before it have been validated.

Stage 1: Data Input

The lifecycle begins where every report does, with data entering the system. Nothing downstream can be more complete or accurate than the data captured here, which means the controls at this stage effectively set the ceiling for everything that follows. If the underlying population is wrong from the start, no amount of careful exporting, manipulation, or AI analysis will fix it.

Input controls are the first line of defense. These include system-enforced validations (e.g., required fields, format checks, range checks), segregation of duties over data entry and approval, and access controls that restrict data input to authorized personnel. Management review controls, such as supervisory review of new entries or reconciliation of input totals to source documents, provide an additional layer of assurance.

Evidence to retain: system configuration screenshots, access provisioning records, and documented approvals.

Stage 2: User Data Request

Once data is in the system, someone has to ask for it back out. The way a report is requested, including the parameters entered and the system it is pulled from, determines whether the population you receive is the one the control actually needs. A subtly wrong date range or a report pulled from a synchronized-but-lagging system can produce a file that looks right and reconciles to nothing.

The control owner should verify the accuracy of the report total and agree it to an independent source, such as the general ledger or a sub-ledger balance. Alternatively, the control owner should review and confirm the appropriateness of the criteria used to generate the report. Best practice is for the preparer to capture a screenshot at the time the report is requested, documenting the parameters entered. The control owner then reviews that screenshot to confirm the criteria were appropriate and the report was pulled from the system of record.

Evidence to retain: parameter screenshot, control owner sign-off.

In the example above, the control owner has inspected the saved-search criteria, confirmed that no filter would inadvertently exclude records, and documented that conclusion directly on the screenshot with their initials and date. That annotated screenshot becomes the evidence that the request itself was appropriate.

Stage 3: IT Application + IPE Definition

Behind every report is the application that stores the data and the IT general controls (ITGCs) that keep that application trustworthy. This stage is where traditional SOC 1 reliance lives, and where its limits begin to matter once AI enters the picture. The reliability of the report is only as strong as the controls over the system that produced it.

Ensure that ITGCs over the relevant systems are designed and operating effectively. This includes controls over logical access, change management, and data backup and recovery. For systems supported by third-party service organizations, review the applicable SOC 1 reports and evaluate any exceptions or qualified opinions. Where SOC 1 reports identify deficiencies relevant to the completeness or accuracy of report outputs, implement compensating controls at the user entity level. Document the basis for relying on the system and retain evidence of the SOC 1 review, including any bridge letters that extend coverage to the evaluation period.

Evidence to retain: SOC 1 review documentation and bridge letters.

Stage 4: IT Application Output

Getting data out of the system is deceptively risky. Exports silently drop rows, hit tool limits, or carry over filters that were only ever meant for on-screen viewing. Because this is the last clean checkpoint before a human, or an AI, starts manipulating the data, it is the natural place to lock in a defensible record count and control total that everything downstream can be tied back to.

When a system-generated report is exported to a tool such as Excel, the control owner should perform procedures to validate that all records exported from the IT system are reflected in the output. This is especially important when the export appends data to an existing file or when the population is large enough to approach tool limitations (e.g., Excel's 1,048,576 row limit). Recommended procedures include reconciling the record count in the export to the record count displayed in the source system; agreeing the total of a key amount field (e.g., invoice total, transaction amount) in the export to the corresponding total in the system; and, where applicable, verifying that no filter is applied to the exported file that would exclude records.

Evidence to retain: reconciliation workpaper tying the export to the source system.

This reconciliation works best when both sides are captured side by side. In the screenshots below, the source system reports a population of 81 records, and the exported workbook's row count ties back to that same total. That is simple, durable evidence that nothing was dropped on the way out.

Stage 5: User Changes

Raw exports are rarely usable as-is. Preparers filter, categorize, add columns, and calculate, and every one of those touches is an opportunity to break the population or introduce an error that no system will catch for you. By this point the data has left the controlled environment of the source application entirely, so the discipline has to come from the preparer and reviewer.

Once data is exported to a tool like Excel, preparers often need to manipulate it to achieve the objective of the task, whether that is filtering, categorizing, adding supplemental data fields, or performing calculations. Each of these steps introduces the risk of error. The control owner should perform procedures to validate any changes made to the exported data. This includes confirming that computations and categorizations are appropriate and consistently applied, verifying that any data added from external sources is accurate and complete, and ensuring that the final dataset used in the control reflects the same population as the original export. Maintaining a version history or using protected workbooks can reduce the risk of inadvertent changes.

Evidence to retain: annotated workpaper showing the computation and categorization review.

Stage 6: AI Prompt + Data Analysis

This is where AI changes the picture. Up to now the framework has mirrored traditional IPE; from here, the "system" producing the analysis is a model with no SOC 1, no change log you can audit, and a tendency to be confidently wrong. It is also the stage where most of the time is saved, which is exactly why the controls around it have to be the most rigorous in the entire lifecycle.

Because AI models are not subject to SOC 1 audits, control owners cannot rely on third-party assurance over the model's outputs. Instead, they must perform incremental, manual verification procedures each time the AI prompt is executed: agree the totals, amounts, and record counts the AI produces to the validated Stage 4 output; confirm no scope limitation was inadvertently embedded in the prompt; review the selection and filtering criteria for appropriateness; independently verify a sample of AI-generated calculations against the underlying data; and document the exact prompt, parameters, and inputs used so the control can be shown to have run consistently across periods.

Think of Stage 6 as analogous to Stage 5 (User Changes): just as a preparer must validate manual changes made in Excel, a control owner must validate the changes, both explicit and implicit, made by the AI to the data. The AI prompt output must be tied back to the validated IT application output, which in turn must tie to the source system. This chain of reconciliation is what provides auditable assurance over the completeness and accuracy of AI-generated analysis.

Evidence to retain: the documented prompt and inputs, plus the reconciliation to the validated input data.

Purpose-built tools are starting to make this a lot easier. The example below shows FloQast's Transform agents, where an AI routine is composed from predefined, individually reviewable steps (determine in-scope POs, calculate service periods, identify exclusions, and so on), and the agent's final output cannot be used until a human explicitly approves or rejects the run.

Structured prompting like this is a meaningful improvement over an open-ended chat box: the steps are explicit, repeatable, and easy to document, and the mandatory approval gate forces a human into the loop. Even so, it does not replace the reconciliation. The approve/reject decision is only as good as the verification behind it, so the control owner must still tie the agent's output back to the validated input before relying on it.

Stage 7: AI Generated Output

The final stage is the AI's output itself, the file or analysis that actually feeds the control. The temptation is to trust it, because it looks polished and arrived in seconds. Resist that: treat it exactly as you would a report from a system with deficient ITGCs, complete and accurate only once you have independently proven it, never on the model's say-so.

Recommended procedures include reconciling the record count in the AI output to the record count in the input data provided to the AI; agreeing key control totals (e.g., sum of amounts, number of transactions) in the output to the corresponding totals in the validated input; retaining both the AI output and the input data as evidence, along with documentation of the reconciliation performed; and, for high-risk or high-dollar controls, having a second reviewer independently verify the output against the source data rather than relying solely on the preparer's review.

Evidence to retain: the reconciliation, the output file, and reviewer sign-off.

It is worth emphasizing that the primary risk at this stage is completeness: the AI may silently exclude records that do not fit a pattern, that fall outside an implicit assumption in the model, or that were simply not processed due to a model limitation. Unlike a system error that might produce an obvious anomaly, an AI omission can be difficult to detect without a systematic record count reconciliation. Control owners should treat any unexplained discrepancy in record counts as a red flag requiring escalation.

Practical Guidance for Control Owners and Preparers

The following principles summarize the practical implications of this framework for day-to-day execution:

1. Treat AI as an Untrusted System

No matter how sophisticated the AI model, it must be treated as if it were a system with deficient ITGCs. This is not a commentary on the quality of the AI; it is a recognition of the fact that no external assurance (SOC 1) exists over its outputs. Every AI-generated output used in a control must be independently validated.

2. Build a Chain of Reconciliation

The gold standard for AI-integrated IPE validation is a complete chain of reconciliation: source system → IT application output → user-modified data → AI input → AI output. Each link in this chain must be validated. If any link is broken, the integrity of the entire chain is compromised.

3. Document the AI Prompt

The AI prompt is, in effect, the "report parameter" for an AI-generated output. Just as control owners document the parameters used to generate a system report (Stage 2), they must document the exact prompt used to generate an AI output. This documentation should include: the full text of the prompt; the date and time it was executed; the model or tool used; and the data inputs provided. Without this documentation, the control cannot be demonstrated to have been executed consistently.

4. Perform Reconciliation Every Time

AI models can produce different outputs for the same input depending on model updates, temperature settings, or other non-deterministic factors. Control owners should not assume that an AI tool that produced accurate results last quarter will produce accurate results this quarter without re-validation. Reconciliation procedures must be performed each time the AI prompt is executed as part of a control.

5. Maintain Appropriate Evidence

For each stage in the lifecycle, control owners should retain sufficient evidence to demonstrate that completeness and accuracy procedures were performed. At a minimum, this includes:

• Screenshots of report parameters (Stage 2)
• Record count and amount reconciliations for system exports (Stage 4) and AI outputs (Stage 7)
• Documentation of the AI prompt and input data (Stage 6)
• Annotated workpapers showing computation and categorization validation (Stages 5 and 6)
• Reviewer sign-off, particularly for high-risk controls

Key takeaway for auditors. When evaluating the design and operating effectiveness of controls that incorporate AI-generated outputs, auditors should assess whether management has implemented manual compensating controls at each stage of the AI-integrated data lifecycle. The absence of a SOC 1 report for the AI model does not mean the control is automatically deficient, but it does mean that management must demonstrate that it has independently validated the completeness and accuracy of AI outputs through manual procedures, and that sufficient evidence of those procedures has been retained.

Conclusion

The efficiency gains from AI-assisted data analysis are real, and organizations that learn to integrate AI into their control environments in a well-governed way will have a meaningful advantage. But those efficiency gains cannot come at the cost of control integrity.

The framework presented in this article is designed to help control owners, preparers, and auditors navigate the intersection of AI and SOX compliance. It is grounded in existing IPE principles and extends them to address the unique risks that AI introduces, particularly the absence of third-party assurance over AI outputs and the risk of silent omissions in AI-generated data.

The core message is straightforward: AI-generated outputs used in controls must be validated manually, the prompt must be documented, and the chain of reconciliation from source system to AI output must be complete and auditable. Organizations that establish these practices now will be well-positioned as AI adoption accelerates and as auditors and regulators begin to develop more specific guidance on the topic.

---

About this article. This article is intended for informational purposes and reflects the author's professional judgment based on existing SOX and audit standards as of the date of publication. It does not constitute legal, accounting, or auditing advice. Readers should consult their auditors, legal counsel, and relevant professional standards when designing controls for their specific environments.