Last updated: 13 August 2026
Subtitle: Six shifts that separate teams experimenting with AI from teams that have genuinely redesigned finance around it.
Finance has always been a retrieval problem disguised as a numbers problem.
Ask any controller what actually consumes the month-end close, and the answer is rarely arithmetic. It is hunting for the invoice behind a variance. It is reconciling a general ledger extract against a purchase order log that lives in a different system. It is chasing a business head over WhatsApp to explain why a cost centre overshot by ₹18 lakh. The calculation takes seconds. Assembling the inputs takes eleven days.
This is why AI is landing harder in finance than in almost any other corporate function. The work that language models are good at — locating, summarising, explaining, drafting, cross-checking — maps almost perfectly onto the work that consumes finance teams but appears nowhere in a job description.
OpenAI's CFO, Sarah Friar, published a widely-read reflection in August 2026 on building an AI-native finance function from scratch, setting out two ambitions her team is working toward: a zero-day close and continuously updated forecasting. It is worth reading in full. What follows is not a summary of it. It is an attempt to answer the question it leaves open for the rest of us — what does this look like inside a finance function that already has twenty years of systems, statutory obligations, and a legacy chart of accounts?
Here are six shifts that appear to matter most.
Shift 1: Distribution before sophistication
The instinct in most organisations is to run a controlled pilot. Pick one team, one use case, prove ROI, then scale.
In practice this fails for a specific reason: nobody knows in advance which finance workflows AI is good at. Not the CFO, not the CIO, and certainly not the vendor. The knowledge sits with the assistant manager who has run the GST input-credit reconciliation for four years and can tell you exactly which three steps are mechanical and which one requires judgement.
So the sequence inverts. Give the whole function secure access first, then manufacture a reason to use it.
The manufactured reason matters. Access alone produces a spike of curiosity followed by a plateau of email drafting. What breaks the plateau is a structured event with a real deliverable — a two-day internal build sprint where every person brings one recurring task they resent, paired with someone technical who can unblock them. The output is not a slide deck. It is three working tools and a much sharper organisational sense of where the leverage is.
The pattern to aim for is bottom-up discovery meeting top-down prioritisation. Front-line teams surface what is possible; leadership decides which of those possibilities gets pointed at the decisions that actually move the business.
Shift 2: Work backwards from a decision, not forwards from a task
Most AI deployment in finance stops at task automation. Faster commentary. Auto-drafted variance notes. A chatbot over the policy manual. Useful, marginal, and easy to sunset when budgets tighten.
The larger move is to pick one consequential recurring decision and redesign the entire path to it.
Take the quarterly capital allocation review. Map every step honestly: data pulls from the ERP and the CRM, three spreadsheets that reconcile to each other by convention rather than by design, a variance narrative assembled from email threads, a deck built the night before, and a two-hour meeting where 90 minutes go to establishing what happened and 30 minutes to deciding what to do next.
Now ask which of those steps AI can complete, which it can draft for review, and which must remain human. The answer is usually that the first 80% of the path is assembly work and the last 20% is judgement. Today the ratio of team effort is inverted.
The prize is not a faster deck. It is flipping the meeting so that establishing reality takes 15 minutes and deciding takes an hour and forty-five.
Shift 3: The analyst becomes a builder
This is the shift most finance leaders underestimate, and it is the one with the longest tail.
Coding agents have removed the gatekeeper between "I know exactly what tool I need" and "the tool exists." A finance manager who has never written a line of Python can now describe a weekly phasing model — one that respects working days, festival calendars, and quarter-end skew — and iterate it into something that runs. OpenAI's own research, cited in Friar's piece, found that a meaningful share of finance professionals' specialised AI use now involves work outside traditional finance, including a substantial portion that is engineering-adjacent.
The consequence is that finance's default artefacts change. Static spreadsheets and static decks give way to live views that sit on top of the actual data and can answer the follow-up question. A deck answers what you anticipated. A tool answers what you get asked.
There is a second-order effect worth naming: people who build their own tools stop accepting the existing process as given. Someone who has to specify a reconciliation in order to automate it will notice that two of the seven steps existed only because of a system limitation resolved in 2019.
This does not deskill the function. Domain expertise becomes more valuable, not less, because it is now the scarce input — the model can build almost anything, but only the practitioner knows what should be built.
Shift 4: Build the control plane at the same time as the capability
Finance is the one function where "mostly right, quickly" is not a virtue. A forecast that is directionally correct is useful. A statutory disclosure that is directionally correct is a problem.
This is not an argument for slowing down. It is an argument for making accountability explicit at design time rather than discovering it during an audit. Practically, that means deciding upfront:
- Grounding. Which sources is the system allowed to use? An AI answering investor diligence questions should draw only on approved, filed, current material — not on whatever it can find.
- Traceability. Every number needs a path back to a source record, and every variance explanation needs to name the transaction behind it. Unverifiable output is not an efficiency gain; it is a deferred liability.
- Authority. Which actions can the system take, which require a maker-checker approval, and which must escalate? Changing an approved baseline forecast should always require human authorisation.
- Ownership. AI accelerates the draft. A named person owns the output. This does not become negotiable because the draft was good.
For regulated Indian entities there is an additional layer: whatever gets built has to survive statutory audit, internal audit, and — depending on the business — RBI or SEBI inspection. The reassuring part is that this discipline is not new. Finance already knows how to run maker-checker workflows, access matrices, and audit trails. The task is applying an existing muscle to a new class of system, not inventing a governance philosophy from nothing.
The same applies to cost. Token spend, seat licences, and model routing are now straightforward to bound with usage limits, role-based access, and approval thresholds. Treat AI as a variable expense with a budget owner, and the anxiety about runaway spend largely resolves itself.
Shift 5: Measure value per unit of intelligence, not adoption
Most AI dashboards in large companies measure the wrong thing. Seats provisioned, weekly active users, queries per employee, tokens consumed. None of these tell a CFO whether anything got better.
A more honest scorecard asks four questions of each workflow:
- Did the system complete work that actually mattered to the business?
- What was the fully-loaded cost — inference, licences, plus human review and rework?
- Was the output good enough to use without rebuilding it?
- Did it compress a cycle or improve a decision?
Then attach that to operating metrics the function already reports. For the close: cycle time in days, share of transactions auto-reconciled, exception volume requiring manual review, time to explain a material variance. For planning: forecast accuracy against actuals, refresh frequency, time to produce a new scenario.
One counterintuitive finding shows up repeatedly. The cheapest model is often not the most economical. A stronger model that reaches a reliable answer in one pass, with light review, frequently costs less in total than a cheap model that needs three attempts and an hour of an analyst's time to verify. Per-token pricing is a misleading unit; cost per accepted output is the real one.
Shift 6: Aim at a continuous close, but resource the plumbing
Both of the ambitions worth borrowing — a near-zero-day close and always-on forecasting — depend on something unglamorous: connected, reconciled, lineage-aware data.
If actuals, commitments, accruals, and approved plans do not live in a state where they can be joined and traced, no amount of model capability produces a trustworthy real-time view. It produces a fast, confident, wrong one. The uncomfortable truth for most enterprise finance functions is that the first six months of an AI-native programme look like data engineering, not AI.
That reframes the roadmap honestly:
- Quarter 1: Broad secure access, one build sprint, an inventory of the top ten recurring workflows by hours consumed. Instrument your current baseline — close cycle time, forecast error, exception counts — because you cannot demonstrate improvement against a number you never recorded.
- Quarter 2: Pick one decision. Wire its data path end-to-end, including lineage. Ship one live tool that replaces a recurring deck.
- Quarter 3 onward: Extend the reconciled foundation, add scenario capability on top, and formalise the control plane so internal audit can sign off on what has been built.
The close does not vanish. What vanishes is the scramble to reconstruct the business after the period has already ended.
Why this lands on the CFO
Finance is one of the few functions with a legitimate line of sight into strategy, capital, data, risk, and performance simultaneously. That vantage point is exactly what an AI transformation requires, and it is why the CFO is often better placed than anyone to lead it — not merely to fund it.
There is also a demonstration effect. A finance function that has genuinely rebuilt its own workflows becomes the internal proof that this is possible, and the template every other function copies. A finance function that only writes the cheque becomes the reason the rest of the organisation stays sceptical.
The destination is not a faster close. It is a team that understands the business as it changes, shows leadership the choices ahead while they can still be influenced, and spends its time on judgement rather than assembly.
Reference and inspiration: Sarah Friar, "What building an AI-native finance function taught me," OpenAI, 10 August 2026 — https://openai.com/index/building-an-ai-native-finance-function/. The observations, framework, examples, and India-specific context in this article are the author's own.
