On June 25, 2026, Financial Executives International announced the release of the AI Framework: Internal Control Over Financial Reporting, a whitepaper developed by FEI's Committee on Corporate Reporting to help companies integrate artificial intelligence into financial reporting while maintaining effective internal control over financial reporting.
The framework was written by Chief Accounting Officers and Controllers from Meta, Walmart, ServiceNow, and Alphabet. It is built directly on the SEC's definition of ICFR and maps cleanly to the 2013 COSO framework your SOX program is already based on.
It is intended to be a living document that will evolve alongside AI technology and regulatory expectations.
This is not an academic paper or a regulatory signal document. It is a 55-page scoping-and-controls manual written by the people who sign SOX 302 certifications at some of the largest public companies in the world. If your finance function is putting AI anywhere near the numbers, this is the document your audit committee will eventually ask you about. Most committees are not aware of it yet, which is exactly why the proactive step matters: brief the audit committee and finance leadership on the framework before it lands on their agenda from somewhere else.
This post is the plain-language implementation guide the framework itself does not provide. The framework's content is covered section by section, mapped to what a controller at a public company needs to do in the next 90 days.
This blog is distinct from the AI disclosure regulatory signals blog and the forward-looking AI standard preparation blog also in this cluster. Those blogs addressed the question of whether and when AI disclosure will be required in financial statements. This blog addresses a different question: how do you control AI within your existing SOX ICFR program, using the framework that the controllers of four Fortune 100 companies wrote for that specific purpose.
What Is the FEI Committee on Corporate Reporting and Why Does Its AI-ICFR Framework Matter?
FEI's Committee on Corporate Reporting is a high-powered, multi-industry committee of Financial Executives International composed of highly engaged Corporate Controllers and Chief Accounting Officers from Fortune 100 and large public companies. The CCR focuses on engaging accounting standard setters and regulators and has a positive impact through comment letters and other advocacy, including direct engagement with the SEC, FASB, PCAOB, and the Big 4 accounting firms.
The CCR is not a think tank. Its members are practitioners who are directly accountable for the accuracy of their companies' financial statements and who sign the SOX 302 and 906 certifications for some of the largest public companies in the United States. When the CCR publishes a framework, it reflects the judgment of people who are already living with the problem the framework addresses.
The AI-ICFR framework matters for four reasons.
First, it is the first practitioner-built guide for scoping, controlling, and evidencing AI inside the financial reporting chain. Regulatory bodies have issued signals (covered in the companion blog). Big 4 firms have issued client alerts. But no practitioner group has previously published a document this specific about how to bring AI under SOX control.
Second, it is COSO-mapped. FEI is one of COSO's five sponsoring organisations, alongside the IIA, the AICPA, the American Accounting Association, and the Institute of Management Accountants. The framework extends the 2013 COSO Internal Control: Integrated Framework, which is the framework your external auditors already use to assess your ICFR. The framework asks you to extend what you have, not to start over.
Third, it carries institutional weight with audit committees. When an audit committee chair asks the engagement partner whether the company's AI ICFR controls are adequate, the partner's reference point will be the FEI framework. A company that has already mapped its AI use to the FEI framework is in a materially better governance position than one that has not.
Fourth, it is practical. The four control approaches the framework describes (human-in-the-loop, performance testing, multi-model validation, and data analytics) are not aspirational. They are the actual approaches the authors are applying at Meta, Walmart, ServiceNow, and Alphabet today.
What Did Meta, Walmart, ServiceNow, and Alphabet's Controllers Agree On About AI in ICFR?
The framework's foundational position: COSO and SOX remain the governing architecture for ICFR, and they remain sound. The problem is not the frameworks themselves. The problem is that they were not designed for an operating environment in which AI systems are making, influencing, or validating financial reporting decisions. AI adoption in finance is outpacing the development of governance guidance specific to it.
The four things the controllers specifically agreed on:
First: AI does not change what is material, or who is accountable. The bar is still reasonable assurance under SOX, still evidenced by the 302 and 906 certifications. AI is additive to your ICFR program, not an exception to it.
Second: it slots into your existing COSO program. The framework supplements the 2013 COSO framework rather than replacing it. You extend what you have; you do not start over.
Third: scoping is the hard part, and the trap is the intermediate step. Reliance lives in AI extraction, classification, and matching long before the final number. Scope the system end to end, and hold AI-as-the-control to a higher bar than AI-in-the-process.
Fourth: the evidence model expands. Prompts and model versions become change-managed configuration items, and your external auditor belongs in the design phase, not at year-end.
What the framework explicitly rejects: treating AI as exempt from SOX because it is new and technically complex, and treating AI as so dangerous that it gets a parallel control regime disconnected from the existing program. Both approaches produce control deficiencies. The framework's answer is that AI controls are ICFR controls, subject to the same design, testing, and documentation standards as every other control in your SOX programme.
The Framework's Core Premise: If AI Influences Financial Reporting, It Becomes Part of Your ICFR
The threshold question for AI and ICFR is whether the AI system influences a material financial reporting amount or assertion. The framework's answer to this question is broader than most SOX teams currently apply.
Reliance is broader than the final output. Take an accounts payable process where AI extracts invoice data, classifies the expense, and routes for approval. Even if a human triggers the final payment, you are relying on the AI's extraction and classification for accuracy and completeness. If any component activity is necessary to mitigate a risk of material misstatement, the AI system is in scope. Teams that scope only the final number will miss this, and so will their auditors, right up until they do not.
The framework also draws a critical distinction between AI in the process and AI as the control. When AI does the work and a human or non-AI control validates it, that is one compliance path with one set of control requirements. When AI is the control (reviewing expense reports to flag policy violations, for example), the bar is higher and the validation procedures are more rigorous. Getting this distinction wrong is how teams end up with a control that does not actually control anything.
AI introduces failure modes that traditional ICFR risk assessment was not built for. Hallucination, the tendency of AI systems to generate plausible-sounding but factually incorrect outputs, can affect financial estimates, disclosure language, and analytical summaries in ways that are difficult to detect without deliberate validation procedures.
The practical scoping rule the framework establishes: define the system boundary from data ingestion to financial impact, and test the integrated outcome rather than fragmented components. Many AI systems are a mix of probabilistic models and deterministic workflows. Fragmentation creates an onerous compliance burden and, worse, can miss the failure where every part works but the integrated output is materially wrong.
The Three-Tier AI Classification: How the Framework Categorizes AI by ICFR Risk Level
The brief describes a three-tier AI classification. The framework's actual structure uses a risk-level spectrum rather than formally numbered tiers, but the risk progression from AI-assisted SOX programme management to AI as a key control to agentic AI is the framework's organising principle. Each level is addressed below in the three following sections.
The classification logic: the ICFR risk level of an AI use increases as the AI's involvement in producing or verifying financial amounts becomes more direct and autonomous. An AI that assists a human reviewing a control is lower risk than an AI that is itself the control. An AI that autonomously executes a financial reporting process without human review of each transaction is the highest risk category.
Tier 1, AI-Assisted SOX Program Management: What Controls Are Required?
At the lowest risk level, AI assists humans in managing the SOX programme without directly influencing financial statement amounts. Examples include AI tools that help organise control documentation, identify testing samples, summarise control narratives, or flag changes in the control environment for human follow-up.
For this use category, the framework's control requirements are the lightest. The AI output is a management input, not a financial reporting input. A human uses the AI's output to make decisions, and the human's decision is the control event, not the AI's analysis.
The primary control requirement at this level: document that the AI tool is being used in the SOX programme and describe the human review applied to its outputs. The output monitoring controls are less intensive because the financial statement impact is indirect.
The evidence requirement: prompts used to generate AI analysis of the control environment should be documented. Model versions used should be tracked. These are now configuration items in the SOX programme documentation, just as the version of the testing methodology template would be tracked.
The shadow reliance risk (discussed in more detail below) exists even at this level. If the SOX team is relying on AI summaries of control documentation to plan their testing without independent verification of those summaries, the AI has become a de facto input to the testing programme even if it was intended only as an organisational tool.
Tier 2, AI as a Key Control Over Significant Accounts: What the Framework Requires
At the intermediate risk level, AI is a key control in the ICFR programme. It is not assisting a human who then makes the control decision; the AI system is the control that prevents or detects material misstatements.
Examples include an AI system that reviews all journal entries for anomalies consistent with financial statement fraud, flags them for human review, and provides the first-pass completeness and accuracy assessment that the journal entry control relies on. Or an AI model that generates the credit loss reserve estimate that management then reviews and approves. The AI's output is a direct input to a financial statement amount.
When AI is the control, the bar is higher, and you owe the more rigorous validation procedures. This is AI-as-the-control, and it requires the most rigorous of the four control approaches the framework describes.
The four control approaches the framework provides for this level:
Human-in-the-loop oversight: a human validates the AI output before it is finalised. The framework treats this as the starting point for most AI control environments. It provides the highest assurance and the clearest evidence. It is also the most expensive and carries the shadow reliance failure mode described below.
Performance testing: run curated test data with known correct answers through the system on a recurring basis and compare the results. Best for high-volume, similar transactions with a defined range of outcomes. The test data must represent the population including the bad scenarios the system should reject, not just the clean ones it should process.
Multi-model validation: run an independent challenger model in parallel and flag disagreements for human review. The two models must be genuinely independent: separate context windows, parallel execution, different vendors, different versions, different prompts. If the challenger shares the primary model's bias, you have built two witnesses who will produce the same error.
Data analytics: monitor the full population for anomalies, drift, and trend breaks. Broad coverage, lower precision. Analytics alone is usually not precise enough to be the only key control, but it is a strong second layer.
Tier 3, Agentic AI in ICFR: Why the Framework Treats This as a Material Weakness Risk Without Robust Human Oversight
Agentic AI refers to AI systems that autonomously execute multi-step processes, make decisions at each step, and complete a defined task without human review of each individual action. In financial reporting terms, an agentic AI might autonomously perform the period-end close for certain account categories, reconcile accounts, post journal entries, and generate the supporting documentation, with humans only reviewing the final output.
The framework treats agentic AI in ICFR as the highest-risk category and flags it as a potential material weakness risk unless robust human oversight is designed into the process at specific checkpoints.
The material weakness risk the framework identifies is not that agentic AI will fail in an obvious way. It is that agentic AI can fail silently. <cite index="39-1">A manual control fails visibly: a human does not perform the reconciliation, and the gap is obvious. An AI control can fail silently, producing plausible but incorrect outputs without triggering any exception flag. The system appears to be running. The dashboard shows green. The material misstatement goes undetected.
The framework's specific concern with agentic AI in ICFR is the absence of natural human checkpoints in the process. Every human-executed financial reporting process has inherent review moments: the human controller looks at the number and applies judgment before passing it to the next step. Agentic AI eliminates those inherent review moments, replacing them with automated decision logic that may not be configured to catch the specific error patterns that human judgment would identify.
The framework's required response to agentic AI in ICFR: design explicit human oversight checkpoints into the agentic workflow at the points where material misstatement risk is highest. Document those checkpoints as ICFR controls. Test them with the same rigour as any other key control. And assess whether the agentic AI's output monitoring is sufficient to detect failures between the human checkpoints.
How the Framework Maps to the 2013 COSO Framework Your SOX Program Already Uses
The AI governance and oversight controls map to the Control Environment. The AI-specific risk identification and the requirement to fold AI vectors into your fraud risk assessment map to Risk Assessment, including COSO Principle 8. The four control approaches laid out in the framework are Control Activities. The auditability and evidence requirements live in Information and Communication. Outlier and performance monitoring is Monitoring Activities.
This COSO mapping is the most operationally useful element of the framework for SOX teams. It means that the FEI AI-ICFR framework does not require building a new governance structure. It requires extending the existing COSO-based SOX programme to cover AI using the same five-component architecture already in use.
The Control Environment extension: does the company have a policy governing the use of AI in financial reporting processes? Does it specify which tools are approved, what approval process is required before introducing a new AI tool into a financial reporting process, and what documentation is required for each tool in use?
The Risk Assessment extension: has the AI-specific risk taxonomy been added to the annual risk assessment? The framework specifically flags hallucination risk, model drift risk, data quality risk, and shadow reliance risk as AI-specific risks that must be assessed in the ICFR risk assessment alongside traditional fraud and error risks.
The Control Activities extension: for each AI tool in the ICFR scope, has one or more of the four control approaches (HITL, performance testing, multi-model validation, analytics) been selected, documented, and tested?
The Information and Communication extension: is the AI system's configuration, including model versions and prompts, documented and change-managed? Is the evidence produced by AI controls (output logs, review certifications, performance test results) retained and accessible to external auditors?
The Monitoring extension: is there a periodic process for assessing whether AI controls are operating as designed? Does that process include testing for shadow reliance in HITL controls?
What the Framework Says About Vendor Risk: The Model Drift and Audit Trail Problem
Your vendors are embedding AI into the systems you already rely on, the ERP, the close tool, the contract reviewer, often without announcing it in a way your SOX program will catch. The framework's guidance is direct: read SOC 1 reports in their entirety for AI use, with specific attention to whether vendors are carving AI-assisted processes out of their assertions, explicitly or through broad exclusions. Monitor release notes for new AI features. Request documentation on which modules use AI.
The risk the framework identifies is not just that the vendor's AI is flawed. It is that AI risk has quietly moved into a system you stopped scrutinising because last year's SOC 1 was clean. That SOC 1 may no longer cover what you think it covers because the vendor has introduced AI-assisted features into previously manual processes.
Model drift is the specific audit trail problem the framework flags for vendor AI. Model drift occurs when an AI model's accuracy degrades over time as the data it processes changes while the model's parameters remain unchanged. A credit risk model trained on pre-2020 data may perform poorly on post-pandemic loan performance. An accounts payable matching AI trained on one vendor's invoice format may degrade in accuracy when the vendor changes its invoice structure.
For ICFR purposes, model drift in a vendor-provided AI tool is a control failure that may not be visible to the company unless it is specifically testing for it. The vendor's SOC 1 report, if it does not explicitly address the AI tool's accuracy monitoring and revalidation frequency, does not provide the assurance the company needs.
The practical action item: for each vendor-provided AI tool in the ICFR scope, request documentation of the vendor's model revalidation frequency and methodology. If the vendor's SOC 1 report does not cover the AI tool's accuracy and the vendor cannot provide independent evidence of ongoing accuracy monitoring, treat the vendor AI tool's output as an unvalidated input and apply compensating controls.
What Your Audit Committee Will Eventually Ask About This Framework and When
The audit committee will eventually ask about this framework. Most committees are not aware of it yet. The timing of that audit committee question depends on three triggers.
The first trigger is the external auditor. External auditors at public companies with significant AI use in their close processes are already asking management about AI ICFR controls as part of the year-end audit planning process. When the engagement partner asks whether AI tools are within the ICFR scope, the FEI framework is the reference document they are using to assess the quality of the company's answer.
The second trigger is a regulatory inquiry or SEC comment letter. As discussed in the AI disclosure regulatory signals blog in this cluster, SEC comment letters on AI claims in financial filings are an existing enforcement mechanism. A company that receives a comment letter asking about AI use in its financial reporting process will be asked to describe its AI controls. The FEI framework is the most defensible reference for that description.
The third trigger is a peer company disclosure. When a peer company begins disclosing its AI ICFR framework in its annual report (which some companies have done voluntarily, and which may become required under future disclosure standards), the audit committee will ask management why the company has not done the same.
The proactive approach: brief the audit committee on the FEI framework at the Q3 or Q4 board meeting, before any of the three triggers occurs. Include the AI inventory summary, the ICFR scope assessment results, and the control approach selections for each AI tool in scope.
A Controller's Implementation Checklist Based on the FEI Framework
Six actions in the next 90 days, drawn directly from the framework's closing recommendations.
One: build the SOX-relevant AI inventory. Not every AI tool in the enterprise. The focused set that could give rise to a material misstatement. Start from your key controls, which are already tied to material risks, and map where AI touches them.
Two: re-run the reliance test on existing processes. Look past the final output to the intermediate steps. Find where AI extraction, classification, or matching is already feeding a number you rely on, even in processes you do not currently consider AI-dependent.
Three: stress-test human-in-the-loop controls for shadow reliance. If a process is documented as human-reviewed, confirm the human is actually reviewing. Seed a known error into the population and confirm the human catches it. If they do not, your HITL control is producing false assurance, and you want to know that before a misstatement slips through it.
Four: treat prompts and model versions as change-managed configuration items. A prompt change is a change to the system that produces your financial data. It belongs in your change management and SOD program, the same as a code change. Most companies are nowhere near this today.
Five: re-read critical vendors' SOC 1 reports specifically for AI. Look for carve-outs and exclusions around AI-assisted processes. Request evidence of model revalidation frequency and methodology for any vendor AI tool in the ICFR scope.
Six: involve your external auditor early, in the design phase. AI in the financial reporting chain is novel enough that you do not want to discover at year-end that your control design produces evidence the auditor will not accept. Align on approach and evidence standard before you build, not after.
Frequently Asked Questions
What is the FEI AI-ICFR framework?
The FEI AI Framework: Internal Control Over Financial Reporting is a whitepaper developed by FEI's Committee on Corporate Reporting to help companies integrate AI into financial reporting while maintaining effective ICFR. It is a 55-page scoping-and-controls manual written by Chief Accounting Officers and Controllers from Meta, Walmart, ServiceNow, and Alphabet. It was released on June 25, 2026 and is available through Financial Executives International.
Who published the FEI AI-ICFR framework?
The framework was authored by a cross-industry group of corporate controllers, chief accounting officers, and accounting leaders from Fortune 100 and large public companies, with input from academia.</cite> FEI's Committee on Corporate Reporting, whose members hold CAO and controller positions at Fortune 100 companies including Meta, Walmart, ServiceNow, and Alphabet, is the authoring body.
Does the FEI framework have regulatory force or is it voluntary?
The framework is voluntary practitioner guidance, not a regulatory requirement. It does not create new requirements. It applies existing ICFR requirements to AI. However, its authorship by Fortune 100 CAOs and controllers who sign SOX 302 certifications gives it institutional weight that pure think-piece guidance does not carry. Audit committees and external auditors will use it as a reference.
How does the FEI AI-ICFR framework map to COSO?
The framework supplements the 2013 COSO Internal Control: Integrated Framework rather than replacing it. FEI is one of COSO's five sponsoring organisations. The AI governance and oversight controls map to the Control Environment; AI-specific risk identification maps to Risk Assessment (including COSO Principle 8); the four control approaches are Control Activities; auditability and evidence requirements are Information and Communication; and outlier and performance monitoring is Monitoring Activities.
What is shadow reliance and why does the framework flag it as a significant risk?
Shadow reliance occurs when a process is documented as human-in-the-loop, technically a non-reliance control, but in practice the human reviewer has become dependent on the AI's speed and apparent accuracy and is rubber-stamping outputs. The control exists on paper and has quietly stopped operating. The pattern gets worse precisely as the AI gets better, because a system that is right 99 times in a row trains the reviewer to trust the hundredth without looking.
Does using AI in the financial close mean it must be tested as an ICFR control?
If any component activity is necessary to mitigate a risk of material misstatement, the AI system is in scope. Teams that scope only the final number will miss intermediate steps where AI extraction, classification, or matching is already feeding a material amount. The scoping test is whether the AI use is necessary to mitigate a risk of material misstatement, not whether the AI directly produces a financial statement number.
What is model drift and why is it an audit trail problem?
Model drift occurs when an AI model's accuracy degrades over time as the data it processes changes while the model's parameters remain unchanged. For ICFR purposes, a vendor-provided AI tool experiencing model drift is a control failure that may not be visible without periodic performance testing. The audit trail problem arises when the vendor's SOC 1 report does not cover the AI tool's accuracy monitoring and revalidation, leaving the company without evidence that the control is operating effectively.
Key Takeaways
- On June 25, 2026, FEI's Committee on Corporate Reporting released the AI Framework: Internal Control Over Financial Reporting, a 55-page practitioner-built guide for integrating AI into financial reporting while maintaining effective ICFR.
- The framework was written by CAOs and controllers from Meta, Walmart, ServiceNow, and Alphabet. It is built on the SEC's definition of ICFR and maps directly to the 2013 COSO framework.
- The framework's core position: AI does not change what is material or who is accountable. The bar is still reasonable assurance under SOX, evidenced by the 302 and 906 certifications. AI is additive to your ICFR program, not an exception to it.
- The framework provides four control approaches for AI in ICFR: human-in-the-loop oversight, performance testing, multi-model validation, and data analytics. Most companies in early adoption will use a combination, with HITL as the primary approach and testing and analytics as secondary monitoring.
- Shadow reliance is the framework's most important risk finding: a HITL control that is documented as human-reviewed but where the human has stopped genuinely reviewing. The mitigation is to seed known errors into the population periodically and confirm the human catches them.
- Prompts and model versions are now change-managed configuration items. A prompt change is a change to the system that produces financial data, and belongs in the change management and SOD programme.
- Vendor AI risk: read every SOC 1 report for AI carve-outs and request evidence of model revalidation frequency. AI has been embedded into ERP and close tool platforms without announcement in ways that existing SOC 1 assurance may not cover.
- The 90-day implementation programme: AI inventory, reliance test, HITL shadow reliance stress test, prompt change management, vendor SOC 1 review, and external auditor design-phase alignment.
