AI coding in finance teams needs a control framework now
OpenAI's finance organization is writing its own close and reporting tools with AI assistants, and most companies have no policy covering who reviews that code or whether auditors will test it.
For two decades the finance function bought software. It is now starting to write it. CFO Dive reported this week that OpenAI's finance organization is experimenting with AI-assisted coding inside the finance function itself, building close and reporting utilities rather than procuring them. AI coding in finance teams is arriving faster than the control frameworks meant to govern it, and the gap is going to surface first in the close.
Why finance is building instead of buying
The build impulse is a budget response as much as a technology one. MarketScale reported in late June that CFOs are tightening AI budgets even as agentic platforms and hardware deals multiply, and followed with reporting that sharper capex scrutiny is reshaping how enterprise buyers justify tech spending. Separately, EY research covered by CFO Dive found CFOs self-reporting weak AI readiness at the same time ROI pressure is rising. When a vendor cannot demonstrate payback and the seat licence renews anyway, an analyst with a coding assistant starts to look like the cheaper path.
The economics are not trivial. Every internally built utility is one fewer module a company renews, which quietly changes the negotiating position with ERP and close-management vendors. That matters more now that seat-based software pricing is drifting toward consumption models across the industry. A finance team that can generate its own variance-commentary script has leverage it did not have in the last renewal cycle.
But the leverage comes attached to a liability. Trintech's CFO told CFO Dive in April that the AI journey in the financial close is not a sprint. The close is precisely where homegrown code lands first, because that is where the repetitive, rule-based work sits and where an analyst's frustration is highest.
Three control questions with no owner
Suppose an FP&A analyst generates a reconciliation script with an AI assistant on a Tuesday afternoon and it runs in the October close. Three questions have no assigned owner in most organizations today.
First, who reviews the code. Not who runs it, who reads it. AI assistants produce plausible logic that can silently mishandle edge cases such as intercompany eliminations, foreign-exchange rounding or a period-end cutoff. A reviewer needs both the accounting judgment and enough technical literacy to spot the failure mode, and that combination is rare on a finance team's org chart.
Second, whether it sits in scope for ICFR and SOX key-control testing. If the script feeds a number into a material account balance, the answer is almost certainly yes, regardless of who wrote it. Third, and most consequential, whether the external auditor treats it as a spreadsheet under end-user computing guidance or as an application requiring IT general controls coverage. Those two answers carry very different testing burdens. Access, change management and program development controls apply to one and not the other, and the classification will not be your choice alone.
A working control framework for finance-authored code
The practical answer is a tiered model, not a ban. Tier one is the finance-owned repository: analytical, non-reporting utilities that inform judgment but do not post entries or produce a number in the statements. Data pulls for a board deck, scenario models, anomaly scans. These need version control and a named owner, but not an IT gate.
Tier two is anything that touches a journal entry, a reconciliation used as evidence, or a disclosure input. This requires a second-person code review with sign-off logged, a documented test of the logic against a known-good period, and inclusion in the control matrix as a documented process. Tier three is anything that writes to the ERP or runs unattended on a schedule. That belongs behind the IT change-management gate with full ITGC coverage, no exceptions, because at that point it is an application.
Two supporting mechanics make the tiers real. Keep an inventory. If you cannot produce a list of every AI-generated script running in the close, you cannot scope your own controls, and neither can your auditor. And define a promotion path, so that a tier-one tool that quietly becomes load-bearing gets reclassified rather than drifting into the close unnoticed.
What the audit committee should see before year end
Bring this to the committee before the auditor brings it to you. Three artifacts are enough for a first conversation: the inventory of finance-authored code currently in use, the tiering policy with named review owners, and a statement of which items management has concluded are in scope for ICFR testing this year.
Also raise it with the external audit team early rather than at the interim. PCAOB and AICPA guidance on IT general controls and end-user computing already frames the questions, and Big Four audit-quality alerts have been sharpening on automated controls. An auditor who first encounters your reconciliation script during fieldwork will scope it conservatively. One who helped set the classification in September will not.
There is a workforce dimension worth naming as well. CFO Dive reported in May that AI remains the most cited driver of technology workforce cuts. A finance function that absorbs development work is also absorbing development risk, and it does so with fewer engineers nearby to catch the mistakes. The control framework is what stands in for the people who used to be in the room.
Key takeaways
- OpenAI's finance organization is building its own close and reporting utilities with AI coding assistants, per CFO Dive reporting this week.
- The shift is partly a budget response: MarketScale reported CFOs tightening AI budgets under sharper capex scrutiny, while EY research shows readiness lagging ROI pressure.
- Three questions lack owners today: who reviews finance-authored code, whether it is in SOX scope, and whether auditors treat it as end-user computing or as an application needing ITGCs.
- A tiered policy works better than a ban: analytical tools stay finance-owned, anything touching a journal entry needs documented review, anything writing to the ERP goes through IT change management.
- Take the inventory, tiering policy and scoping conclusions to the audit committee and the external auditor before year-end fieldwork, not during it.
