Every finance function runs on spreadsheets and other tools that nobody in IT built, tested or controls, and every year one of them produces a number that turns out to be wrong. The category is called end-user computing, and the audit of it fails at the first step more often than any other IT-adjacent audit, because the population cannot be found by asking. This guide is the program for auditing it: what counts as an EUC, how to build the inventory when discovery seems impossible, how to tier the inventory so the controls land on the files that matter, what the controls for a critical EUC are and how to test them, how to prioritize migration into systems, and how to run the engagement, with a controls checklist and a worked example at a bank whose deferred-fee spreadsheet had just cost it a significant deficiency.
In this guide
- Why end-user computing keeps producing wrong numbers
- What counts as an EUC
- Discovery and inventory: the impossible first step, made practical
- Risk-tiering the inventory
- What regulators and standards expect
- Controls for critical EUCs
- Testing the EUC program
- Migration-to-system prioritization
- The EUC controls checklist
- Worked example: Lakeshore Bancorp after the deferred-fee error
- Common mistakes
- Related guides
Why end-user computing keeps producing wrong numbers
An enterprise application has a change process, an access model, a test environment, a backup and somebody whose job is to keep it working. A spreadsheet has a person, and when the person is busy, on leave or gone, it has nobody. The failure modes follow directly: a formula edited in one cell and not the rest of the column; a range that stopped one row short when the data grew; a link to a file that moved; a macro nobody can read that was written by someone who left in 2019; an input pasted from the wrong month; a hidden sheet with a manual override that was meant to be temporary; a version emailed around until three people are working from three different truths. None of these is exotic, and the most public example remains the one JPMorgan’s own management task force described in its January 2013 report on the Chief Investment Office losses: a value-at-risk model operated through a series of spreadsheets with manual copying between them, in which an operational error divided by a sum where it should have divided by an average, understating the volatility the model reported. Large institutions have spent the decade since building EUC programs because that report made the risk undeniable; smaller organizations mostly have not.
For financial reporting the exposure is direct. Most of the reports and schedules that key controls depend on pass through a spreadsheet somewhere between the system and the reviewer, which makes EUC integrity part of the information-produced-by-the-entity problem the IPE testing guide covers, and a spreadsheet error that a review control did not catch is evaluated as a control deficiency like any other, as the deficiency evaluation guide shows with exactly that case. For banks, the overlap with model risk is explicit: a spreadsheet that estimates, forecasts or prices is a model, and the model risk guidance that replaced SR 11-7 in April 2026 (Federal Reserve SR 26-2 and OCC Bulletin 2026-13) expects it to be in the model inventory with validation proportionate to its risk. The EUC program and the model inventory overlap, and the audit should test that the overlap is managed rather than duplicated.
What counts as an EUC
An EUC is any application, tool or file developed, maintained or operated by business users outside the change management, access control and operational controls that IT applies to enterprise systems, where the output is used for a business, financial reporting, regulatory or decision purpose. The definition is by control environment, not by technology, which is why it catches more than spreadsheets. A policy needs the definition and the scope statement, because the first thing an inventory exercise produces is an argument about whether a particular tool is in.
| EUC type | Typical uses | Characteristic failure modes |
|---|---|---|
| Spreadsheets | Reconciliations, accruals, allowances and reserves, roll-forwards, allocations, regulatory schedules, management reporting, pricing | Formula and range errors, broken links, manual inputs, version proliferation, hidden overrides, macro opacity |
| Desktop databases | Sub-ledgers for products the ERP does not handle, customer or asset registers, reporting marts built from extracts | Unlogged edits, no backup, single-user dependency, query logic nobody reviews |
| Scripts and notebooks | Data extraction, transformation, analytics, reconciliations written in SQL, Python or R by finance or risk staff | Environment drift, hard-coded parameters, silent failures, no version control, credentials embedded |
| BI dashboards and self-service reports | Management and board reporting, KPI monitoring, ad hoc analysis on warehouse data | Measure definitions that diverge from the ledger, filters applied silently, stale refreshes presented as current |
| Low-code apps, macros and automations | Workflow apps, approval routing, robotic process steps built by business teams | Business logic outside change control, ownerless bots running with a person’s credentials, undocumented exception handling |
| Model-like EUCs | Allowance and reserve estimates, valuation, forecasting, capital and liquidity calculations | All of the above plus conceptual soundness questions that require validation, not just control |
Discovery and inventory: the impossible first step, made practical
Asking business units to list their EUCs produces a short list of the ones people are proud of and none of the ones that matter. The practical method runs the other way: start from where the risk is, work back to the files, and use scanning to find what the process view missed. Six sources, combined, produce an inventory that can be defended.
| Source | What it yields | How to use it | Typical yield |
|---|---|---|---|
| Key control matrix and IPE inventory | Every spreadsheet or query that a key control depends on | Extract the information inputs for each IT-dependent manual control; each spreadsheet step is an EUC by definition | The highest-risk EUCs, almost complete for financial reporting |
| Close checklist and reporting calendar | Files used to prepare journal entries, disclosures and management reports | Walk each checklist step with the preparer and record the files opened | Accruals, allocations, roll-forwards, consolidation adjustments |
| Regulatory and external reporting maps | Schedules and workbooks behind regulatory returns, tax filings and covenant reports | Trace each reported figure back to its source; the last hop is usually a spreadsheet | High-materiality, low-frequency EUCs that nobody thinks of as controls |
| Model inventory and risk function registers | Estimation and forecasting tools already recognized as models | Reconcile the model inventory to the EUC inventory in both directions | The overlap population, plus models the model inventory missed |
| File share and collaboration scanning | Files by type, size, macro presence, external links, last modified date, owner, location | Scan finance, risk, treasury and operations shares; filter for macros, links to ledger extracts, and recent modification; confirm with owners | The long tail, and the shadow copies of files already inventoried |
| Process walkthroughs and self-declaration | Tools used in operational processes outside finance | Add an EUC question to every process walkthrough; run a declaration exercise with a definition, not a blank form | Operational EUCs (pricing, scheduling, inventory) that finance never sees |
The scanning step needs three decisions written down: which shares and repositories are in scope (including personal drives and email attachments, which is where the real versions live), which file characteristics trigger review (macros, external links, links to system extracts, size above a threshold, names matching close or regulatory processes), and who confirms each candidate. Scanning finds files; it does not find purposes, and a candidate list of several thousand files is only useful once the owners have said which ones produce numbers anybody uses. The funnel from candidates to confirmed EUCs is the inventory’s audit trail, and the auditor tests it by taking a sample of the rejected candidates and asking the owners again.
The inventory record for each confirmed EUC carries: name and location (one authoritative location, with the shadow copies noted for deletion), owner and backup owner, purpose and the process or report it feeds, inputs and their sources, outputs and their consumers, frequency of use, tier, the controls in place, and the last review date. Completeness is tested annually by re-running the discovery sources and reconciling the results to the inventory, the same way an asset inventory is reconciled to independent sources in the IT audit plan guide. An inventory that has never been reconciled is a list, not a control.
Risk-tiering the inventory
Tiering exists so that the controls land on the files that could hurt, and it needs criteria that two people would apply the same way. Four dimensions do the work: the materiality of what the EUC feeds (financial statements, regulatory reports, board decisions, customer-facing outputs, versus internal analysis), the complexity of the EUC (macros, external links, multiple sheets or tables, size, manual steps), the degree to which the output could be wrong without anyone noticing (whether a downstream control would catch an error, and at what precision), and the dependency on individuals (single owner, undocumented). Score each on a three-point scale, set tier thresholds, and record the score, not just the tier, so that re-tiering is a recalculation rather than a renegotiation.
| Tier | Criteria (typical) | Controls required | Review and testing |
|---|---|---|---|
| Tier 1: critical | Feeds financial statements, regulatory reports or key decisions above a materiality threshold; complex or macro-driven; no compensating downstream control at adequate precision; or classified as a model | Full control set: restricted access, version control, locked inputs and validation, change log with testing and independent review, documentation, backup, independent logic review at implementation and after changes, output reconciliation | Annual independent review; in scope for SOX or regulatory testing where relevant; model validation where model-like |
| Tier 2: significant | Feeds reporting or decisions below the Tier 1 threshold, or above it with a precise downstream control; moderate complexity | Access restriction, version control, input controls, change log, documentation, backup, output check by the reviewer | Periodic owner self-assessment with sample review by a second line or internal audit |
| Tier 3: low | Internal analysis, convenience tools, outputs re-performed or superseded by system reports | Inventory entry, owner, basic naming and storage standards | Inventory refresh only |
Two tiering rules prevent the common distortions. The materiality dimension is assessed on the potential error, not on the size of the file’s usual output: a small allocation spreadsheet that could reverse the sign of a segment’s profit is Tier 1. And a downstream control only reduces the tier if it has been tested at a precision that would catch the plausible error, which is the same precision question the management review controls guide applies to reviews generally; “the controller looks at it” is not a compensating control.
What regulators and standards expect of EUC control
No standard is titled “end-user computing”, but four sets of expectations reach it directly, and the audit’s criteria should cite them. For SOX programs, the PCAOB’s Staff Audit Practice Alert No. 11 of October 2013 named spreadsheets, queries and report writers as the information sources whose completeness and accuracy auditors had failed to test, and it remains the reference the external auditor will quote when a key control depends on a workbook; the practical consequence is that every Tier 1 EUC serving a key control is IPE and is tested as such. For banks, model risk guidance treats spreadsheet-based estimation tools as models: the April 2026 guidance from the Federal Reserve (SR 26-2) and the OCC (Bulletin 2026-13), which replaced SR 11-7, expects a complete model inventory and validation proportionate to risk, and examiners have long asked how the inventory captures models that live in spreadsheets. For risk data aggregation at large banks, the Basel Committee’s BCBS 239 principles expect accuracy and integrity in risk reporting with manual processes and adjustments minimized and controlled, which has made spreadsheet-based risk reporting a standing supervisory topic. And for every organization, the COSO framework’s principle 11, selecting and developing general controls over technology, applies to the technology the business built for itself as much as to the technology IT runs, which is the argument that puts EUC control inside the internal control system rather than beside it.
The auditor should also expect a specific counter-argument from the business: that the EUC is “just a calculation” and the control is the review of its output. The response is the precision question. If the reviewer would catch the plausible error, the review is a compensating control and the EUC can be Tier 2; if the reviewer works at a threshold above the plausible error, or reviews the output without re-performing anything, the EUC is the control and has to be controlled as one. The deferred-fee case at Lakeshore in the worked example below is the illustration: a $250,000 review threshold over a workbook whose formula error produced $1.4 million looks precise until the error is one the reviewer had no way to see.
Controls for critical EUCs
The control set for a Tier 1 EUC reproduces, at file level, the general controls an enterprise application gets from IT, and it is easier to design than to sustain, because every control depends on the owner’s discipline. Access means the authoritative copy sits in a location where read and write rights are managed, with the calculation sheets protected and the input cells the only ones editable by preparers; the access list is reviewed on the same cycle as application access, per the user access review guide. Version control means one authoritative file, a naming convention that identifies the version and period, prior versions retained read-only, and a rule against working copies; where the platform supports check-out and version history, those are the evidence. Input validation means inputs are pasted or linked into designated cells, reconciled to their source (control totals, record counts, a tie-out to the system report), constrained by data validation where the tool allows, and dated. Change control means a change log inside or alongside the file recording what changed, why, who made it and who tested and reviewed it, with logic changes tested against a known result before the changed version is used; a change to a Tier 1 EUC is a change like any other and gets the same segregation between the person who makes it and the person who approves it.
Documentation means a purpose statement, a map of inputs, calculations and outputs, the key assumptions and the known limitations, kept current enough that a competent replacement could operate the file in the owner’s absence. Backup means the authoritative location is backed up and a restore has been proven, which is usually inherited from the platform and should be confirmed rather than assumed. Logic review means an independent, documented review of the formulas and structure at implementation and after any material change, using tools that map precedents and dependents and flag inconsistencies, plus a re-performance of the key calculations by hand or in a parallel build; for model-like EUCs this becomes validation, with conceptual soundness, benchmarking and outcomes analysis. Output checks mean the reviewer of the EUC’s output reconciles it to expectations and to independent sources before it is used, and the reconciliation is evidence in the control the EUC serves. And structural discipline, the separation of inputs, calculations and outputs into distinct sheets or areas with no hard-coded numbers inside formulas, is what makes all the other controls testable.
Tooling changes the cost of the control set but not its content. Dedicated EUC management platforms automate discovery scans, hold the inventory, capture version history and change logs, compare versions to show what logic changed, and run formula-integrity checks on a schedule; collaboration platforms supply version history and access control for free if the authoritative-location rule is enforced. What no tool supplies is the independent logic review and the input reconciliation, which remain human work, and an organization that buys a platform and stops there has automated the inventory of files it still does not control. The audit tests the outcomes in the checklist whatever the tooling, and treats the platform itself, where one exists, as an application with its own general controls.
Testing the EUC program
The engagement tests the program, then tests a sample of critical EUCs against the control set. The program tests establish whether the inventory is complete and tiered defensibly; the file tests establish whether the controls exist and operate on the files that matter. Both halves are needed: a perfect inventory with uncontrolled files and a perfectly controlled sample drawn from an incomplete inventory both leave the organization exposed.
| # | Test | Method | Pass condition |
|---|---|---|---|
| 1 | Policy and definition | Inspect the EUC policy, definition, scope, tiering criteria and control requirements by tier | Policy exists, is approved, defines EUC by control environment, and sets controls by tier |
| 2 | Inventory completeness | Re-run the six discovery sources independently for a selected process or unit; reconcile to the inventory | All EUCs found by the auditor appear in the inventory; unexplained gaps below a tolerance agreed in planning |
| 3 | Inventory accuracy | Sample inventory records; verify owner, location, purpose, inputs, outputs and tier with the owner and by inspection | Records current; one authoritative location; shadow copies identified |
| 4 | Tiering | Re-score a sample of Tier 2 and Tier 3 EUCs on the criteria | Scores reproduce; no Tier 1 EUC hiding in a lower tier; downstream controls cited for tier reduction are tested controls |
| 5 | Access and version control | For sampled Tier 1 EUCs, inspect location permissions, protection settings, version history and working-copy practice | Access restricted and reviewed; calculations protected; single authoritative version with history |
| 6 | Input controls | Trace inputs in the sampled EUCs to source reports and reconciliations; test validation settings | Inputs reconciled and dated; designated cells; validation in place |
| 7 | Change control | Inspect change logs; compare current logic to the last reviewed version; test a sample of changes for testing and independent review | All logic changes logged, tested and reviewed by someone other than the maker |
| 8 | Logic review and re-performance | Run a formula-mapping tool; re-perform key calculations on the sampled EUCs; inspect the last independent logic review | No unreviewed inconsistencies; re-performance agrees; review documented and current |
| 9 | Documentation and continuity | Inspect documentation; test whether the backup owner can operate the file | Documentation current; backup owner named and capable |
| 10 | Output controls and downstream reliance | Trace the EUC’s output into the control or report it serves; inspect the reconciliation performed by the user of the output | Output reconciled before use; the control that depends on the EUC records its reliance |
| 11 | Model overlap | Reconcile model-like EUCs to the model inventory; inspect validation status | Every model-like EUC in the model inventory with validation proportionate to risk |
| 12 | Migration governance | Inspect the migration backlog, prioritization and progress | Tier 1 EUCs with system alternatives have a migration decision recorded (migrate, remediate, retire) with dates |
Sample sizes follow the population: for Tier 1 EUCs the sample is often the whole population or most of it, because the population is small and each file is unique; for the inventory and tiering tests, a sample of 25 records across units gives a defensible view of a large inventory, sized as the sample sizes guide describes. The formula-mapping step is the one that finds things: an auditor with a mapping tool and an afternoon will find inconsistent formulas in most large workbooks that have never been independently reviewed, and the findings are concrete in a way few IT audit findings are.
Migration-to-system prioritization
The durable fix for a critical EUC is usually to stop it being one: to move the logic into the ERP, the consolidation tool, the reporting platform or a governed data model where IT’s general controls apply. The organization cannot migrate everything, so the program needs a prioritization that management can defend and internal audit can test. The score has two axes. Risk is the tier score, weighted toward materiality and toward the absence of downstream controls. Effort is the cost of the alternative: whether the system already has the function (a configuration change), whether it needs a build or a purchase, how many upstream and downstream processes change, and how long the owner’s team would run parallel. The output is three lists: migrate (high risk, low effort, and the high-risk items where effort is justified), remediate (high risk, high effort, controlled as Tier 1 until a system change arrives, with a review date), and retire (EUCs whose output a system already produces, which are more common than anyone expects once the inventory is complete). Each Tier 1 EUC gets a recorded decision, and the audit tests that the decisions exist and that the migrate list moves.
The EUC controls checklist
One checklist per Tier 1 EUC, completed by the owner at implementation and at each annual review, and used by the auditor as the test template. Tier 2 files use sections 1, 2, 3, 5 and 8.
EUC controls checklist (Tier 1)
1. Identification. Inventory reference; name; authoritative location; owner and backup owner; purpose; process, control or report served; frequency; tier and score with date; model inventory reference if model-like.
2. Access. Location permissions (list, last review date); sheet or object protection on calculations and outputs; input cells designated; access reviewed on the application review cycle.
3. Version control. Naming convention applied; version history retained; prior versions read-only; no working copies (shadow copies located and removed); period-end version archived.
4. Inputs. Each input listed with source, method (link, paste, manual), reconciliation to source (control totals, record counts, tie-out) and date; validation rules on manual inputs; hard-coded values in formulas eliminated or documented.
5. Change control. Change log present with date, description, reason, maker, tester, reviewer; logic changes tested against a known result; reviewer independent of maker; last change and its review referenced.
6. Logic review. Independent review at implementation and after material change; formula-mapping results; inconsistencies resolved; key calculations re-performed; assumptions and limitations recorded; validation report if model-like.
7. Documentation and continuity. Purpose, structure, inputs, calculations, outputs and operating steps documented; backup owner has operated the file at least once; documentation date.
8. Outputs and downstream reliance. Outputs listed with consumers; reconciliation performed by the consumer before use; the dependent control or report records its reliance; backup of the authoritative location confirmed.
9. Migration decision. Migrate / remediate / retire; rationale; target date; owner of the decision.
10. Sign-off. Owner attestation; independent reviewer; dates; next review date.
Worked example: Lakeshore Bancorp after the deferred-fee error
Lakeshore Bancorp, the illustrative $9 billion regional bank used across this site, closed its last SOX year with a significant deficiency that began in a spreadsheet: a formula error in the deferred loan fee amortization workbook produced a $1.4 million misstatement that the preparer review, operating at a $250,000 threshold, did not catch, and the external auditor did. A second significant deficiency, the undocumented qualitative factors in the CECL allowance, also lived in a workbook. The audit committee asked internal audit for an EUC audit, and the CAE scoped it at 380 hours with the function’s data analytics auditor assigned to the discovery work, because the bank had an EUC policy from 2021 and an inventory of 40 files that nobody believed.
Discovery ran all six sources. The key control matrix’s IPE inventory, rebuilt earlier in the year as the control classification guide describes, listed 74 reports of which 29 passed through spreadsheets. The close checklist walk added 38 files, the regulatory reporting map (call report schedules, the liquidity and capital packs) added 22, and the model inventory contributed 9 model-like workbooks. The share scan across finance, risk, treasury and loan operations returned 6,400 candidate files, filtered to 1,870 with macros, external links, links to ledger extracts or modification in the last year, which the owners confirmed down to 118 in use, 61 of them duplicates of files already found. The confirmed inventory came to 212 EUCs against the old list of 40, tiered by the four-dimension score into 31 Tier 1, 78 Tier 2 and 103 Tier 3. Both deficiency workbooks were Tier 1; the old inventory had held one of them.
| Test area | Result on the 31 Tier 1 EUCs | Finding and rating |
|---|---|---|
| Inventory completeness | 212 confirmed against 40 listed; 14 Tier 1 files had shadow copies on personal drives, three of which were the versions actually used at the last quarter-end | High: inventory and version control not operating; authoritative-location rule unenforced |
| Access and protection | 19 of 31 in locations with permissions beyond the preparing team; 24 with no sheet protection on calculations | Medium: access restriction absent on most Tier 1 files |
| Input controls | Inputs reconciled to source on 22 of 31; nine relied on pasted extracts with no tie-out, including the deferred-fee workbook’s loan population | High: the deferred-fee error’s root cause (an incomplete population paste) uncontrolled on eight further files |
| Change control | Change logs present on 6 of 31; logic changes since the last year-end identified by comparison on 17 files, none reviewed independently | High: no change control on Tier 1 logic |
| Logic review | Formula mapping found inconsistent formulas in 11 of 31 workbooks; four produced differences above the tiering materiality threshold when re-performed, the largest $610,000 in a lease liability roll-forward | High: independent logic review not performed; four corrections booked |
| Model overlap | Nine model-like EUCs; seven in the model inventory; the two outside were an interest rate risk sensitivity workbook and a deposit runoff assumption file used by treasury | Medium: model inventory incomplete, referred to model risk management under the 2026 guidance |
| Migration | No migration decisions recorded; 11 Tier 1 EUCs had system equivalents available (loan module amortization, fixed asset module, the reporting platform) | Medium: migration governance absent; 11 migrate, 15 remediate, 5 retire agreed at the closing meeting |
The report carried seven findings, four High, and one conclusion the committee had not expected: the deferred-fee error was not an isolated formula slip but the visible instance of a control environment in which none of the 31 files that could move the financial statements had independent logic review or change control, and eight had the same uncontrolled input pattern that had caused the error. Management’s response moved the deferred-fee amortization into the loan system’s module by the second quarter, which retired the workbook, and placed the remaining Tier 1 files under the checklist with a quarterly owner attestation and an annual review by the second line. Internal audit’s follow-up a year later is a re-run of tests 2, 5, 7 and 8 on the Tier 1 population, which is the cheapest way to know whether an EUC program is alive: if the change logs have entries and the logic reviews have dates, it is.
Common mistakes
Building the inventory by asking. Scanning without a confirmation step, and presenting thousands of files as the population. Defining EUC by technology so that scripts, dashboards and low-code apps escape. Tiering on the size of the usual output instead of the plausible error. Accepting “the controller reviews it” as a downstream control without testing its precision. Applying the Tier 1 control set to every file, which guarantees it is applied to none. Testing the file the owner opens for the auditor rather than the version used at period-end. Reviewing formulas by eye instead of with a mapping tool. Treating the model inventory and the EUC inventory as separate worlds. Leaving migration as an aspiration with no decision per file. And closing the audit without leaving the owner attestation and the review cycle in place, so that the inventory is stale again by the following year; the issue log template is the place to track the migrate and remediate decisions to closure, and the ITGC primer explains the general controls that a migrated EUC inherits and an unmigrated one lacks.
Related guides
- IPE testing: proving the reports your controls rely on
- Manual, automated and IT-dependent manual controls
- Management review controls: precision, evidence and testing
- Evaluating control deficiencies
- How to perform a user access review
- Model risk management audit
- SOX ITGC scoping
- How to build the IT audit plan
- Audit sample sizes
- Audit issue log template
- IT general controls: the complete primer
Leave a Reply