Finance Needs an Operating Model for Work Performed by Machines

Introduction

Microsoft’s Dynamics 365 ERP MCP server can give an agent access to finance and operations business logic and let it perform data operations that previously required a user working through the application interface. Microsoft describes the server as supporting agents that can perform nearly any function available to a user, subject to the tools, security context and instructions exposed to the agent.

The department now has to accommodate work performed by software that can retrieve live ERP data, invoke business logic, complete routine activities and continue through several steps without a person operating every screen. Oracle’s current Fusion ERP AI catalogue spans agents for ledger activity, expenses, payables, payments, cash processing and other financial work. SAP describes a comparable direction in its 2026 AI-Native North Star Architecture: people set direction, assistants coordinate and specialist agents execute within governed boundaries, with exceptions returning to people.

A supervised autonomous finance operating model therefore needs more than a policy saying that people remain accountable. Finance has to decide what constitutes machine-performed work, how that work is assigned, which decisions interrupt autonomous execution, what evidence the machine must leave behind, how unresolved cases return to people and who owns changes to the software performing the work.

These are operating-model questions because the machine is no longer confined to producing an answer for an employee. In some processes, it is becoming one of the entities doing the work.

At a glance

• Finance automation increasingly includes software that can act against live business systems, not only prepare information for a person.
• Machine-performed work needs an explicit scope, completion condition, evidence requirement and human owner.
• Supervision is most useful when attached to material decisions and unresolved conditions rather than every routine step.
• Finance roles expand to include oversight of machine execution, exception resolution and changes to the controls governing that execution.
• Internal control has to cover the machine’s configuration and behaviour as well as the transaction it produces.

Finance automation is beginning to look like work allocation

For years, the boundary around finance automation was relatively easy to describe.

A workflow routed an approval. RPA copied data between applications. A forecasting model produced an estimate. A document system extracted fields from an invoice. Employees remained visibly responsible for connecting most of those outputs into the wider process.

Agent-enabled ERP systems change the shape of that boundary.

Microsoft now exposes finance and operations business logic as actions that agents can invoke. Its Finance Agent connects productivity tools with financial systems and supports reconciliation work in Excel and collections work in Outlook, although Microsoft still documents parts of those experiences as prerelease or preview capabilities. Oracle’s financials portfolio includes agents that monitor ledgers, process cash, handle expenses and work across portions of payables and payments. SAP’s 2026 architecture describes agents executing work across enterprise applications under human direction and governed process context.

A task performed by a machine still has inputs, dependencies, an expected outcome and a point at which somebody else relies on the result. When several such tasks run in sequence, finance has effectively assigned a block of operational work to software, making the design of that assignment part of how the function operates.

A machine task needs a job definition

“Let the agent handle it” is not an operating specification.

A machine-performed finance task needs a defined business purpose and enough surrounding structure for another worker—human or machine—to understand what completion means.

For a recurring activity, finance should be able to identify the source information the machine is expected to use, the business system it may act upon, the result it is expected to create, the conditions under which it stops and the evidence retained when it finishes.

Oracle’s 2026 financial-agent designs increasingly expose those boundaries in product configuration rather than leaving them entirely inside prompts. The 26D policy-and-approvals capability for its Budget Adjustment Assistant, currently available through a controlled release, can validate proposed transfers against configured policies, route valid adjustments through approval and allow review of the posted budget entry after processing. The software can perform substantial work while policy validation, approval and the resulting financial record remain part of the surrounding process.

The same operating logic applies beyond budget adjustments. A machine worker does not need an employee job description, but it does need an operational contract clear enough to determine whether it performed the work it was given.

Supervision should follow the financial consequence

Human supervision does not require a person to watch every automated step.

Doing so would reproduce manual work around software that was introduced to remove it.

The more useful design attaches human involvement to decisions whose financial consequence, uncertainty or policy significance warrants intervention.

SAP’s 2026 expense automation is a simple example. Its Expense Automation Agent can prepare and populate an expense report, while the employee still reviews, refines and submits it. The machine performs much of the construction work; the person enters where confirmation of the resulting business record remains appropriate.

Elsewhere, a low-risk reconciliation can run to completion unless evidence conflicts. A proposed budget movement can require formal approval before funds are changed. A monitoring agent may operate continuously and involve an accountant only when a journal, balance or transaction meets a configured exception condition.

Oracle’s Ledger Agent uses that latter pattern: it can monitor balances, journals and transactions and surface information to accountants when intervention is required rather than making continuous manual monitoring the operating model.

Supervision becomes part of process design. Finance has to decide where a person materially improves control, rather than treating “human in the loop” as a universal step inserted after every machine action.

The human role changes even when accountability does not

Moving routine execution to software does not remove human work from the operating model. It changes its composition.

Someone still defines policy. Someone decides whether the machine’s scope remains appropriate. People investigate cases that cannot complete normally, evaluate new patterns of failure, change business rules and determine whether the automated behaviour still produces acceptable financial outcomes.

The work becomes less visible when organizations continue describing teams entirely through the tasks employees used to perform.

An accountant who previously reviewed 500 routine items may eventually review only 30 unresolved ones. The role has not simply lost 470 transactions. It now contains a larger share of judgment about why the remaining cases differ, whether the system behaved correctly and whether the operating rule itself needs to change.

The finance operating model cannot therefore be designed simply by subtracting automated tasks from existing job descriptions: machine execution creates supervisory, exception and change-management work around it.

Exceptions become part of the staffing model

The arrival of supervised machine work also changes where human capacity is required.

If routine cases increasingly complete without intervention, employee workload becomes more concentrated around cases with missing evidence, policy ambiguity, unexpected system conditions and genuinely unusual transactions. Total manual volume may fall while the residual work requires more contextual expertise.

Oracle’s 26D Payables Agent illustrates the shape of the problem without requiring finance to treat every exception alike. Its configuration supports matching policies, anomaly controls and automated resolution paths for supported exception patterns. Oracle also advises routing unsupported exceptions to a designated queue or specialist rather than allowing them to remain unresolved in interface tables.

A finance team adopting more machine execution consequently needs enough expertise at the receiving end of those exceptions. The residual human workload may be smaller in volume while becoming more concentrated in cases that require context, authority or accounting judgment.

The operating model has to account for whether the function has enough capacity and expertise to receive the work that autonomous execution cannot complete.

Internal control now extends to the machinery doing the work

A financial control has traditionally been discussed in relation to transactions, systems and people.

Machine workers add another layer because their behaviour can depend on instructions, models, tools, source context and configuration that can change independently of the underlying accounting policy.

COSO’s 2026 guidance on effective internal control over generative AI explicitly identifies risks such as prompt-based manipulation, opaque reasoning, model drift and frequent configuration changes. It also notes that organizations are already applying these systems to reconciliation, analysis and decision support at a scale that can affect operations, reporting and compliance.

A correct approval rule does not provide much assurance if the machine can bypass the intended process, use the wrong source information or change behaviour after a configuration update without detection.

The operating model therefore needs ownership for the machine’s surrounding controls: who maintains its operating instructions, who validates significant changes, who watches performance and who determines whether a new capability is permitted to enter production. That is supervision of the system performing the work rather than a requirement that a person make every transaction decision.

Evidence has to survive machine execution

Finance cannot rely on the fact that a task completed.

The organization may later need to establish which information the machine used, which action it took, which policy or control applied, where a person intervened and what ultimately entered the financial system.

Current products are beginning to expose that expectation directly. Oracle’s Budget Adjustment Assistant routes transactions through configured approvals and describes the resulting approval path as creating a clear audit trail before funds are updated. Its Payables Agent exposes workflow, validation, coding and funds statuses while retaining explicit configuration around controls and exception handling.

The IIA’s Artificial Intelligence Auditing Framework similarly treats AI as something management has to govern, execute and monitor, with internal audit eventually assessing whether the resulting processes and controls operate effectively.

The finance operating model consequently needs a durable process record around machine work.

That record is not there merely because an auditor may ask for it. It allows finance itself to distinguish a correct financial outcome from one that happened to look correct after an opaque sequence of machine actions.

Machine work needs its own change-management discipline

An employee’s responsibilities rarely change because somebody updated an underlying language model overnight.

A machine worker can.

Its source data can change. A new tool can become available. Instructions can be revised. A model version can behave differently. A tolerance may be widened. The business application may expose another action.

Some of those changes look technical while altering what the machine can do inside a financial process.

COSO’s GenAI guidance draws attention to frequent configuration change and model drift for precisely this reason. Microsoft likewise treats agent purpose, instructions and available ERP tools as explicit parts of agent configuration, while SAP’s emerging architecture places runtime governance around agents that execute enterprise work.

Finance therefore needs a change boundary around machine-performed work: a new capability should not silently expand operational responsibility because it became technically available. The process owner needs to know what changed, what financial work is affected and whether existing controls still describe the resulting behaviour.

That change boundary belongs inside the operating model because the scope of machine work can shift through technical updates that would never appear on an organization chart.

The organization chart will not show all the workers

Most finance organization charts will continue to show controllers, accountants, analysts, operations teams and finance leaders; they will not list a reconciliation agent, expense agent or automated monitoring process as an employee reporting to a manager.

The work performed by those systems nevertheless has to be described and governed.

As software takes responsibility for larger portions of execution, finance needs another way to describe the function: which outcomes are owned by people, which activities are performed by machines, where supervision enters and which process record connects the two.

Accounting for that work does not require pretending software is an employee. Operating models describe how work gets done, and once part of that work is performed autonomously, the model has to account for it.

FAQs: supervised autonomous finance operating model

What is a supervised autonomous finance operating model?

It is an operating model in which software can perform defined finance work with a degree of autonomous execution while people retain responsibility for process ownership, material intervention, control, exceptions and changes to the system performing the work.

The emphasis is on designing the relationship between machine execution and human responsibility rather than removing people from the finance process.

Does autonomous finance mean finance processes run without people?

Not generally.

Different processes can support different degrees of unattended execution. Routine work may complete automatically, while policy decisions, ambiguous cases, material approvals, configuration changes or unusual transactions still involve people.

The operating model defines those boundaries explicitly.

What work should finance assign to AI agents?

The decision depends on the process, source data, available business logic, consequence of error, degree of uncertainty and the controls surrounding the activity.

A stronger test is whether finance can define the task’s permitted scope, expected outcome, intervention conditions and evidence requirements clearly enough to operate it responsibly.

How is supervised autonomous finance different from traditional RPA?

Traditional RPA generally executes predefined steps. Agent-enabled systems can have more discretion over how they obtain information, select tools or progress toward an assigned objective.

That greater runtime flexibility changes what finance has to specify around the work: operating boundaries, monitoring, intervention and evidence become more important even when the underlying business policy remains unchanged.

Who is accountable when a finance agent performs the work?

Software does not remove organizational accountability.

A finance process still needs named human ownership for its policy, controls and business outcome. Exactly how transaction authority is delegated is a separate control-design problem, but autonomous execution should never make ownership of the underlying financial process ambiguous.

Finance has to manage the work, not merely deploy the technology

The practical shift in autonomous finance is visible in ordinary enterprise systems already being used to run finance.

Agents can access ERP business logic, monitor transactions, prepare records, complete routine activities and pass selected conditions back to people. The technology is progressively taking responsibility for pieces of work rather than only helping employees perform them.

Managing that work requires finance to define the task and completion state for machine execution, place human intervention at material decisions and unresolved conditions, provide a receiving path for exceptions, retain evidence of the resulting actions and assign ownership for changes to instructions and capabilities. These choices belong in the operating model because they determine how the function continues to operate when execution is no longer entirely human.

Without them, a finance function may have increasingly capable automation while still managing the work as though every meaningful action were performed by a person sitting in front of the application.