Financial reporting is often derived from information systems that rely heavily on automated processes, increasing the importance of system and data integrity. If IPE is inaccurate or incomplete, any conclusions based on it may be invalid—even if the audit procedures themselves were well designed, as lack of sufficient testing to determine completeness and accuracy of IPE can result in inaccurate conclusions such as effectiveness of controls or insufficient and appropriate audit evidence when performing substantive testing.
IT audit procedures help support the financial and Internal Control over Financial Reporting (ICFR) audit opinion by testing and concluding on controls that address the risks surrounding how systems impact financial reporting. For discussion surrounding the importance of management procedures and controls to validate IPE’s integrity see our insight Understanding and Managing Information Produced by the Entity in Audits.
Depending on how the systems are used and information generated from the information systems, risks that need to be addressed can include but may not be limited to automated calculations, interfaces between systems, and system-generated reports, that may be used in control and/or substantive testing.
No matter if IPE is used as an input or output to a control, or used when performing substantive procedures, auditors need comfort that the IPE is complete and accurate.
What is IPE?
Information Produced by the Entity (IPE) is information generated internally by an entity’s systems, processes, or personnel. It can be system-generated, manually prepared, or a hybrid of both.
Common types of IPE include:
- System-generated reports: AR/AP aging, inventory valuation, trial balance, revenue exception reports
- User-extracted data extracts: SQL queries directly from information system database or BI exports used for close and reporting
- Manually prepared spreadsheets: flux analyses, journal entry support, Tax provisions, Warranty reserve models
- Reconciliations and operational schedules: cash reconciliations, amortization schedules, close checklists supported by internal listings
If information is created internally or obtained indirectly in electronic format from a third-party and is used in the execution of a control or is used by audit teams in their substantive testing, it should be treated as IPE and considered for evaluation.
Why Does IPE Matter?
Auditors commonly rely on IPE for both substantive procedures and control testing. For example, IPE may be used to:
- Determine populations for sample-based control testing (e.g., all journal entries posted or all invoices paid during period)
- Perform analytics (e.g., trend reports, exception reporting, fluctuation analyses)
- Validate balances and disclosures (e.g., subledger aging supporting receivable reserves)
Clients likewise rely on IPE when executing controls, including:
- Management review controls (variance/flux review supported by system-generated reports)
- Reconciliations (subledger-to-GL, system-to-system tie-outs)
- Monitoring controls (exception dashboards, access activity listings, change logs)
IT Systems and the Reliability of IPE
The reliability of IPE is inseparable from the reliability of the IT systems that create, process, and present that information. When IPE is inaccurate or incomplete, audit procedures may be misdirected, controls may appear effective when they are not, and the risk of undetected material misstatement increases. IPE reliability is influenced across the full data lifecycle:
- Generation – Data is captured within the system through data entry. Weak input validation and/or incomplete data entry can compromise IPE.
- Processing – Automated calculations, configurable logic, workflows, and batch jobs assist in translating source data into reporting outputs. Errors in configuration, calculation logic, or exception handling can result in inaccurate or incomplete results.
- Storage – Databases and data warehouses are used to store the data within the system. Risks related to data integrity, retention practices, and extraction methods can lead to incomplete or inconsistent reporting.
- Presentation – Reports and extracts rely on defined logic, parameters, filters, and formatting. Incorrect query criteria or report logic can cause relevant data to be excluded or misrepresented, even when underlying data is sound.
Common IT-related Risks That Can Affect IPE
Common IT-related risks include data integrity failures, unauthorized access or changes, system configuration or programming errors, and interface or data transfer breakdowns.
This is where Information Technology General Controls (ITGCs) and application controls play a safeguarding role. Strong ITGCs—especially around access, change management, and operations—help establish that systems and reports are produced in a controlled manner. Application controls (input, processing, and output controls) help ensure transactions and reporting outputs are processed as intended.
Addressing Completeness and Accuracy: A Practical Approach
Evaluating IPE does not need to be overly complex, but it should be intentional and risk based. The steps below represent an example of a practical approach that can be used in an external or internal audit setting:
Start by clearly identifying:
- How and where the IPE is generated (system/module/report/query)
- The systems that provide data to the IPE (source systems feeding the report)
- Any tools or files used after the IPE is generated (Excel reports or other downstream processing)
- Whether the IPE is produced:
- Directly from the system of record
- From a data warehouse/database
- Through exports to Excel with the opportunity for subsequent manipulation
This step prevents treating IPE as a report that cannot be changed when it is actually the product of parameters, queries, or processing logic.
Assess the IT control environment that supports the reliability of the IPE:
ITGCs
- Access: who can generate the report vs. who can modify the logic or underlying data?
- Change management: are changes to the report/query/configuration authorized, tested, and approved?
- Operations: are batch jobs and interfaces monitored, and are errors investigated and corrected timely?
Application controls
- Input controls: validations and edit checks
- Processing controls: automated calculations and workflow logic
- Output controls: controls over report generation and data integrity checks
The strength of these controls often drives how much direct testing of IPE completeness and accuracy is needed.
Procedures should be tailored based on how the IPE is used and the risk it addresses. Example procedures include:
- Identify the relevant data elements (fields, totals, status codes, dates, entity scope)
- Determine whether it is system-generated or manually prepared/manipulated
- If system-generated, consider whether the report/query changed during the period (identify the change date/version)
- If manual/hybrid, consider spreadsheet integrity and whether there is an audit trail to source data
Perform source-to-report and report-to-source testing
- Trace selected source transactions into the report to confirm completeness
- Select items from the report and vouch back to source records to confirm accuracy
Re-perform or recalculate outputs where relevant
- Recompute key calculations (aging, classifications, totals, thresholds) for selected items
When issues are found:
- Document the exception and assess the impact on:
- Control reliance (integrated audit/ICFR)
- Audit evidence sufficiency and appropriateness (substantive testing)
- Consider compensating controls or alternative procedures
- Independent reconciliations, additional corroboration, expanded testing, or revised audit approach
Practical challenges (and How to Manage Them)
Audits commonly encounter recurring IPE issues, such as:
- Inconsistent report parameters across users or periods
- Custom queries or logic changed without controls in place
- Data warehouse/database outputs not reconciled to the system of record
- Interfaces that fail or partially load without clear evidence of resolution
- Excel exports that are filtered, edited, or overwritten without traceability
- Excessive access allowing unauthorized data/report changes
To mitigate late-stage IPE risks, the auditor should consider whether:
- IT and business professionals at the company are involved early to identify key IPE used in controls and audit procedures
- An IPE inventory is maintained, including the owner, source system, report name, parameters, and evidence retained)
- Appropriate report change controls exist for critical IPE including a formal change process, restricted access, and periodic validation)
- Appropriate access and review controls exist over spreadsheets where spreadsheet use is unavoidable, including standardized templates, locking, version control, and independent review)
IPE is often treated as “just a report,” but in many audits it is the backbone of both control execution and audit evidence. Understanding the IT systems that produce IPE and addressing the completeness and accuracy risks through a combination of ITGC evaluation, application control understanding, and targeted testing, helps auditors and internal audit teams maintain audit quality, reduce rework, and support reliable conclusions. To help assess IT risks and controls underlying critical IPE, connect with our Technology Risk Assurance team to support reliable audit evidence and efficient audit execution.