Home / Blog / IPE and report reliance

IPE and report reliance in SOX audits: getting IT-dependent controls right

Walk through almost any "manual" control in a SOX file and you'll find a system inside it. The controller reviews a reconciliation — built from a general ledger export. The manager approves the aging analysis — generated by the ERP. The payroll review compares this month to last — using a report someone configured years ago and nobody has looked inside since.

That embedded system output is IPE — information produced by the entity — and it's where more SOX findings originate than almost anywhere else, for a simple reason: a perfectly performed review of a wrong report is a control that doesn't work. The reviewer's diligence is irrelevant if the population they reviewed was incomplete.

External auditors have tightened on this steadily, and PCAOB inspection findings keep feeding the pressure. If your program treats IPE as a footnote, this is the area most likely to generate uncomfortable questions in the fall.

What counts as IPE

Anything system-generated that a control relies on:

The practical test: if this system output were wrong or incomplete, would the control still achieve its objective? If not, the output is IPE and needs support.

What "relying on a report" actually requires

For each key report a control depends on, you need a story with three chapters, and teams routinely write only the first:

1. Baseline the report's logic. Once, establish that the report does what everyone believes: the query logic matches its purpose, the population criteria are complete (that aged receivables report includes all AR sub-ledgers, including the entity migrated last year), and calculations are right. For custom reports this means examining the logic or reconciling output to source data. Document it as its own piece of work — a report-reliance memo or an IPE workpaper — not as a sentence inside someone's test.

2. Establish that the logic stayed put. A baseline from March says nothing about October unless something constrains change. That something is ITGCs: change management over the application (report modifications are controlled) and access security (who can alter report logic or the underlying data). This is the load-bearing connection — report reliance is only as good as the ITGCs over the application that produces the report. If ITGC testing fails for that application, every control relying on its reports inherits the problem, and the baseline has to be replaced with period-specific validation, which is expensive.

3. Evidence the specific instances. For each tested control occurrence: which report, run when, with what parameters, and did the performer do anything to check it (row counts, reconciliation to the GL, sanity checks)? A screenshot of the report header with parameters visible costs the performer ten seconds and saves the file a finding.

Spreadsheet manipulation adds a fourth chapter — evidencing that the filtering and formulas didn't drop rows or mangle values — which is why the best fix for spreadsheet-heavy IPE is often eliminating the spreadsheet step, not documenting it.

The failure mode isn't ignorance — it's disconnection

Here's the thing: most SOX teams know all of the above. The findings still happen, because the knowledge lives in disconnected places:

The result is the classic gap: an application whose reports feed three key controls, sitting outside ITGC scope because no document connects the dots. Nobody decided to skip it. The chain just never existed anywhere except in fragments.

Making the chain a living thing

The fix is structural, not motivational: the walkthrough-to-ITGC chain has to exist as one navigable object, maintained as part of normal work rather than reconstructed for the auditors.

Concretely, that means being able to answer, at any point in the year, in minutes:

  1. Per walkthrough: which IT dependencies did this process surface — reports/IPE, automated controls, interfaces, calculations?
  2. Per dependency: which application produces it?
  3. Per application: is it in ITGC scope, and which ITGC controls cover it?
  4. Per ITGC control: what's its current test status — and if it failed, which business controls upstream are exposed?

Question 4 is the one that matters in October. When an ITGC deficiency lands, the first question is the blast radius: which reports, which controls, which assertions. Teams with a maintained chain answer it the same afternoon. Teams with a static scoping memo from February spend two weeks re-interviewing process owners — during the busiest month of the year.

A spreadsheet can hold this chain, and for a small environment it's a legitimate starting point. Its weakness is that it only reflects reality on the days someone updates it, and drill-back (from an application to everything relying on it) means Ctrl+F and prayer.

This chain is, candidly, the reason SoxDesk exists. Walkthroughs capture IT dependencies as structured items typed as report/IPE, automated control, interface, or calculation; each dependency links to its application; applications flow into an ITGC scoping view that flags in-scope applications with no ITGC coverage; and the links drill back both directions — from a walkthrough down to applications, or from an application up to every dependency and process relying on it, with the live test status of covering ITGC controls shown in place. When someone adds a dependency in June, the scoping view reflects it in June.

A 90-minute self-assessment

Whether or not you change tooling, run this exercise before your external auditors do:

  1. List your key controls and mark every one that consumes system output. (Expect a majority — if you marked few, the walkthroughs are underselling the dependencies.)
  2. For each marked control, name the specific report and the producing application. Every "not sure" is a gap in the file.
  3. Compare that application list to your ITGC scope. Applications feeding key controls but sitting outside scope are your urgent findings — self-identified is a far better look than auditor-identified.
  4. For each key report, check whether a baseline exists and whether instance-level evidence (parameters, completeness checks) appears in the testing.
  5. Ask who maintains this mapping when things change mid-year. If the answer is a name rather than a process, you've found the root cause.

Most teams that run this find at least one application in category 3. Finding it in July is a scoping update; finding it in January is a deficiency evaluation.

SoxDesk is an on-premise workflow app for SOX and internal audit teams. Its IT Linkage view keeps the walkthrough → dependency → application → ITGC chain connected and current, with coverage gaps flagged automatically — and all data stays on your own network. The 60-day free trial is the full product, sample audit included: soxdesk.com.