AI has moved into financial reporting itself — proposing journal entries, drafting variance commentary — but a named officer still has to personally certify, under SOX Section 302, that the numbers fairly present the company’s condition. Shreyas Sampath argues that when a model rather than a person produces the output, the “reasonable basis” behind that signature quietly erodes.
When an AI model proposes a journal entry that gets recorded in the books or drafts the variance commentary that informs the financial report, a named officer still has to sign the Section 302 certification attesting that, to their knowledge, the financials fairly present the company’s condition.
“To their knowledge” is tricky here. It assumes the officer has a reasonable basis for what they are certifying. When a person prepares the number, that basis was a chain of people who could each explain their judgment. When a large language model (LLM) generates it, the chain has a gap where a reviewer used to sit, and the officer is the one who signs over that gap.
The teams I work with at Fortune 500 companies have moved AI into reporting workflows without settling what the certifying officer’s reasonable basis rests on once a model, not a person, produces the output. The answer most of them reach for — that IT owns it — is one that fails an audit.
The pressure to deploy is real, and adoption is outpacing oversight. More than half of finance leaders now use AI in some capacity, and the fastest movers are pushing it into financial reporting itself, where AI output no longer just supports human judgment. It shapes the numbers a named executive has to personally certify as accurate.
The reason this falls to the officer rather than staying a technical detail is that finance AI is not a single thing. Summarizing board prep with an LLM sits in a very different risk category than using AI to draft variance commentary or propose journal entries that get recorded in the books. One category supports a decision a person still makes and owns. The other produces output that becomes part of the record the officer attests to.
Most teams configure both kinds of use cases the same way, which is where the exposure builds quietly. The governance a decision-support tool needs and the governance a reporting-critical tool needs look almost nothing alike, and the officer inherits the difference.
Research published by WTW in March 2026 framed this as an emerging AI governance gap under Sarbanes-Oxley (SOX), with direct implications for officer certifications under Section 302. When SOX was written in 2002, it assumed a person made the material decision and could be asked to explain it. A model that generates an output from statistical patterns cannot be deposed, cannot walk an auditor through its reasoning and cannot stand behind a number the way a controller can. The reasonable basis the officer certifies to has to come from somewhere else, which means it has to be built into how the model is governed before the output ever reaches the certified statements.
Consider a use case nearly every organization wants to automate: transaction approval workflows. The logic appears straightforward. When a transaction meets a defined threshold, it should auto-approve. For categories like payments, however, the complexity surfaces quickly.
On a recent client engagement, transactions satisfied every threshold rule configured in the system, yet the underlying payment data was wrong. The result was a series of over- and underpayments to vendors, each one creating reconciliation work, compliance exposure and vendor-relationship fallout that dwarfed whatever efficiency the automation had bought. Now follow that error up the chain. Those payments hit the ledger. The ledger feeds the reporting cycle. That cycle produces the financials an officer certifies. If someone asks that officer what gave them a reasonable basis to sign, the honest answer is that an automated control approved the transactions, and the control was confirming the rule rather than the data. That is a thin basis to certify against, and it was thin from the moment the workflow was designed to validate thresholds without validating what fed them.
The reason this basis erodes so quietly is that the controls meant to protect it were built for a different actor. Internal control frameworks were designed to test whether a person followed a documented procedure. That logic does not translate cleanly to AI surfacing a reconciliation exception or drafting a journal entry for human review. When a model generates the proposal, the review control alone may not be sufficient, and the model itself often needs to be validated as part of the control design; these are choices that need to be made at Sprint One rather than discovered in Q4.
The pattern I see converging at larger audited organizations is narrower than AI vendor pitches might suggest. AI surfaces exceptions, identifies anomalies and drafts supporting analysis. A human retains sign-off on anything that flows to external reporting. The PCAOB has reinforced this direction in public remarks through 2025 and early 2026, describing AI as a tool that should support rather than replace professional judgment with clear documentation of how outputs are generated and reviewed.
Teams getting this right design for audit readiness from the first sprint. Model documentation, input lineage and review evidence are built into the workflow, not retrofitted once the auditors start asking questions. More than three-quarters of executives lack strong confidence they could pass an independent AI governance audit within 90 days, which is a clear signal that retrofitting is what most programs are doing.
These teams also treat governance as a finance-led discipline. AI model validation for reporting workflows is not an IT problem. Finance owns the control, so finance has to own the parameters, the thresholds and the documentation standard.
In my ERP and finance transformation work, “audit-ready from Sprint One” is less about documentation volume and more about a handful of non-negotiables that get locked in at kickoff. Three artifacts I insist on before any configuration begins: a requirements control matrix, a data architecture and process flow diagram mapping every automated decision point as well as functional and technical specs that define what a reviewer must see, capture and retain for every AI-assisted output that touches certified reporting.
10 Questions Every Organization Should Ask a Potential AI Vendor
Adopting AI without understanding how it was built and how it handles data can expose an organization to risks that surface only once something goes wrong
Read moreDetailsWhy ‘IT owns it’ leaves the officer exposed
The programs that consistently stall are the ones treating AI governance as an IT deliverable. The controls end up technically sound and operationally orphaned. When the auditor asks who owns model drift monitoring for the tool that proposes accruals, finance points to IT, IT points to the vendor and nobody has a defensible answer. The officer who signed the certification is standing at the end of that chain, and the chain does not reach a person who can account for the number.
Recent analysis from KPMG and Grant Thornton point to the same conclusion: Effective programs run on joint ownership across finance, IT, internal audit and the control owners themselves.
The gap I see most often is finance quietly outsourcing the governance question to IT because the underlying technology feels unfamiliar. The conversation usually starts with “IT is handling the AI piece,” which is a reasonable answer for infrastructure, model hosting and integration, but not for the parameters that determine whether an output is materially correct. Finance owns the threshold for what counts as a reasonable accrual, what constitutes an acceptable variance and what level of review a high-dollar payment requires. When those parameters get set by an IT team or a vendor default because finance never showed up to the design sessions, the control exists on paper but has no one in finance who can defend it to an auditor. Those parameters are the reasonable basis, restated in operational terms. An officer cannot certify a number with confidence when the thresholds behind it were set by whoever configured the tool, and finance is the only function positioned to set them well enough to make them worth standing behind.
Building the basis before the signature
The finance teams that pull ahead this year will treat AI adoption and control design as the same project, accepting a slower first sprint in exchange for something that scales. The deployment pressure is real, and 74% of CFOs now rank AI deployment as a top-three strategic priority. That pressure is exactly why the certification question cannot wait.
Every workflow that moves AI closer to certified reporting adds another output an officer will eventually sign over, and the reasonable basis for that signature is either designed in at Sprint One or reconstructed under audit pressure later. Teams who understand that are building the basis now, while it is still a design choice rather than a deposition.
Shreyas Sampath is a manager in the finance transformation practice of a Big 4 consulting firm, where he leads M&A finance integrations and enterprise resource planning (ERP) implementations for Fortune 500 clients across the technology, media, telecommunications, consumer and life sciences sectors. With over a decade of experience across Big 4 consulting and enterprise SaaS, Sampath specializes in chart-of-accounts migrations, Day One readiness planning and the application of AI within enterprise finance and accounting functions. 
