An agent that identifies an invoice discrepancy is helping the finance team. Once it changes a purchase order, accepts the discrepancy or initiates a payment, it is exercising delegated authority.
The distinction is an operating-model decision, not a technical detail.
For leaders planning ERP finance transformation, the practical question is what influence or execution authority the organisation is prepared to grant an agent, and under which conditions.
Permission to act should follow an agreed operating model. It should never be inferred from the software permissions available during implementation.
What agentic ERP actually changes
Here, agentic ERP refers to AI agents that interpret business context, select permitted tools and coordinate actions within or around enterprise resource planning systems.
Automation alone does not make a workflow agentic, and using an agent does not remove the need for human approval.
The most useful distinction is between assistance and authority. A system may summarise a reconciliation exception, propose an action, prepare a draft or execute an approved transaction. Each step places different demands on ownership, evidence and control.
Adding an agent does not, by itself, justify replacing the ERP. The answer may be a bounded capability within the existing platform, an orchestration layer across systems or a conventional rules-based workflow.
Start with the business problem and the decisions involved. Select the technology after understanding what the organisation needs it to do.
What the current announcements tell us, and what they do not
Microsoft’s 23 September 2026 Dynamics 365 update sets out an agentic ERP direction across finance and operational processes, including reconciliation, accounts payable and connected workflows. The same update covers capabilities available now, previews and roadmap items extending through March 2027. [1]
The Account Reconciliation Agent documentation is more specific. It describes an experience that evaluates exceptions and recommends actions for users to accept or replace. The page is labelled as production-ready preview documentation. It does not establish that every finance decision can be delegated autonomously. [2]
UiPath’s March 2026 announcement with Deloitte describes a related model: agents, automation and people coordinated across ERP processes. [3]
Taken together, these sources show the direction of travel. They are not a universal implementation specification.
Before committing to a use case, verify the particular product, version, licensing, region, deployment status and approval behaviour. A roadmap presentation is not acceptance evidence for the environment you intend to run.
Design decision rights before granting access
Decision rights set out who may decide, the limits of that authority and who remains accountable for the result. In agentic finance, that is the place to begin, rather than with a list of attractive features.
Who may approve a supplier change? Who may accept an invoice variance? Who may post a journal, release a credit hold or authorise payment? Which conditions require escalation, and who can resolve it?
The business owner and the system operator are not interchangeable. A technical administrator may configure an agent without holding authority to approve the financial decisions it supports.
An agent can perform work, but “the AI decided” is not an adequate ownership model. Name the person or role accountable for each business decision, the control owner and the operational owner responsible for monitoring the service.
Where current decision rights are already effective, preserve them. Redesign the gaps created by the proposed capability rather than launching an unnecessary organisation-wide restructuring.
Procure-to-pay: an invoice exception is not just an accounts payable task
Take a common invoice exception. This example is illustrative, not a PearsonGoldman client case.
An invoice exceeds the purchase order value. An agent retrieves the order, receipt and supplier correspondence, then recommends how to resolve the mismatch.
The decision may sit outside accounts payable. The buyer may need to confirm a price change, the receiving team may need to confirm what arrived, and the budget holder may need to approve additional expenditure. A faster recommendation does not remove those responsibilities.
The procurement operating model should establish which evidence resolves the exception, who owns missing information and which changes require fresh approval. An agent should not create a receipt merely to make an invoice match, or increase an order simply because that would clear the queue.
Supplier bank-detail changes need their own verification and approval path. Payment approval should not silently inherit approval from an unrelated onboarding or invoice-processing step.
The goal is a coherent procure-to-pay process. Individually efficient agents should not pass unresolved accountability between teams.
Record-to-report and order-to-cash need different boundaries
In record-to-report, an agent might investigate why balances do not agree and prepare a proposed adjustment.
Making two numbers match is not the same as establishing the correct accounting treatment. The finance owner still needs evidence about the underlying event, the appropriate period and the treatment of the difference.
Design the workflow so the recommendation remains connected to its source records, review and eventual posting. Reconciliation evidence should explain the outcome, not merely record that an exception disappeared.
Order-to-cash raises different questions. An agent may summarise a dispute or draft a collection message, but authority to send correspondence, amend credit terms, issue a credit note or release a customer hold should be considered separately.
The operating model must reflect the process. There is no single “finance agent approval” that safely substitutes for those distinctions.
Put controls in systems, not only in prompts
OWASP identifies excessive agency as a risk arising from excessive functionality, permissions or autonomy. Its guidance recommends constraining tool access and enforcing authorisation in downstream systems rather than relying on the language model to decide what is allowed. [4]
The practical implication is that a prompt saying “follow finance policy” is not the control boundary.
For each use case, specify permitted records, actions, legal entities and approval conditions. Enforce those restrictions through the relevant identity, application and integration controls.
Keep segregation of duties meaningful. Two agents using the same privileged account do not create independent approval simply because their names differ.
Preserve the authoritative business records. An agent’s summary should not become a competing ledger, supplier master or approval register.
The operating model should make clear where each fact is maintained, how conflicting information is resolved and which system records the completed transaction.
Bind approval to the action actually executed
An approval should identify what is being authorised. General agreement with an agent’s plan is not enough.
OWASP’s agent-security guidance recommends binding approval to the specific action and parameters, protecting against replay and independently validating authority before execution. [6]
For finance, the approved transaction should remain recognisable when it reaches the execution step. A change to the amount, recipient or target record should trigger the appropriate revalidation rather than reuse an unrelated approval.
Test failure paths as well as successful processing. What happens when the ERP accepts an action but the connector times out? A blind retry must not create a duplicate commitment.
The recovery process also needs to reflect business reality. Some actions can be cancelled before execution; others require a controlled reversal or correction. Do not describe every posted transaction or external payment as instantly reversible.
Keep evidence that supports a business review
The review record should connect the original business request, relevant source records, proposed action, applied policy, approval and final execution result.
Retain the agent or service identity, timestamps and material version information. Record exceptions and the decisions that resolved them.
The record exists to reconstruct what happened and assess whether it was authorised. A generated explanation is not proof that the decision was correct.
Protect the evidence itself. Avoid copying unnecessary confidential information or credentials into logs, and establish appropriate access and retention arrangements.
For operational management, report outcomes alongside activity. Leaders need to see cases completed correctly, cases awaiting decisions, repeated failure patterns and the consequences of errors, as well as the number of agent runs.
Redesign the human work as well
Human oversight works only when the reviewer has the information, authority and capacity to make a meaningful decision.
A queue containing thousands of unexplained “approve” buttons is not a satisfactory target operating model.
Define what reviewers should examine, the circumstances requiring specialist input and the route for challenging a recommendation. Make clear what happens when the responsible person is unavailable.
Assign responsibility for maintaining the process rules, monitoring the service and approving changes to agent behaviour. Establish who can suspend the capability and how operations continue during an interruption.
This is change management as well as control design. Teams need to understand their revised responsibilities and how success will be measured.
NIST’s voluntary AI Risk Management Framework provides a useful organising reference through its Govern, Map, Measure and Manage functions. It is a risk-management resource, not a finance-specific approval standard or a substitute for local accountability. [5]
Build a business case around correctly completed work
A high automation rate can hide the effort spent on review, rework and support. Judge the business case by the cost of correctly completed outcomes.
For a proposed invoice-exception use case, establish the baseline handling effort, waiting time, rework and error profile. Compare that baseline with the proposed process, including the work that remains with people.
Include licensing, model or API consumption, integration, monitoring, security assurance, operational support and ongoing change costs. Set limits on consumption and repeated processing rather than assuming every run will be cheap.
Released capacity is not the same as a cash saving. Time made available has value, but it does not automatically reduce expenditure. State how that capacity will be used and who owns the resulting benefit.
A useful scorecard balances speed, quality, control and cost. It might track time to resolution, correct-first-time completion, reviewer effort, duplicate transactions, control exceptions and total cost per completed case.
Do not optimise one metric in isolation. Clearing exceptions faster is not progress if the organisation subsequently has to investigate and reverse more decisions.
Move from discovery to controlled delivery
A responsible pilot does not require an enterprise-wide redesign. It does require the decisions and dependencies for that use case to be resolved.
1. Select a bounded business problem
Choose a process with a clear owner, accessible evidence and a measurable problem. Compare agentic execution with simpler alternatives.
The output should identify the proposed outcome, baseline, scope and reasons for using an agent.
2. Define the operating conditions
Agree the authority matrix, source systems, approval boundaries, exception ownership, service responsibilities and funding.
Translate those decisions into an implementation backlog with named owners, dependencies and acceptance criteria. A target-state diagram alone is not an executable plan.
3. Prove behaviour before extending authority
Begin with historical, synthetic or appropriately authorised test data. Where appropriate, use shadow operation: the agent produces recommendations without making live transactional changes.
Test ambiguous records, missing evidence, rejected approvals, duplicate requests, integration failures and attempts to exceed the permitted scope.
The release decision should rest on observed behaviour against agreed criteria, including failure handling. A persuasive demonstration is not enough.
4. Introduce a limited live service
Start with a controlled population, explicit transaction boundaries and sufficient human support.
Confirm that monitoring, escalation and suspension arrangements work in practice. Record what the pilot establishes and what remains unproven.
5. Scale only when the evidence supports it
Compare results with the baseline and inspect whether benefits survive the full cost of review and operation.
Treat additional permissions, transaction types, entities or integrations as changes requiring assessment. A successful narrow pilot does not automatically validate broader authority.
Preserve proportionate change control as models, prompts, tools and business rules evolve.
What leaders should require before approving deployment
The investment decision should be supported by a connected set of artefacts: a process and decision map, an authority matrix, data and integration ownership, an implementation plan, test evidence, operational responsibilities and a benefits baseline.
Together, they should present one coherent case for deployment.
A proposed benefit should connect to a process change. That change should connect to an accountable owner, a permitted action, an enforceable control and evidence that the design works.
Where that chain breaks, resolve the gap before asking the technology to carry it.
PearsonGoldman’s approach connects finance transformation, ERP delivery, procurement and operating-model design. The aim is to keep business outcomes and accountable decisions in control of the technology programme.
Agentic ERP can change how work is performed. Finance transformation determines whether that change creates value the organisation can trust.
Sources
- Microsoft, published 23 September 2026.Build the future of agentic ERP with new Microsoft Dynamics 365 capabilities
- Microsoft Learn.Account Reconciliation Agent (production ready preview)
- UiPath, published 12 March 2026.UiPath Expands Strategic Alliance with Deloitte to Launch Agentic ERP
- OWASP GenAI Security Project.LLM06:2025 Excessive Agency
- NIST AI Resource Center.AI Risk Management Framework
- OWASP Cheat Sheet Series.AI Agent Security Cheat Sheet