AI Finance Operating Model: How Roles and Skills Change

Most finance teams that deploy AI agents spend months on the technology and very little time on the people who will work beside it. An AI finance operating model answers a different question: once agents handle matching, reconciling, chasing and first drafts, who does what, who decides, and what does a controller or analyst actually spend the day on? This article sets out how roles shift across transactional finance, controllership and FP&A, which skills matter next, and how to redesign the team without losing control or institutional knowledge. It is written for finance leaders with a pilot running, or about to start, who want the organisation design to keep pace.

1. What Does an AI Finance Operating Model Change?

The obvious change is volume. Agents read invoices, match remittances, prepare reconciliations and draft commentary, so the hours spent on assembly fall away. The less obvious change is where decisions sit. In a traditional model, a decision is embedded in someone's routine: the AP clerk who knows a supplier always bills freight separately, the accountant who knows which accrual gets reversed. When an agent does the routine, that judgement has to be written down as a rule, a threshold or an escalation path, or it disappears. An AI finance operating model is therefore mostly about making implicit decisions explicit and giving each one a named owner.

Take a distribution group with entities in Dubai and Riyadh. Before agents, each entity has its own AP team, its own close checklist and its own workarounds. After agents, the same invoice-matching logic runs across both, and the differences between entities surface as exceptions rather than habits. That is useful, but it also means somebody must decide which local practice is legitimate and which is simply how it has always been done. Teams that skip this step end up with agents that faithfully reproduce old inconsistencies at higher speed.

2. Finance Roles After AI Agents: Transactional Teams

Accounts payable, receivables and general ledger teams feel the change first. When agents process the bulk of clean invoices and remittances, the remaining work is the exceptions: the price variance outside tolerance, the remittance that pays three invoices short, the goods receipt posted to the wrong cost centre. Each of these needs context, a phone call or a judgement about commercial intent. The role moves from processing to resolving, and the people who do it well can explain why a transaction failed, which is a different skill from keying it in.

This is where many programmes make their first mistake. They reduce headcount in the transactional team before the exception queue has stabilised, then discover that the hardest cases now sit with the fewest people. A better approach is to keep experienced staff through the first few close cycles, use them to tune the escalation thresholds, and only then decide on structure. The people who used to process the volume are usually the best source of the rules an agent needs, and they leave with that knowledge if the change is handled badly.

Agent supervision also becomes part of the job. Someone checks the agent's work queue each morning, reviews items it parked, samples items it cleared, and notes patterns: a supplier whose invoices keep failing on tax codes, a customer whose remittance format changed. That person is effectively a shift lead for a digital team. With AITHENTIC's finance AI agents, each agent has a defined role, decision rights, escalation logic and a full audit trail, which makes this supervision practical because the reviewer can see what the agent did and why.

3. The Controller Role: From Preparer to Rule Owner

For controllers, the shift is from preparing the numbers to owning the rules that produce them. In a close run largely by agents, reconciliations, accruals and intercompany matches arrive prepared, with supporting evidence attached. The controller's time goes into three things: setting and reviewing the materiality and tolerance rules the agents apply, approving the exceptions those rules escalate, and making sure the evidence trail will stand up to an external auditor. This is closer to the job controllers were always meant to do, before the close calendar consumed it.

The skills follow from that. Controllers need to read and challenge a rule set as comfortably as a trial balance, which means understanding how an agent reaches a match or a proposed journal, even without writing code. They need a working grasp of data lineage: where a figure came from, which system fed it, and what happened to it on the way. And they need precision about decision rights, because a vague approval policy that a person would interpret sensibly becomes a control gap when an agent applies it literally.

Speed changes the rhythm too. AITHENTIC's published work on an agentic month-end close, with the close cut from 5 days to 1 on Oracle AI Agent Studio, shows how compressed the timetable can become. A one-day close leaves no room to discover problems late. Review has to move earlier and become continuous: daily checks on reconciliation status, weekly review of rule changes, and a clear view of which open items will block sign-off. Controllers who keep working to a fixed end-of-month checklist end up approving faster without reviewing better.

4. FP&A Analyst Skills: From Building Numbers to Challenging Them

FP&A analysts often spend most of a cycle gathering actuals, rebuilding spreadsheets and writing similar variance explanations every month. Agents can now take the first pass: they pull actuals, refresh driver models and produce draft variance commentary for review. What remains is the part that needed a human all along. Is the explanation true? Is the driver still the right driver? What should the business do about it? An analyst who can answer those questions in a conversation with a commercial director is worth far more than one who can build a faster lookup.

The FP&A analyst skills that matter next are commercial and investigative. Analysts need to understand the operational drivers behind the numbers well enough to spot a plausible but wrong explanation from an agent. They need scenario thinking: framing the questions a model should answer before asking for outputs. They also need to communicate uncertainty plainly, because an agent-generated forecast that looks precise can mislead a board if nobody explains its assumptions. Advanced spreadsheet ability still has value, but it is no longer the main reason to hire someone into FP&A.

5. New Roles in an AI Finance Operating Model

A few roles appear that did not exist in most finance functions before. The agent owner is accountable for one agent or workflow: its rules, its performance, its exceptions and its change log. This is a finance role, usually filled by someone who ran the process manually. The finance data steward owns master data quality and the definitions agents rely on, such as what counts as a valid vendor record. A process designer decides how work flows between agents and people. None of these need to be new hires, but the accountability must be written into job descriptions and objectives, or the first audit query exposes the gap.

The boundary with IT needs to be drawn explicitly in an AI finance operating model. Agents run inside SAP, Oracle, Dynamics 365 or NetSuite, so platform teams own access, integration and uptime, while finance owns the logic and the outcome. A short responsibility matrix agreed early, covering who can change a rule, who can change an integration and who approves each, prevents most of the arguments later. Without it, a small tolerance change can sit in an IT change queue for weeks while the exception backlog grows.

6. How to Redesign Finance Team Structure Without Losing Control

Redesigning finance team structure works best in sequence: process first, then roles, then numbers. Map each process at the level of decisions rather than tasks, and mark which decisions an agent can make, which it can only propose, and which stay with people. Only then define the roles that own those decisions. Organisations that start with a target headcount and work backwards tend to remove the people who held the undocumented knowledge, and spend the following year rebuilding it at greater cost.

Finance reskilling should be practical and tied to live work. Classroom courses on AI concepts have limited value for an accountant whose real need is to review an agent's reconciliation and recognise a suspicious match. Pair people with the first deployments, have them write and test rules, and let them sit in on exception reviews with internal audit. Where outside help is useful, AI transformation consulting should cover operating model design and change management alongside the build itself, since the technology is rarely the part that stalls.

One judgement call deserves a direct answer: not every role needs to change at once, and some should barely change at all. Treasury dealing, tax technical work and complex revenue recognition judgements still depend on expertise that agents support rather than replace. Redesigning those teams early creates disruption with little return. Put the effort where agents are actually live and producing exceptions, and let the AI finance operating model expand as the agent estate grows, one workflow at a time.

Key challenges

• Judgement that lived in people's routines is lost if it is not captured as rules before staff move on.
• Headcount reductions made before exception volumes settle leave the hardest work with the fewest people.
• Agent ownership is left informal, so nobody is accountable when an agent makes a wrong decision.
• Approval policies written for people are too vague for agents that apply them literally.
• Reskilling relies on generic training instead of practice on live agent output.

The framework

A practical model runs in four stages: decide, design, assign, develop. Decide means mapping each finance process at the level of decisions and classifying every decision as agent-made, agent-proposed or human-only, with explicit thresholds. Design means defining escalation paths, evidence requirements and the boundary between finance and IT for each workflow. Assign means giving every agent a named finance owner, every master data domain a steward and every rule set an approver, with those duties written into job descriptions. Develop means building skills through live deployments, with staff reviewing agent output, tuning rules and joining exception reviews with internal audit, then repeating the cycle as each new agent goes live.

How to implement it

1. Map one live or planned agent workflow at decision level and record who decides what today.
2. Capture the undocumented rules held by experienced staff as written thresholds and escalation paths before changing any roles.
3. Appoint a named agent owner and data steward for the workflow and add that accountability to their objectives.
4. Agree a responsibility matrix with IT covering rule changes, integration changes and who approves each.
5. Run several close cycles with the existing team, tuning rules from the exception queue, before deciding on structure.
6. Build reskilling around reviewing real agent output and repeat the design for each new workflow.

Frequently asked questions