Two questions travel under the label “AI in SOX”, and they have different answers. Can the SOX program use AI to do its own work? Yes, for drafting, extraction, analysis code and full-population matching, on one condition: the tool’s output is never the evidence. A test conclusion counts when the population was shown to be complete and accurate, someone other than the tool can reperform the work from what is on file, and a competent tester checked the output against the underlying records and documented the check. Where the external auditor wants to use that testing, the auditor decides, control by control, under its own standards.
When does AI inside a financial reporting process become part of ICFR? When a key control depends on what it produces: it codes, matches, posts or calculates without a person checking each result, or it produces the information a reviewer relies on. From then on it needs what any in-scope system needs (controlled change, restricted access, monitoring) and one thing a rules engine does not: evidence across the period that its outputs were right. A system that can return different answers to the same input cannot be tested once and assumed to hold.
As of November 2026 the research for this guide found no PCAOB standard, SEC rule or SEC guidance that addresses AI inside ICFR. What exists is a COSO publication from February 2026, PCAOB staff observations, a PCAOB request for comment of June 2026 that asks whether AI needs standards or staff guidance, PCAOB amendments on technology-assisted analysis that leave AI aside, non-authoritative papers from the CAQ, AICPA, IIA and FEI, and SEC enforcement about AI claims. This guide sets out what each says, then a working method for both questions. Everything beyond the cited documents, including the two answers above, is practitioner judgment and is labeled as such. It belongs with the SOX guides and adds the SOX layer to generative AI across the audit lifecycle and auditing agentic AI.
In this guide
- What has been published, as of November 2026
- Part one: using AI in the SOX program
- The evidence rules that apply to AI output
- Confidentiality and data-handling conditions
- What to agree with the external auditor first
- A model policy for SOX testers
- Part two: when an AI-enabled step is in scope for ICFR
- Classifying the control, and why one test is not enough
- General IT controls for models and prompts
- Review controls, third-party AI and fraud
- Control checklist for an AI-enabled process
- Worked example: Brackwell Industrial Supply
- Questions the audit committee and the external auditor will ask
- What is unsettled
- Questions readers ask
- Related guides
What has been published, as of November 2026
Read the table for who each text binds. PCAOB standards bind the external auditor. SEC rules and guidance bind the registrant and its management. COSO’s 2013 internal control framework is the framework management chooses; COSO’s 2026 paper says it adapts that framework’s components and principles to GenAI instead of creating a separate one. CAQ, AICPA, IIA and FEI documents bind no one. Every row was read at its source on 10 November 2026; where only an announcement could be read, the row says so.
| Body | Date | Document | What it says | Status |
|---|---|---|---|---|
| PCAOB | July 2024 | Spotlight: Staff Update on Outreach Activities Related to the Integration of Generative Artificial Intelligence in Audits and Financial Reporting | Firms used GenAI mainly for administrative and research work; some did not allow it in audit procedures; the person using it stays responsible for the work and its documentation. Preparers used it for drafts and some repetitive tasks such as finding reconciling items, and raised inconsistent output and opaque tools as auditability questions. | Staff views; “not a rule, policy, or statement of the Board” |
| PCAOB | 12 June 2024; SEC approval 20 August 2024 | Release No. 2024-007, Amendments Related to Aspects of Designing and Performing Audit Procedures that Involve Technology-Assisted Analysis of Information in Electronic Form (to AS 1105 and AS 2301) | Effective for audits of fiscal years beginning on or after 15 December 2025. Covers the auditor’s analysis of electronic information with technology-based tools: level of detail, company-produced and external information, procedures with more than one purpose, items identified for investigation. Says the amendments do not address specific matters relating to other technology applications used in audits, and gives AI as an example. The Board’s Policy Statement Regarding Implementation of Paragraph .10A of AS 1105, Audit Evidence (Release No. 2025-004, 18 September 2025) does not mention AI either. | Final; binds the external auditor |
| PCAOB | April 2026 | Spotlight: 2025 Conversations With Audit Committee Chairs | From conversations with more than 250 chairs: concern about fraud facilitated by AI, and questions to auditors about AI’s effect on financial reporting and controls and about how firms control their own AI tools. | Staff views |
| PCAOB | 23 June 2026; comments due by 7 August 2026 | Release No. 2026-005, Request for Public Comment on PCAOB Standard Setting | Question 8 asks whether the Board should pursue standard setting and research, or staff guidance, on AI: its effect on risk assessment, on auditing internal controls and on audit evidence, and the documentation, supervision and governance of AI-enabled tools. Question 10 asks which current standards are not fit for purpose in an AI environment. Reports no consensus among earlier commenters between guidance and standard setting. | Request for comment; proposes no rule |
| PCAOB | Page as read on 10 November 2026 | Standard-Setting, Research, Rulemaking, and Related Activities (agenda page) | Under “Staff Guidance”, says the staff “is currently considering guidance” on a topic it titles “Use of Super Intelligence”: the effect on the audit of a company’s use of it in financial reporting, and the auditor’s own use. The term is the page’s own, and the page does not define it. A search of pcaobus.org on the same date found no issued standard or staff guidance on testing AI-enabled controls. | Agenda item; nothing issued |
| SEC | In force | Exchange Act Rule 13a-15, Regulation S-K Item 308 and the 2007 interpretive guidance (Release 33-8810) | Technology-neutral. A search of sec.gov on 10 November 2026 found no rule, interpretive release or staff guidance on AI in ICFR. | Rules bind registrants; an evaluation that follows the 2007 guidance satisfies Rule 13a-15(c) |
| SEC | 18 March 2024 | Press release 2024-36, SEC Charges Two Investment Advisers with Making False and Misleading Statements About Their Use of Artificial Intelligence | Settled charges over false and misleading statements about the firms’ use of AI; $400,000 in civil penalties in total. About claims, not ICFR. | Enforcement |
| SEC | 14 January 2025 | SEC Charges Restaurant-Technology Company Presto Automation for Misleading Statements About AI Product (order, Securities Act Release No. 11352) | Settled order: a company listed on Nasdaq until September 2024 made misleading statements about its AI product. The order also found a failure to maintain disclosure controls and procedures (Rule 13a-15(a)). No civil penalty. | Enforcement |
| COSO | 23 February 2026 | Achieving Effective Internal Control Over Generative AI (GenAI) | Adapts the 2013 framework’s five components and 17 principles to GenAI: eight capability types, control considerations by component, a six-step roadmap. Where management relies on AI output as evidence for an ICFR control, it says the prompt, configuration and model version should be documented and evidence retained. It does not set what external auditors accept. | Publication commissioned by COSO, by five named authors; it states that it contains general information only |
| CAQ | April 2024 | Auditing in the Age of Generative AI | For auditors of companies deploying genAI: a table of risk areas and questions (governance, fraud, model performance, prompts, monitoring and others), human review supported by entity-level or IT general controls, and two examples. | Not authoritative |
| CAQ | July 2024 | Audit Committee Oversight in the Age of Generative AI | Says genAI “may not always provide reliable or repeatable information”; lists questions for management and auditors on governance, testing before deployment, human involvement, monitoring of changes and fraud. | Not authoritative |
| AICPA | Announced 13 October 2026 | Artificial Intelligence (AI) Considerations for Financial Statement Auditors (practice aid) | Two parts: an entity’s use of AI in financial reporting and controls, and audit firms’ own use. Member download; described from the AICPA’s announcement only. | Nonauthoritative |
| AICPA | Listed 11 September 2026 | TQA Section 9561, SOC Examinations: Effect of the Service Organization’s Use of AI on SOC 1 and SOC 2 Examinations | Questions and answers for examinations under AT-C sections 320 and 205. Behind a login; not read for this guide. | Technical Q&A |
| IIA | 2024 update; page dated 13 September 2024 | The IIA’s Artificial Intelligence Auditing Framework | For internal auditors auditing AI, in three domains: governance, management and internal audit. One passing reference to testing ICFR; nothing on SOX. | Guidance, not a Standard |
| FEI | 25 June 2026 (newswire dateline; FEI’s page is undated) | AI Framework: Internal Control Over Financial Reporting (Committee on Corporate Reporting whitepaper) | Per FEI’s announcement: a method for scoping AI used in financial reporting and four control approaches (human-in-the-loop review, performance testing against known results, multi-model validation, data analytics monitoring). Paid document; only the announcement was read. | Practitioner whitepaper |
Three things follow. First, the texts that bind are technology-neutral, and they already hold the tests that matter. PCAOB Auditing Standard 2201 paragraph .47 lists factors that affect the risk associated with a control, among them whether a person performs it or it is automated, how far it relies on other controls such as IT general controls, and its complexity and the judgments in its operation. AS 1105 paragraph .10 has the auditor test the accuracy and completeness of information the company produces, or test the controls over them; as amended for fiscal years beginning on or after 15 December 2025, it names IT general controls and automated application controls among those controls. The SEC’s 2007 interpretive guidance (Release 33-8810) has management evaluate the IT general controls that other controls need in order to work, and vary the evidence with risk, including the risk that a control fails. Second, the documents that address AI converge on two points: outputs can vary and can be wrong, and validation by a person or another independent check has to stand between the output and anything relied on. Third, nobody with authority has said how an AI-enabled control is to be tested; the PCAOB asked in June 2026 whether it should.
Part one: using AI in the SOX program
SOX testing narrows the general question of AI in audit work, because someone else relies on the result: management for its assessment, and often the external auditor. The table lists candidate uses and the review each needs. It is practitioner judgment; no standard prescribes it.
| Use | What the tool does | What can go wrong | The review that makes the output reliable |
|---|---|---|---|
| Drafting narratives and control descriptions | Turns walkthrough notes and prior-year files into a narrative or a control description | Describes a step or control that does not exist; smooths over a gap the walkthrough found | The tester ties each step to walkthrough evidence and the control owner confirms it. The walkthrough is still performed by a person. |
| Extracting attributes from sampled evidence | Reads invoices, approvals, contracts or tickets and fills the test sheet | Misreads a field; misses an amendment or a second page; reports a date that is not on the document | The tester agrees every extracted attribute to the document before recording a pass. The tool saves keying, not checking. |
| Matching a full population | Compares every item to a rule: approvals to the authority matrix, leavers to active accounts, payments to approved bank details | Incomplete extract; a wrong join or filter; exceptions reported as if each were a failure | Reconcile the extract to an independent total, read the logic and run it on items with known answers, disposition every exception. A saved script, which the tool may draft, is better evidence than a model’s own comparison. |
| Classifying free text | Sorts journal entry descriptions, exception reasons or ticket notes into categories | Misclassification; the “nothing unusual” class is never examined | Use it for selection only. Sample every class, including the clean one, and record the error rate. |
| Reading review-control evidence | Locates flagged items, explanations and sign-offs inside a review pack | Accepts a plausible explanation; cannot judge precision or whether the reviewer corroborated anything | The tester judges precision and reperforms a selection of the reviewer’s follow-up. The tool only finds pages. |
| Summarizing SOC 1 reports | Lists exceptions, user entity controls and subservice organizations | Drops an exception, a carve-out or a qualification | A person reads the opinion, the test results and the user entity control list in full. The summary is an index. |
| Drafting conclusions and deficiency memos | Produces a first draft of a test conclusion or a deficiency evaluation | States a fact that is not in the workpapers; cites a paragraph that does not say what is claimed | Every fact carries a workpaper reference and every citation is opened. Severity is decided by the people accountable for it. |
| Selecting samples | Asked to pick items at random | The selection cannot be reproduced and may not be random | Do not use a language model. Use a seeded, documented selection from the reconciled population. |
Two patterns explain the table. Where the tool reads documents, the tester’s check against the source is the procedure and the tool is a convenience. Where the tool, or code it wrote, processes a population, the work is an analytic and is held to the rules for analytics.
The evidence rules that apply to AI output
No standard read for this guide has a separate rule for AI output. The existing rules apply, and in practice three tests decide most cases.
- Completeness and accuracy of the information used. A full-population test is only as good as the extract. Reconcile it to an independent figure before the tool sees it, by the methods in the IPE testing guide. The tool’s output is a derived listing too: show that items in equal items out.
- Reperformability. Another tester with the file and the same source has to be able to reach the same result. For code, that means the saved script, version and run log described in documenting analytics as audit evidence. For a step the model performed, keep the tool and model version, the date, the instruction given, the inputs and the raw output. If the same instruction could return a different answer tomorrow, the retained output and the tester’s check of it are the record; the ability to run it again is not.
- A competent person’s documented review. The evidence hierarchy does not change: inspecting the underlying record and reperforming the control outrank any summary of them. A model’s statement that an approval exists is a pointer to where to look.
For management, Instruction 2 to Regulation S-K Item 308 requires the registrant to maintain evidential matter, including documentation, that reasonably supports management’s assessment, and the SEC’s 2007 guidance says that as risk rises the evidence would ordinarily come from direct testing or from monitoring by more objective people. For the external auditor, AS 2201 paragraphs .16 to .19 govern the use of work done by others: the more competent and objective the people, the more use the auditor may make of their work, and the higher the risk associated with a control, the more of the work the auditor performs itself. The technology-assisted analysis amendments add requirements for the auditor’s own analysis: where a procedure serves more than one purpose, the auditor should achieve each objective (AS 1105 paragraph .14, as amended), and when a test of details identifies items for further investigation, the auditor has to determine whether they indicate, individually or in aggregate, misstatements or control deficiencies (AS 2301 paragraph .49). Those paragraphs bind the auditor, not management’s tester. As practice, a full-population test offered for reliance should be able to meet them.
Confidentiality and data-handling conditions
SOX evidence includes unreleased results, draft disclosures, payroll and bank details, customer contracts and vendors’ SOC reports. The conditions below are a working minimum, as practice, on top of the company’s own AI and data policies.
- Approved tool only. A deployment the company has contracted for, with terms that exclude training on inputs, a stated retention period and logging. No consumer tools and no personal accounts.
- Unreleased financial information is restricted. Draft financial statements, close data and disclosure drafts go only into a deployment cleared for material nonpublic information, with access limited to people already inside the close.
- Personal data is minimized. Payroll and HR evidence is tested in the system of record or with identifiers masked.
- Third-party documents follow their terms. SOC reports and contracts usually arrive under confidentiality terms. Check them before a copy is uploaded anywhere.
What to agree with the external auditor first
Whether the auditor uses AI-assisted testing is the auditor’s decision, and firm policies differ: the PCAOB staff’s July 2024 outreach found some firms did not then allow GenAI in audit or attest procedures. Settle the items below in writing when reliance is agreed for the year, an early line in the SOX compliance checklist; November is too late to change how a control is tested where reliance is planned. The reliance decision itself is covered in getting external audit to rely on your SOX testing.
| Item | What to settle |
|---|---|
| Where AI is used | Which controls and test steps involve a tool, and what the tool does in each: drafts, extracts, matches or classifies. |
| What the tester still does | The human check for each use, written as a procedure the auditor can reperform. |
| Excluded controls | Which controls get no AI assistance. In practice: controls that address fraud risk, significant estimates and management review controls. |
| Documentation | The fields recorded for each use (tool, version, date, instruction, input, output, review) and where they sit in the workpaper. |
| Populations and samples | How extracts are reconciled before analysis and who obtains them; confirmation that sample sizes and selection methods are unchanged by the tool. |
| Changes during the year | How a change of tool, model version or method is communicated, and what is retested when it happens. |
| The auditor’s reperformance | Whether the auditor will reperform from source documents or from the tool’s output, so the file holds what they need. |
A model policy for SOX testers
| Rule | Reason |
|---|---|
| Use only the approved tool, signed in as yourself. | Confidentiality, and a trail of who did what. |
| The tool never concludes. A pass, a fail and a severity are recorded by a named tester. | Accountability sits with a person management and the auditor can question. |
| Agree every attribute that supports a conclusion to the source document yourself. | The document is the evidence. The output is not. |
| Reconcile populations before analysis, and outputs to inputs after it. | Completeness is where full-population tests fail. |
| Read any code the tool writes, run it on items with known answers, and save it with its version. | An unread script is an untested report. |
| Record tool, version, date, instruction, input and output for every use that supported a conclusion, and keep them with the workpaper. | Reperformance by a reviewer or by the external auditor. |
| No AI assistance on excluded controls without the program lead’s written approval. | Higher-risk controls need the most direct evidence. |
| Log every error the tool made that your review caught. | The log shows whether review works and where to stop using the tool. |
| Tell the program lead before the tool, model or method changes mid-year. | A change of method between interim and roll-forward testing has to be explained to the auditor. |
Part two: when an AI-enabled step is in scope for ICFR
Scope follows reliance, as it does for any system. COSO’s 2026 paper offers a working definition that fits: management relies on AI when it depends on the system’s output as part of the evidence that an ICFR control is designed or operating effectively. The table applies that test, as practitioner judgment; the mechanics of SOX scoping and ITGC scoping are unchanged.
| Situation | Example | In scope? | What carries the assurance |
|---|---|---|---|
| 1. AI drafts text that a control owner reviews before use | Flux commentary, accounting memos, disclosure drafts | The tool is not a control. The review is, and it is usually key already. | The review, redesigned for the new risk: explanations tied to source, numbers agreed to the ledger. |
| 2. AI captures or transforms data that then passes a deterministic key control | Invoice fields read by a model, then a configured three-way match | In the process but not relied on, if the downstream control would catch its errors at the precision needed | The downstream control. Record the reasoning and put the tool on the change-watch list. |
| 3. AI output is recorded with no person checking each item | Touchless account coding, auto-clearing of matches, auto-certified reconciliations | Yes | Controls over the tool, plus a monitoring control that tests output accuracy through the period. |
| 4. AI output is the information a reviewer relies on | Exception lists, anomaly flags, contract summaries used for accounting conclusions | Yes, as information used in a control | Completeness and accuracy of that information, tested directly or through controls over the tool. What it did not flag matters most. |
| 5. AI calculates or proposes a recorded amount | Accruals, reserves, allocations | Yes | An independent expectation or recalculation by the reviewer; controls over inputs and versions. |
| 6. An agent acts in a financial system | Posts journals, releases payments, edits master data | Yes | Its own identity, authority limits the system enforces, segregation of duties, complete logs. |
| 7. A vendor switches on an AI feature in a system already in scope | A release adds AI matching to the payables or close tool | Apply rows 1 to 6 to what the feature does | Release-note review as a re-scoping trigger; the vendor’s SOC 1 coverage. |
| 8. An employee uses a general assistant to perform a control step | Pasting a reconciliation into a chatbot to find reconciling items | The control is still the person’s | The approved-tool policy, and the same evidence of performance as before. |
Row 2 is where programs talk themselves out of scope too early. The test is precision: would the downstream control catch an error the tool makes, at an amount that matters, for every type of transaction the tool touches? A three-way match catches a misread amount on a purchase-order invoice. It does nothing for an invoice that has no purchase order.
Classifying the control, and why one test is not enough
The control classification guide defines three natures by how each fails: manual controls fail one occurrence at a time, automated controls fail systematically when something changes, and IT-dependent manual controls can fail both ways. The single test of an automated control rests on that logic. For the external auditor, AS 2201 paragraph B28 describes entirely automated application controls as “generally not subject to breakdowns due to human failure”, and paragraphs B29 to B33 let the auditor carry a tested baseline forward where general controls over program changes, access to programs and computer operations are effective and still tested, and the auditor verifies that the control has not changed. Paragraph B31 has the auditor weigh how far the control can be matched to a defined program within an application and how stable that application is. The method is in testing automated controls.
Appendix B says nothing about AI. What follows is this guide’s reasoning from those paragraphs, not a rule: a learned or generative component does not fit their conditions, in three ways. Its output for a given item is not fixed by a setting anyone can inspect: COSO’s paper states that “GenAI is probabilistic, not deterministic”, and the CAQ notes that the same question can return different answers. Its behavior changes with things that ordinary program change control may never see: a vendor’s model update, an edited prompt, new reference data. And it has no single path to test: accuracy on last month’s invoices says little about a new supplier’s format. So, as judgment: an AI component is not benchmarked, and one passing instance is evidence about that instance.
| The step | Classify as | Evidence of operation | Single test? |
|---|---|---|---|
| A configured rule around the model: confidence threshold, routing, dollar limit, hard block | Automated | Configuration inspection, one instance tested each side of the limit, change history | Yes, where general IT controls are effective, as for any configuration |
| A person reviews each AI output before it is used | IT-dependent manual | A sample of reviews sized by frequency, plus tests of the information reviewed | No. Sampled like any manual control |
| A person reviews only what the model flags | IT-dependent manual, with the unflagged population as its information risk | Tests of the review, and evidence about what was not flagged, from sampling that class | No |
| The model’s output is used with no review of each item | Automated step that depends on a monitoring control (a management review of machine output) | The monitoring control’s results across the period, the tester’s own sample of outputs, and retesting after each model or prompt change | No. Evidence has to span the period |
General IT controls for models and prompts
The familiar domains still organize the work. What changes is the list of things that count as a change and as privileged access. COSO’s paper asks for models, their configurations and the indexes they retrieve from to be treated as configuration items under access and change control, with documented approval of changes to prompts, thresholds and retrieval sources. The table is this guide’s mapping, as judgment, of each domain to the method guides.
| Domain | What it covers for an AI component | Evidence to ask for | Method |
|---|---|---|---|
| Change | Model version, including updates the vendor pushes; the prompt or instruction set; thresholds and routing rules; the reference data the model retrieves from; training or tuning data | Version history for each; change tickets with approval; a regression run on a fixed set of items with known answers before each promotion; vendor release notes, reviewed | IT change management |
| Access | Who can edit prompts, thresholds and reference data; administrator rights in the tool; the tool’s own account in the ERP | Access reviews that include these roles; proof that people who configure the tool cannot also approve its output; the service account’s entitlements | Privileged access, user access review, segregation of duties |
| Operations and monitoring | Complete processing, error and fallback handling, logging, output quality over time | Reconciliation of items in to items out; aging of the error queue; a log that holds input, output, model version and confidence for each item; accuracy measures with thresholds and an owner | The interface and scheduled-job tests in the automated controls guide |
| Vendor | Hosted tools and models; a model provider behind the tool vendor | A SOC 1 report that covers the feature; how the model provider is treated as a subservice organization; contract terms on change notice and data use | Vendor due diligence |
Review controls, third-party AI and fraud
Management review controls over AI output
A review of machine output is a management review control and is judged the same way: defined information, an independent expectation, a threshold, investigation, evidence. Three design points, as practice, are specific to AI. The reviewer samples from everything the tool processed, including what it passed without comment, because a review of flagged items says nothing about misses. The expectation is independent of the tool: a second person’s coding from the source document, or a recalculation. And the review has a quantified trigger with a consequence: an error rate above which the period’s output is re-examined and the tool goes back to full review until it is fixed. Watch the reviewer as well as the tool: agreement with every output at seconds per item is a control that has stopped operating, and the oversight measures in the AI audit framework show how to check.
Third-party AI and what a SOC 1 report covers
AI in finance often arrives inside a vendor’s product. Read the vendor’s SOC 1 report with the ten questions in how to review a SOC 1 report and, as practice, add four. Is the AI feature inside the system description? Is there a control objective, with tested controls, over the accuracy of its processing, or only over access and change? Is the model provider a subservice organization, and is it carved out? Do the complementary user entity controls assume the customer reviews the feature’s output? If the report is silent on the feature, treat its processing as untested for your purposes and rely on your own controls over its output. For the auditor, AS 2201 paragraphs B17 to B27 apply as for any service organization. The AICPA’s September 2026 Q&As on AI in SOC examinations are new, and earlier reports may not mention AI features at all; ask the vendor how its service auditor has applied them.
Fraud and override
In this guide’s judgment, three exposures belong in the fraud risk assessment under COSO Principle 8. Fabricated support: the CAQ’s July 2024 paper warns that realistic fake documentation can be generated, which strengthens an old rule, that testers pull evidence from the system of record and do not accept it as an attachment. A new override path: whoever can edit a prompt, a threshold or the reference data can change what gets posted without touching the ledger, so those edits belong in privileged access reviews and in a change log that someone independent reads. A new poster: an agent’s account is a user for segregation of duties and for journal entry testing, and its entries carry its own ID, never a shared one. Instructions hidden in documents the tool reads are covered in the agentic AI guide.
Control checklist for an AI-enabled process
Use this as a design checklist before go-live and a test plan afterward. Not every row is a key control; rows 3 to 7 usually are where the tool is relied on. It is practice, consistent with the control approaches COSO and FEI name, and it adds to the process controls in the SOX controls list.
| # | Control | Risk it answers | Evidence |
|---|---|---|---|
| 1 | Inventory of AI uses in financial reporting processes, each with a named finance owner and a scoping decision, approved by the controller and refreshed quarterly | AI in use that the program does not know about, or that nobody answers for | Inventory with owners; scoping memo entry for each use |
| 2 | Testing before go-live on a fixed set of items with known answers, against pass criteria set in advance, then a parallel run or full human review for an initial period | A tool never shown to work on this company’s data; errors that appear only at volume | Test set, results and sign-off; comparison results |
| 3 | Deterministic limits around the model: confidence threshold, dollar limit, categories that always go to a person | High-risk items posted untouched | Configuration evidence and change history |
| 4 | Human review of items below the threshold or in mandatory categories, evidenced for each item | A wrong output accepted | Review records with reviewer ID |
| 5 | Monitoring control: a periodic accuracy sample drawn from all items processed, including unreviewed ones, compared with an independent answer | Undetected errors and drift | Sample, error rate, threshold, action taken |
| 6 | Change control over model version, prompts, thresholds and reference data, with a regression run | Behavior changes nobody approved | Tickets, version history, regression results |
| 7 | Restricted access to configuration, separated from approval of output | Override through the tool | Access review that includes tool roles |
| 8 | A log for each item: input, output, model version, confidence, reviewer | Transactions that cannot be reconstructed | Log extract traced for a selection |
| 9 | Completeness check: items received equal items processed plus items rejected | Silent drops | Reconciliation; cleared error queue |
| 10 | Fallback procedure for when the tool is unavailable or pulled back | An uncontrolled manual workaround at period-end | Procedure; evidence it was followed |
| 11 | Vendor oversight: SOC 1 review, user entity controls mapped, release notes reviewed | Untested vendor processing; unannounced model changes | SOC 1 review memo; release-note log |
| 12 | Quarterly evaluation of whether the tool, or a change to it, is a material change in ICFR | A missed disclosure under Item 308(c) | Change log entry; disclosure committee minute |
Worked example: Brackwell Industrial Supply
Brackwell Industrial Supply is a hypothetical US-listed distributor of maintenance and repair parts with a 31 December year-end, whose auditor attests to ICFR. Every figure here is invented. In 2026 the controller put two tools into finance. On 1 June an invoice tool went live in accounts payable: a vendor-hosted model reads supplier invoices, matches purchase-order invoices to order and receipt lines ahead of the ERP’s three-way match and, for the roughly 9,000 invoices a month with no purchase order, proposes the account and cost center and posts without review where its confidence score is 0.90 or higher, about 70 percent of them. From the September close, an assistant drafts flux commentary and accrual memos. The external auditor was told in April. The SOX team’s decisions follow. The sample sizes are Brackwell’s own choices, agreed with its auditor; none is a rule.
| Step | Scoping decision | Key controls | Test approach |
|---|---|---|---|
| Capture and line matching of purchase-order invoices | In the process, not relied on. Reading and matching errors surface as failures of the ERP’s three-way match or duplicate check, existing key automated controls, and go to a person. A wrong line that still agrees on price and quantity does not change the amount recorded. | Three-way match; duplicate invoice check (unchanged) | As before: configuration, one instance, change history. Added: output analysis for June to December showing no invoice was paid outside the match after go-live. |
| Auto-coding of invoices with no purchase order | In scope. Nothing downstream is precise enough to catch a capital item coded to expense. | (a) Configured 0.90 threshold, with review mandatory above $25,000 and for fixed asset and prepaid accounts. (b) Analyst review of routed items. (c) Monthly accuracy control: 60 auto-posted invoices drawn at random are coded from the image by an analyst who does not maintain the tool; more than 2 disagreements suspends auto-posting and triggers re-review. (d) Change control over model version, prompt and threshold. | (a) Automated: settings inspected, one invoice tested each side of each limit, change log read. (b) Sample of 25 reviews. (c) Tested as a review control: three monthly instances at interim and one in roll-forward, 10 items reperformed in each, plus the tester’s own random sample of 40 auto-posted invoices at interim and 15 in roll-forward. (d) Every change since go-live traced to a ticket and a regression run. |
| The vendor’s hosted model | In scope through the vendor | SOC 1 review; four user entity controls mapped | The report runs to 30 September and describes the coding feature, but its control objectives cover access and change, not coding accuracy. Brackwell places no reliance on the vendor for accuracy; control (c) carries it. A bridge letter is requested for the fourth quarter. |
| Drafted flux commentary | The assistant is not a control. The controller’s monthly flux review is. | Flux review, description amended: the reviewer agrees each explanation above threshold to ledger detail or a source document, and the pack marks drafted text. | Review control testing as before, with corroboration of each explanation added as an attribute. |
| Accrual calculation | Not allowed this year. The freight accrual stays in the reviewed workbook; the assistant drafts only the memo. | Existing accrual review | Unchanged |
Control (c) earned its place in October. The September instance, performed on 2 October, found 4 disagreements in 60 against a limit of 2. All four were invoices from suppliers on one billing platform, coded to the wrong expense account after a model update the vendor made on 14 September without notice. Auto-posting was suspended the same day. The team re-reviewed all 1,180 auto-posted invoices from those suppliers since the update and a random 100 from other suppliers: 143 were recoded, moving $386,000 between expense accounts and cost centers; nothing crossed between capital and expense, and the further 100 were clean. The entries were corrected before the September books closed.
The SOX team evaluated a design deficiency in control (d), which had no step for vendor-initiated updates, by the method in evaluating control deficiencies. They classified it as a control deficiency, not a significant deficiency: the exposure was bounded by the dollar limit and the mandatory-review accounts, and the monitoring control caught the errors within its cycle at a precision well below materiality. The fix was a contract amendment requiring notice of model updates, and a rule that auto-posting stops after any update until the regression set passes; the timing of a year-end retest is in remediation and retesting. The disclosure committee had logged the June go-live in its second-quarter evaluation of changes in ICFR, concluded, with its reasons recorded, that it was not a material change, and revisited that conclusion in the third quarter; the quarterly process is in the 302 sub-certification guide. The external auditor tested controls (a) and (c) itself and used management’s testing for (b).
Questions the audit committee and the external auditor will ask
The CAQ’s July 2024 publication lists questions for audit committees, and the PCAOB staff’s April 2026 Spotlight reports chairs asking auditors about AI’s effect on financial reporting and controls. The table combines those themes with what audit teams ask in practice.
| Question | Asked by | A good answer has |
|---|---|---|
| Where is AI used in processes that feed the financial statements, including features vendors switched on? | Both | A dated inventory with a named finance owner and a scoping decision for each use |
| Which key controls depend on an AI output, and how do you know the output is right? | External auditor | The control list, the monitoring control’s results for the period, and what was done when a threshold was breached |
| What changed in the tool this year, who approved it, and who is able to change it? | External auditor | Version history for model, prompts, thresholds and reference data, with tickets and regression results; a reviewed access listing |
| What does the vendor’s SOC 1 cover, and what does it leave to the company? | External auditor | A review memo stating whether the feature is in the description and which user entity controls operate |
| Did SOX testers use AI, on which controls, and what did a person verify? | External auditor | The tester policy, the agreed list of uses, and workpapers that show the human check |
| Has AI been considered in the fraud risk assessment? | Both | Named schemes (fabricated support, configuration override, agent postings) mapped to controls |
| Was introducing the tool a material change in ICFR for the quarter? | Audit committee | The disclosure committee’s documented evaluation |
What is unsettled
- How an auditor tests an AI-enabled control. No PCAOB standard or staff guidance on it was found as of 10 November 2026. The Board’s June 2026 request for comment asked whether AI’s effect on auditing internal controls calls for standards or staff guidance, and the agenda item in the table is still under consideration. Nothing found from the SEC addresses AI in management’s assessment; the SEC actions read for this guide concern what companies said about AI.
- Whether a model can ever be tested once. The benchmarking paragraphs were written for programs that stay the same until someone changes them. The position in this guide, no benchmarking and evidence across the period, is conservative judgment. An auditor may ask for more or accept less.
- How much monitoring evidence is enough. There is no convention for the size or frequency of accuracy samples comparable to the sample-size conventions used for manual controls. Agree it with the auditor, control by control.
- What counts as a failure. COSO’s paper itself says the definition of a control failure may need to evolve for probabilistic systems. Until someone with authority says more, a workable practice is to set the tolerable error rate in the control description in advance and treat a breach as a deviation.
- Who has an ICFR audit. An SEC proposal of 19 May 2026 (Release 33-11419), proposed and not final as of November 2026, would leave the auditor’s attestation to large accelerated filers only, with management’s own assessment unchanged; until it is final, work to the rules in force, set out in SOX 404(a) vs 404(b).
Until those points are settled, a position a program lead can defend this year, as practice, is this. Allow AI in testing for drafting, verified extraction and scripted population tests on lower-risk controls, with the external auditor told in advance. Allow AI in a process where a deterministic key control or a review of each item stands downstream, or where touchless processing is capped by a dollar limit and covered by a monitoring control. Hold back AI-calculated estimates, AI as the only control over a significant account, and agents that post without their own identity and limits, until the evidence in the checklist exists.
This guide is general and educational; it is not legal, accounting or securities advice.
Questions readers ask
Can AI be used for SOX testing, and will the external auditor rely on it?
As practice, yes: as a tool under a tester’s control, for drafting, extraction, analysis code and population matching, with the tester checking the output against source records. Reliance is the auditor’s decision, control by control (AS 2201 paragraphs .16 to .19). Agree the uses, the human procedures and the documentation at planning.
When is an AI tool in scope for SOX?
On the reliance test this guide uses, when a key control depends on its output: it records transactions without a review of each item, produces the information a reviewer relies on, calculates a recorded amount, or acts in a financial system. A tool that only drafts text for a control owner who reviews it is not a control. The review is.
Can an AI control be tested once, like an automated control?
Not on the reasoning that supports a single test of a configured control. That reasoning, and benchmarking under AS 2201 paragraphs B28 to B33, assume logic that stays fixed until someone changes it under effective general IT controls. For a model, test the deterministic settings around it once and obtain evidence of output accuracy across the period. This is practitioner judgment; no standard addresses it.
Has the PCAOB or the SEC issued rules on AI in ICFR?
None was found on pcaobus.org or sec.gov as of 10 November 2026. The PCAOB has published staff observations (July 2024), amendments on technology-assisted analysis that leave AI aside, and a June 2026 request for comment asking whether AI needs standards or staff guidance. The SEC’s ICFR rules and 2007 guidance are technology-neutral, and the SEC actions read for this guide concern misleading claims about AI.
What does COSO say about generative AI?
On 23 February 2026 COSO released Achieving Effective Internal Control Over Generative AI (GenAI), which applies the 2013 framework’s five components and 17 principles to GenAI by capability type. It is guidance, not a new framework, and it does not say how auditors should test such controls.
Can an AI agent post journal entries or perform close controls?
No rule read for this guide forbids it, but an agent that posts entries, clears matches or certifies reconciliations is inside ICFR. It needs its own identity, authority limits the system enforces, separation from approval, complete logs and a monitoring control over what it did. Its entries go into the journal entry testing population under its own ID.
Does a new AI tool have to be disclosed in the 10-Q or 10-K?
As of November 2026, Exchange Act Rule 13a-15(d) has management evaluate changes in ICFR each fiscal quarter, and Regulation S-K Item 308(c) requires disclosure of a change that materially affected, or is reasonably likely to materially affect, ICFR. Whether a particular tool is such a change is a judgment for management and the disclosure committee. Document the evaluation either way.
Related guides
- SOX Compliance hub — every SOX and ITGC guide on the site, by stage of the SOX year.
- Generative AI Across the Audit Lifecycle — use cases, review gates and failure modes for audit work in general.
- Auditing Agentic AI — authority limits, identity, logging and kill switches for systems that act.
- Testing Automated Controls and System Configurations — the single test, its conditions and benchmarking.
- IPE: Testing Completeness and Accuracy — the rules for information a control or a test relies on.
- Management Review Controls — precision factors and what evidence of review has to show.
- Documenting Analytics as Audit Evidence — what a full-population test has to keep on file.
- How to Review a SOC 1 Report — the ten-question method for vendor reports.
- Getting External Audit to Rely on Your SOX Testing — how the reliance decision is made and earned.
Leave a Reply