Key reports and IPE in SOX: what auditors test before relying on a report
When a SOX control depends on a system report, query or spreadsheet, auditors must test the completeness and accuracy of that information before they rely on it. PCAOB AS 1105 (paragraph 10) requires an auditor using company-produced information to test its accuracy and completeness, or the controls over them, and to judge whether it is precise and detailed enough. Staff Audit Practice Alert No. 11 applies the same logic to controls that use system-generated data: supporting the control means testing both the control and the controls over the data. This page does not set a cost or duration for that work, because both depend on the report and its source. The answer changes with three things: the source system that generates the data, the logic and parameters used to extract it, and how much the control relies on the output. A quarterly aging report that a reviewer checks line by line carries different risk from a report that feeds an automated calculation without review. Management owns the report, its completeness and accuracy controls, and the decision about how much reliance to place on it. DeployOpen prepares systems, configurations and evidence for that testing. Only the external auditor issues the opinion on ICFR.
Practically, start by listing every report, query and spreadsheet that a key control uses, then record the application, report writer or database that produced each one. Confirm with your auditor which ITGCs over that source they expect to test, and ask how they will test the extraction logic and parameters. Staff Audit Practice Alert No. 11 describes inspection findings where firms tested an in-scope application but not the report writer or custom query that produced the data, and where ITGC deficiencies were found but not addressed. Those gaps are the ones to close before fieldwork. Also confirm with the auditor what evidence they accept for parameter values, population totals and changes to query logic, since those details decide whether the report can be relied on at all.
Which IPE gaps PCAOB inspections keep finding
PCAOB Staff Audit Practice Alert No. 11 describes recurring failures in how firms test information produced by the entity. The five gaps below each pair a failure with the check that closes it, and they share one thread: a report is only as reliable as the systems, logic and controls behind it.
ITGCs over the source application
Firms tested a control that relies on a report but never tested the general controls over the application that generated that report. The report looks clean, yet access, change and operations weaknesses in the source system can alter what it shows. Check that access, change and operations ITGCs cover the generating application for the period the report supports the control, and that the population was produced by that system rather than rekeyed.
Query and parameter logic
Inspections found firms that tested the output of a query without testing the logic that extracted the data. A filter on dates, status codes or thresholds can quietly drop records. For each report, obtain the query or report definition and the parameter values used, read the logic against the control's objective, and confirm that changes to that logic are covered by change management.
Customized reports outside tested ITGCs
Some engagements planned to rely on ITGCs that covered the core system, but the reports and queries built on top of it were customized and never came within those tests. Custom code, modified templates and added fields sit outside the tested population. Inventory the customizations, map each to the ITGCs that govern it, and extend testing or add coverage where none exists.
Report writers and spreadsheet tools
Firms found ITGCs ineffective but did not test the report writers, query tools and spreadsheets used to produce the data. Spreadsheets with locked formulas, shared files and manual copy-paste steps carry the same integrity risk as a system report. Identify which tools produced the population, test access to and changes in those tools, and review the formulas or macros that transform the data.
Unaddressed ITGC deficiencies
Some firms identified ITGC deficiencies during their work and did not address them before relying on the reports those systems produced. A known weakness in access or change control undermines the completeness and accuracy conclusion for every report from that system. Document each deficiency, evaluate its effect on the reports used in controls, and either remediate it or design compensating procedures before concluding on the report.
Why ITGCs over the report source decide whether the report can be relied on
A report is only as reliable as the system, data and logic that produced it. When a key control depends on a report, such as an aging listing, a exception report or a reconciliation population, the auditor will not accept the output at face value. The report's accuracy and completeness rest on the IT general controls over the source application, the database behind it and the report writer or query tool that extracted the data. If access to those components is loose, if changes to them go unreviewed, or if batch jobs that feed them can fail silently, the report can look correct and still omit or distort records.
Start by listing every report and query that a key control uses, then trace each one back to its components. For each, identify the application that generated the underlying data, the database tables it reads, the report writer or scheduled query, and the parameters or reference files that drive the output. PCAOB AS 2201 (paragraph B30) notes that automated application controls may depend on related files, tables, data and parameters, such as a rate table used by an automated interest calculation. A changed rate table or a modified parameter can alter results without any change to program code, so access and change controls must reach those files too. Confirm with your application and database administrators who can write to each of these objects and whether those changes flow through the same approval path as code changes.
AS 2110 (Appendix B, paragraph B4) also lists inappropriate manual intervention as an IT risk. Spreadsheets that are exported, edited and re-saved before a control runs are a common path for this risk, and they sit outside the application's own controls. Ask whether anyone adjusts report output by hand, whether those adjustments are logged, and whether the people making them are independent of the control being performed. Where manual intervention cannot be removed, document who makes it, what they change and how a second person checks it, so the auditor can evaluate the control rather than assume it.
How a key report moves from identification to tested evidence
This sequence takes a system-generated report from the moment a key control depends on it to the point where management and the auditor hold evidence that the report is complete and accurate. Each step produces a record that the next step relies on.
Identify reports used in key controls
During the top-down risk assessment, management lists every report, query or spreadsheet that a key control uses as input, such as an exception listing, aging report or reconciliation population. Process owners and the control owner confirm the list against the control narrative. The output is an inventory that maps each report to the control it supports and the financial assertion it protects. The step is complete when no key control relies on an unlisted data source.
Document the source system and report logic
For each report on the inventory, the control team records the source application and database, the tables or fields pulled, the query or report writer logic, and every parameter or filter that changes the output. It also records who can create, edit or run the report and who can change its parameters. The output is a report specification that a tester can follow without asking the process owner. Management confirms the specification matches the report as it currently runs.
Test ITGCs over the source and report writer
The IT team and the tester evaluate the access, change and operations controls over the application that generates the data, the database holding it, and the report writer or query tool used to build the output. Testing covers who can alter queries or parameters and whether those changes follow the change process. Staff Audit Practice Alert No. 11 points to firms that tested the application but skipped the report writer, so both layers belong in this step. The output is a conclusion on whether those ITGCs are effective, or a deficiency that feeds into the next steps.
Test the logic of queries and parameters
The tester checks that the query logic and parameters produce the population the control intends, such as the right date range, entity, currency or status filters. Where a parameter is changed manually before a run, the tester evaluates whether that manual intervention is controlled. The output is a documented result showing that the logic was reviewed against the control objective, with any unexpected filters or hard-coded values recorded as findings.
Test completeness and accuracy of the output
The tester compares the report output to independent source totals, such as general ledger balances, system record counts or a sample traced back to transaction detail. Differences are investigated and explained. The tester also judges whether the report is precise and detailed enough for the control to work as designed. The output is a completeness and accuracy workpaper that states the population size, the reconciliation performed and the result. A report that fails reconciliation is not relied on until the cause is resolved or the control is retested.
Address deficiencies in the report chain
When an ITGC over the source or report writer is ineffective, or the report fails completeness and accuracy testing, the team evaluates the effect on each dependent key control. Management decides whether to remediate, replace the report with a more controlled source, or add a compensating control. The output is a written deficiency evaluation that identifies the affected controls, the severity assessment and the remediation owner, so that the report chain is not treated as reliable by default.
Retain the test evidence and generation support
The team files the report specification, the screenshots or exports showing access and change settings, the query code and parameter history, the reconciliation workpapers and the report generation log with the control's evidence. Retention should allow the auditor to re-perform the run and trace the output to source. The output is a complete evidence package per report that another person could use to reproduce the result. Confirm retention periods and format with the external auditor before the assessment starts.
Testing spreadsheets, custom queries and report writers differently
Spreadsheets used in financial controls are often end-user computing tools, so the auditor tests them as controls in their own right rather than as neutral calculators. The question is whether the file produces the same result every time from the same inputs, and whether anyone can change the logic without detection. Testing usually starts by identifying every spreadsheet that feeds a key control, then examining who can edit it and how changes are approved.
- Inventory and classification: List each spreadsheet that feeds a key report or control, with its owner, purpose and the control it supports.
- Locked formulas: Confirm that calculation cells are protected, that hard-coded overrides are absent or logged, and that the protection settings match the documented version.
- Change control on the file: Request the approval record, version history and the reviewer's sign-off for any formula or structural change during the period.
- Access to edit: Check who holds edit rights on the file repository and whether that access is reviewed like other application access.
- Independent recalculation: Auditors often recompute a sample of outputs from source data to confirm the file's results.
Before the audit, confirm with the control owner which spreadsheets the auditor will treat as in scope and whether the repository itself is covered by access and change ITGCs.
Custom queries, scripts and stored procedures extract or transform data that a control later relies on. Their logic is code, so auditors test it like code: they examine what the query does, who can change it, and whether the data it reads is complete. A query can return a clean-looking report while silently excluding records, so the logic review matters as much as the output check.
- Logic review: Obtain the query text and walk through its joins, filters, date parameters and exclusions against the control's stated objective.
- Parameter review: Confirm who sets run-time parameters, such as date ranges or entity codes, and whether the values used are recorded.
- Version control: Request the repository history showing when the query changed, who approved the change and whether the version run matches the version reviewed.
- Access to run or edit: Separate who can execute the query from who can alter it, and check that privileged database access is restricted and logged.
- Completeness checks: Compare record counts or control totals from the query against the source system to confirm nothing was dropped.
Confirm early whether the queries are stored in a version control system or in individual user folders, because the second arrangement usually creates a gap in change evidence.
Vendor report writers and built-in reporting modules are generally less customized than spreadsheets or scripts, but they still transform data and apply configured filters. Because the report depends on the application that generates it, the auditor tests the report's configuration and the access and change controls of the underlying application. Testing the report alone does not establish that its source data is reliable.
- Configuration review: Examine the report definition, selected fields, sort and filter settings, and any scheduled parameters, and compare them with the control's requirement.
- Access to the report writer: Confirm who can create, modify or schedule reports, and whether those rights are separated from transaction processing.
- Application ITGCs: Confirm that access, change and operations controls over the application that generates the report are effective, since weaknesses there undermine the report.
- Change to report definitions: Request evidence that changes to report logic were tested and approved, including upgrades that alter default behavior.
- Reproduction: Ask the entity to re-run the report for a sample period and show that the output matches the original.
Confirm with the vendor and your administrators which report writer version is installed and whether upgrades have changed any default report logic during the period.
What must be in place before the auditor selects a report
Auditors can only rely on a report after they have tested whether it is complete and accurate, and that testing depends on what the company already has in place. The checks below are the items a company should confirm before fieldwork, so the testing can start from documented facts rather than reconstruction.
Current inventory of reports and IPE
List every system-generated report, query and spreadsheet that a key control uses or that supports a control's precision. For each item, record the source application, the control it supports, the owner and the last date the logic was reviewed. Auditors start from this list, so a missing item often becomes a missing control. Check it against the control matrix, not only against the reporting team's own catalog.
Documented query and parameter logic
For each report, write down the selection criteria, filters, date ranges, joins and parameter values that produce the output. Name the owner who can explain them. Auditors test whether this logic is correct, and reports often depend on parameters that someone changed without recording it. Confirm that a person outside the preparing team can read the logic and reproduce one sample result.
ITGCs over the report source
Confirm that access, change and operations controls over the application, database and report writer that generate each report were tested and found effective for the period. If a general control failed, document how the deficiency was assessed and whether the report can still be relied on. Auditors expect to see this link made explicitly, not assumed.
Change records for report logic
Keep approved change tickets for any modification to report code, query text, parameter tables or spreadsheet formulas, including the tester and approver. Compare the change dates with the period under audit. Changes made directly in production or in an unmanaged spreadsheet are a common reason auditors cannot rely on a report without additional testing.
Retained completeness and accuracy evidence
Keep dated evidence that management checked each report for completeness and accuracy before using it, such as reconciliations to source totals, record counts, or re-performed extracts. Record who performed the check, what they compared and what exceptions were resolved. Auditors examine this evidence for the whole period, so retention rules should cover the full fiscal year plus the testing window.
Who is paid for key report and IPE work
This table separates the cost components of testing key reports and information produced by the entity (IPE) in a SOX audit, showing who is paid for each, whether the cost is one-time or recurring, and what drives it up. Use it to build a quote request that itemizes internal time, partner work, tooling and the external auditor's testing separately. No fees or durations are stated because none were supplied for this topic.
| Cost component | Who is paid or who bears it | One-time or recurring | Main cost drivers |
|---|---|---|---|
| Internal inventory and documentation of reports | Internal staff time (finance, IT and control owners) | One-time, then updated when reports change | Number of key reports, number of source systems, and how often report logic changes |
| Query and report logic review | Internal IT or an implementation partner, depending on who has the skills | One-time, with retesting after changes | Query complexity, use of custom report writers, and undocumented parameters |
| Preparing system logs and ITGC evidence for report sources | Implementation partner work and internal system owners | One-time setup, then recurring evidence collection each cycle | Number of in-scope applications, logging maturity, and how many systems feed each report |
| Spreadsheet and end-user computing controls | Internal control owners, with optional partner support for tooling | Recurring as spreadsheets are created or modified | Number of spreadsheets used in controls, version control practices and access restrictions |
| Tooling for hashing, logging or report comparison | Software licensing or open-source tool operation, paid to vendors or internal staff | Often one-time setup with recurring operation | Whether tools are open source, licensed, or already in use, and how many reports they cover |
| External auditor testing of reports and IPE | The external auditor, whose fee is set by the auditor and not by this page | Recurring each audit cycle | Number of key reports tested, sample sizes, and whether ITGC reliance is planned |
Who owns the report, who prepares the evidence and who tests it
Management owns the controls and the reports those controls rely on. Under SEC guidance management must evaluate the ICFR it relies on, and the auditor will test whether management's report inventory and testing are reliable. The company keeps the accountability for every spreadsheet, query and system report used in a key control, even when a partner builds or hosts the tooling.
- Report inventory: Maintain a list of every system-generated report, query, report writer output and end-user spreadsheet that feeds a key control, with its owner and source application.
- Logic documentation: Record the parameters, filters, joins and calculations behind each report, and approve changes to that logic.
- ITGC evidence: Keep access, change and operations evidence for the application, database and infrastructure that produce each report.
- Completeness testing: Perform or review the reconciliations and population checks that show the report is complete and accurate for the period.
- Usually kept in house: Control ownership, sign-off on the report inventory and the final judgment on whether a report is reliable.
Check that each key report has a named owner who can explain its logic to an auditor without outside help.
An implementation partner such as DeployOpen prepares systems and evidence inside the client's own infrastructure. It does not own the controls, and it does not issue audit reports, opinions or attestations. Its work supports the company's team and the auditor's testing, and the scope for that work is agreed in writing before it starts.
- Report inventory: Help identify reports and queries produced by self-hosted platforms and document where each one is generated.
- Logic documentation: Extract and document query logic, report definitions and parameter configuration from the platform so the company can review them.
- ITGC evidence: Configure logging, retain access and change records and prepare exports that show the layers under a report are controlled.
- Completeness testing: Build reconciliation scripts or evidence packages that the company can run and review, while the company keeps responsibility for the result.
- Usually outsourced: Platform configuration, evidence collection tooling and technical documentation. Confirm with the partner which items it will hand over as deliverables and which remain with the company.
Ask for the deliverables in the written scope, including who receives them and who signs off.
The external auditor tests the company's ICFR under PCAOB AS 2201 and uses AS 1105 to decide whether information produced by the company is reliable enough to use. The auditor tests the report, the controls over its accuracy and completeness, or both, and must evaluate whether the information is precise and detailed enough for the purpose. The auditor is independent of the company and of any implementation partner.
- Report inventory: Review management's list of reports and challenge any report used in a key control that is missing from it.
- Logic documentation: Test the logic of queries and parameters used to extract report data, not only the output.
- ITGC evidence: Test the ITGCs over the applications that generate the reports, including the report writers and databases beneath them.
- Completeness testing: Test accuracy and completeness directly or test the controls over them, and document the conclusion.
- Independence boundary: The auditor may not design or prepare the company's controls or evidence in a way that makes it audit its own work.
Confirm early with the auditor which reports it will select and which testing approach it expects.
Questions about SOX key reports and IPE testing
What does IPE mean in a SOX audit?
IPE stands for information produced by the entity, meaning any report, query, extract or spreadsheet the company generates from its own systems and then uses in a control. Auditors treat it as evidence that must be reliable before they can rely on the control that uses it. A standard system report, a custom query that pulls transactions, and a spreadsheet that sums balances all count. The question auditors ask is whether the information is complete and accurate for the purpose of the control, and whether the logic used to produce it can be trusted. Management owns the answer, and the external auditor tests it under the same logic described in PCAOB AS 1105.
Does every spreadsheet used in a control need testing?
No. Only information that a key control relies on needs testing, and the depth of testing follows how much the control depends on it. A spreadsheet that feeds a reconciliation of a significant account is in scope, while a scratch file used for personal planning is not. Start from the key controls in your top-down risk assessment, list every report, query and spreadsheet each control uses, and record who produces it and where the data comes from. Items that are only used for operational efficiency, and that do not affect the financial reporting risk, usually fall outside the evaluation. Confirm the boundary with your auditor before fieldwork.
What does the auditor need from the company for key reports?
The auditor needs a documented population for each report, evidence that the report is complete and accurate, and an explanation of the parameters used to produce it. Typically this includes the report definition or query logic, the source system and tables, the date and parameters used, and a reconciliation or completeness check against the source. Auditors also expect the ITGCs over the source application to be effective, including access, program changes and computer operations, because a report is only as reliable as the system that produced it. Keep records of who can edit queries and parameters, and how changes to report logic are approved.
How many reports drive the testing effort?
The number of reports that a key control depends on drives the effort, followed by how often each report changes and how many systems produce them. A company with a few standard reports from one stable application has a much smaller task than one with custom queries spread across several databases and report writers. Each report that is relied on needs its own completeness and accuracy evidence, and each custom query needs logic review. Effort also grows when report logic changes during the year, because the change must be tested as well. Ask your advisor to inventory reports by control and by source system before estimating hours, since the inventory determines the scope.
Can a partner prepare the evidence for key reports?
A partner can prepare systems, documentation and evidence, but the company still owns its controls and the external auditor alone decides whether the evidence is sufficient. Typical preparation includes inventorying reports, documenting query logic, setting up version control for report definitions, building completeness checks and collecting the ITGC evidence over the source systems. DeployOpen implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so it can prepare that evidence for those platforms. It does not issue audit reports or attestations. Scope and deliverables are agreed in writing before work starts.
What should we confirm with the auditor before fieldwork?
Confirm which reports and spreadsheets the auditor considers relied on, the population and sample expectations, and the completeness and accuracy procedures they will accept. Ask how they want query logic and parameters documented, whether they will test the report writer or database layers, and how they handle reports that are produced by a vendor. Also confirm how the auditor will treat changes to report logic during the year and what evidence supports a benchmark. Get these answers in writing, because they shape the evidence you need to collect and the order in which to prepare it.
How DeployOpen prepares report sources and IPE evidence for the audit
DeployOpen starts by putting the report inventory in writing. For each key report, query and spreadsheet that management relies on, the scope document records the source system, the data tables or extract the report reads, the parameters and filters applied, the person who runs it and the control that uses it. That list also names the ITGCs over the systems that generate and modify the data, such as access, program change and computer operations controls for the application, its database and the layers beneath it. Agreeing this scope before work starts lets management see which report-producing systems will be tested and which are out of reach of the engagement.
Next, DeployOpen documents the logic and hardens the controls that protect the source. Report writer and query definitions are exported and reviewed against their stated purpose, and any hardcoded values, manual overrides or edited extracts are flagged for management to explain or remove. Where the ITGCs over the source are weak, DeployOpen configures and checks the controls that protect it, including restricted write access to report definitions, logging of changes to queries and parameters, and scheduled reruns that confirm completeness against control totals. Management still decides which deficiencies to disclose and how to remediate them.
The engagement ends with an evidence pack for the company and its auditor: the report inventory, source and logic documentation, screenshots or exports showing configuration and change history, and the completeness and accuracy test scripts with their results. DeployOpen does not issue reports, attestations or certifications. Independent auditors and certification bodies test the evidence and form their own conclusions, and management owns the assertion. A quote follows a written scope that lists the reports, systems, locations and deliverables in the engagement.
