Key takeaway
AI does not change the SOX 404 test. If an AI tool produces information a control relies on, or performs part of a control, that control still needs a named owner, a defined precision, and review evidence that supports management's 404(a) assessment and, where 404(b) applies, can be tested by the auditor under PCAOB AS 2201.What is SOX 404?
SOX Section 404 requires a public company to assess and report on the effectiveness of its internal control over financial reporting (ICFR) each year. The SEC implements it through Item 308 of Regulation S-K, and management must evaluate ICFR against a suitable framework. Most companies use the COSO 2013 Internal Control-Integrated Framework.
In practice, management does five things each year:
- Identifies the significant accounts, disclosures and risks of misstatement.
- Documents the controls that address those risks.
- Evaluates, through testing or ongoing monitoring scaled to risk, whether the controls are designed well and operated as designed.
- Assesses any deficiencies, alone and together.
- Concludes whether ICFR was effective at year-end. Management cannot conclude that ICFR was effective if one or more material weaknesses exist at year-end, and it must disclose them.
Section 404 sits next to Section 302, which requires the CEO and CFO to certify each periodic report. SOX compliance documentation is the record behind both: the control descriptions, the test work and the conclusions.
What is the difference between 404(a) and 404(b), and who needs which?
404(a) is management's assessment, and it applies to public companies filing annual reports. 404(b) is the registered auditor's attestation on ICFR, and it applies to accelerated and large accelerated filers. Both are anchored to year-end.
| Company | 404(a) management assessment | 404(b) auditor attestation |
|---|---|---|
| Large accelerated filer (public float of $700 million or more, and reporting for at least 12 months with one annual report filed) | Required | Required |
| Accelerated filer (public float of $75 million to under $700 million, not eligible as a smaller reporting company under the revenue test, and reporting for at least 12 months with one annual report filed) | Required | Required |
| Non-accelerated filer, including a smaller reporting company with under $100 million of revenue and under $700 million of float | Required | Not required |
| Emerging growth company | Required | Not required while it keeps EGC status |
| Newly public company, first annual report | Not required in the first annual report | Not required in the first annual report |
Filer status is determined at each fiscal year-end, using public float as of the last business day of the second fiscal quarter and annual revenue. Lower thresholds apply when leaving a category: below $60 million of float, or qualifying as a smaller reporting company under the revenue test, to leave accelerated filer status, and below $560 million of float to leave large accelerated status. Confirm status before you plan the year's testing. The non-accelerated exemption from 404(b) comes from Section 404(c), added by Section 989G of the Dodd-Frank Act, and the emerging growth company exemption comes from the JOBS Act. A non-accelerated filer still owes the 404(a) assessment, so it still needs documented, tested controls.
What changed for SOX 404 in 2026?
As of October 21, 2026, the statute and the 404(a) and 404(b) requirements are unchanged. Two 2026 developments matter to SOX teams:
- COSO published AI guidance. On February 23, 2026, COSO released Achieving Effective Internal Control Over Generative AI, which applies the 2013 framework to generative AI. See Deloitte's summary.
- The SEC proposed new filer-status categories. On May 19, 2026, the SEC proposed in Release 33-11419 to raise the large accelerated filer threshold from $700 million to $2 billion of float (met for two consecutive years, after at least 60 months as a reporting company) and to merge the accelerated filer and smaller reporting company categories into a single non-accelerated category. Companies outside the new large accelerated category would no longer need 404(b). The comment period closed July 20, 2026. As of October 21, 2026, the proposal has not been adopted, so the thresholds in the table above still apply.
We have not found a PCAOB standard written specifically for AI-assisted controls. PCAOB staff published observations on generative AI in audits and financial reporting in July 2024, and amendments to AS 1105 on technology-assisted analysis apply to audits of fiscal years beginning on or after December 15, 2025. Neither changes how AS 2201 evaluates a control.
How do AI-assisted controls fit ICFR under COSO 2013 and the COSO AI guidance?
AI-assisted controls fit ICFR the same way any control does: through the five COSO 2013 components (control environment, risk assessment, control activities, information and communication, and monitoring) and its 17 principles. The February 2026 COSO publication adapts that structure to generative AI instead of creating a new framework, and Deloitte describes a roadmap of govern, inventory, assess, design, implement and monitor. For a plain-language read, see our post on COSO's new AI governance framework.
The first question is where the AI sits in the control. There are three common patterns:
- AI produces information that a control relies on. An example is contract terms extracted by AI that a reviewer then uses. That output is information produced by the company, so someone has to address its completeness and accuracy.
- AI drafts and a person reviews. The review is the control. A review that only skims the AI output, without comparing it to the source, does not address the risk that the AI is wrong.
- AI performs the control activity. An example is automated matching or exception flagging. This looks like an automated control, so the auditor will ask about the controls over changes to the tool and what happens when it fails without an alert.
If a third-party vendor processes transactions or performs control activities for you, the vendor may be a service organization under PCAOB AS 2601 and AS 2201 Appendix B, and your auditor may ask for a SOC 1 Type 2 report and evidence that you perform the complementary user entity controls it lists. Whether a software vendor is a service organization depends on what it hosts or processes for you, and a tool your staff operate can still raise the question if the vendor hosts data a control relies on, so confirm the approach with your auditor. Management's responsibility for ICFR does not move to the vendor.
Is AI prohibited in SOX ICFR controls?
No. As of October 2026 we have not found a PCAOB or SEC rule, or COSO guidance, that bans AI in ICFR or lists prohibited uses. Neither Section 404 nor AS 2201 addresses AI specifically. The risk comes from how AI is deployed: no owner, no precision, no evidence of review, or tool changes nobody tracked. Those show up as design or operating deficiencies under the same tests as any other control.
What do auditors test under PCAOB AS 2201?
Under AS 2201, auditors take a top-down, risk-based approach. They start at the financial statement level and with entity-level controls, then work down to significant accounts and relevant assertions, understand how misstatements could arise, and test the controls that address those risks for both design and operating effectiveness. They evaluate every deficiency found, and they classify it as a deficiency, a significant deficiency or a material weakness.
For an AI-assisted control, expect the auditor to ask:
- Who owns the control, and who covers when that person is out?
- What exactly does the reviewer compare, and to what threshold?
- How is the completeness and accuracy of the AI output checked (PCAOB AS 1105)?
- What changed in the tool, the prompt or the model during the period, and who approved it?
- What evidence is kept for each occurrence, and can the auditor reperform it?
What should you document for a SOX control?
Document enough that a person who did not perform the control could reperform it. For each key control, record:
- The risk and the assertion the control addresses.
- Who performs the control (role, with a backup) and how often it operates.
- The population the control covers and the data or report it uses.
- The precision: what size or kind of error the control would catch.
- How the completeness and accuracy of any report or AI output is established.
- The evidence kept for each occurrence, and how exceptions are resolved.
- For AI-assisted controls: what the AI does, what the person does, and how tool changes are approved.
How do you document one AI-assisted control? A worked example
The control below is illustrative. The threshold and roles are examples, not benchmarks, and a real control should reflect your own risk assessment.
The situation. A software company uses AI to extract key terms (price, payment terms, contract term, start date, renewal and termination rights, and the goods and services promised) from new customer contracts and amendments, then sets up the contract in its revenue system. The revenue accounting manager, not the AI, decides the performance obligations and the price allocation, and a separate control covers those ASC 606 judgments. The risk here is that a wrong extracted term leads to misstated revenue.
| Attribute | Documentation |
|---|---|
| Risk and assertion | Contract terms are set up inaccurately, which could misstate revenue (occurrence, accuracy, cutoff). |
| Control description | Before set-up, the revenue accounting manager compares each AI-extracted term to the signed contract and any amendments or side letters, and resolves differences. After set-up, the manager agrees the revenue system record to the approved extraction. AI drafts the extraction; the manager's comparison and the set-up tie-out are the control. |
| Owner | Revenue accounting manager. The assistant controller is the named backup. |
| Frequency and population | Each new contract or contract modification with total contract value above $250,000 (illustrative). Contracts at or below that amount are covered by a separate control, sized so that errors below the threshold could not add up to a material misstatement. |
| Precision | Every extracted field that drives revenue (price, payment terms, term, start date, renewal and termination rights, goods and services promised) is compared to the source, with a reference to the contract section for each field. Any difference is corrected and logged, with no tolerance. The $250,000 population threshold defines which contracts this control covers, and the separate control addresses the rest. |
| Completeness and accuracy of information used | Because every field is compared to the signed contract, the control does not rely on the AI output itself. It relies on the list of new contracts. Each month, someone other than the reviewer reconciles that list to new bookings and contract changes recorded in the CRM, billing system and contract repository, and confirms every new contract and modification above the threshold appears in the review log. |
| Review evidence | A dated checklist per contract showing each field compared, the contract section it ties to, corrections made, and the reviewer's sign-off. Kept with the extraction output, the signed contract and the set-up tie-out. |
| Change control | A log of changes to the AI tool, model version, prompts or extraction template, with who approved each and when. For vendor-hosted models, the company also relies on vendor change notices or a SOC report. After any change, the extraction is retested on a sample of contracts. This keeps extraction errors low. The control does not rely on it, because every field is still compared to the signed contract. |
| Exceptions | Differences found are logged and reported to the controller each quarter. A pattern of extraction errors triggers a deficiency evaluation. |
What the auditor does. The auditor selects contracts from the population, reperforms the field-by-field comparison, and inspects the signed checklist and the change log. If the evidence shows the manager only read the AI summary and never opened the contract, the control as performed does not address the risk. That is a deficiency in operation, even though the control description reads well.
What should SOX compliance software do?
Good SOX compliance software keeps the control record in one place. At a minimum, look for these capabilities:
- A control library with risks, assertions, owners and testing procedures.
- Evidence collected and retained for each occurrence of a control.
- Testing workflows, with sampling and documented results.
- Deficiency tracking from identification through remediation.
- Access controls, and a history of who changed what.
Gaapio is an AI-powered technical accounting platform built by CPAs. Its SOX controls product is coming soon and is being designed around those same jobs: documenting controls, assisting with testing workflows, and organizing documentation for auditor review. Request early access below.
Frequently asked questions
Get early access to Gaapio SOX Controls
Tell us how your team documents and tests controls today. We will show you where the product is headed.
References: Sarbanes-Oxley Act of 2002, Sections 302, 404, 906; Dodd-Frank Act Section 989G; JOBS Act Section 103; SEC Regulation S-K Item 308; Exchange Act Rule 12b-2; SEC Release 33-8810 (management's evaluation of ICFR); SEC Release 33-11419 (filer status, proposed May 19, 2026); PCAOB AS 2201 (including Appendix B), AS 1105 and AS 2601; SEC Release 34-88365 (2020 filer-status amendments); COSO, Internal Control-Integrated Framework (2013); COSO, Achieving Effective Internal Control Over Generative AI (February 2026); Deloitte Heads Up on the COSO generative AI publication (2026). This page is general information, not accounting or legal advice for a specific entity.
Written and maintained by the Gaapio team of CPAs. Last reviewed October 21, 2026.
