AI Agents Can Execute ERP Transactions. But Who Is Accountable When They Get It Wrong?

Why AI governance, human approval and transaction-level controls will determine the success of agentic ERP implementations

By OV Prakash | Dynamics 365, Enterprise Delivery & AI Transformation

1. The Next ERP Transformation Is About Decision-Making

For years, enterprise resource planning systems have focused on process automation, transaction processing and data integration.

Organizations implemented ERP platforms to standardize business processes such as:

• Procure to Pay (P2P)
• Order to Cash (O2C)
• Plan to Produce
• Inventory and Warehouse Management
• Record to Report (R2R)
• Project to Profit

Traditional ERP automation generally operates through predefined rules, workflows, scheduled jobs and integrations.

However, enterprise applications are now moving toward a different operating model.

AI agents can interpret business information, evaluate possible actions and interact with enterprise systems through controlled tools and APIs.

This creates an opportunity to move from reactive transaction processing toward proactive operational assistance.

But it also introduces a critical question:

When an AI agent recommends or executes a business transaction, who is accountable for the outcome?

The answer cannot simply be “the AI agent.”

Enterprise accountability must remain with clearly designated business owners, supported by technical controls, security, approval workflows and auditable execution.

2. A Practical Manufacturing and Procurement Scenario

Consider a manufacturing organization using Microsoft Dynamics 365 Supply Chain Management.

A supplier confirms that a critical component required for production will be delivered five days later than originally planned.

Traditional ERP process

Without agent-assisted analysis, the procurement planner may need to:

1. Identify the affected purchase order.
2. Review the supplier's revised delivery commitment.
3. Check available and incoming inventory.
4. Identify dependent production orders.
5. Evaluate the impact on planned manufacturing activities.
6. Review customer delivery commitments.
7. Coordinate with production planning and procurement managers.
8. Decide whether to accept the change, expedite an alternative supplier or revise the production schedule.
9. Update the relevant ERP transactions.
10. Communicate the decision to affected stakeholders.

This process may involve several teams, multiple reports and manual analysis.

Agent-assisted process

With an appropriately designed AI agent, the organization could support a more efficient workflow:

Step 1 — Detect the supplier change

The agent receives or retrieves the revised supplier delivery information through an authorized integration.

Step 2 — Identify the affected purchase order

The agent associates the change with the relevant purchase order, line item, quantity and expected delivery date.

Step 3 — Analyze downstream dependencies

The agent evaluates potential effects on inventory, production requirements, transfer orders and customer commitments using available ERP data and supported business capabilities.

Step 4 — Recommend alternatives

The agent presents possible responses, such as:

• Accepting the revised delivery date.
• Evaluating alternative inventory.
• Reviewing another supplier.
• Escalating the risk to production planning.
• Replanning affected operations.

Step 5 — Obtain business approval

A designated approver reviews the proposed action and its potential consequences.

Step 6 — Execute the approved transaction

Only after the required authorization does the integration perform the permitted ERP action.

Step 7 — Record the outcome

The system captures the decision, transaction result, relevant identifiers and exceptions.

This illustrates a possible enterprise solution architecture. It should not be interpreted as a claim that every step is delivered automatically by Microsoft's standard Procurement Agent.

The important distinction is:

AI analysis is not the same as authorized transaction execution.

3. Microsoft Dynamics 365 and the Emerging Agentic ERP Architecture

Microsoft's direction for Dynamics 365 Finance and Supply Chain Management includes agent-assisted business processes and expanded interoperability through the Dynamics 365 ERP Model Context Protocol (MCP) server.

The ERP MCP approach provides a standardized mechanism through which authorized AI agents can discover and interact with supported ERP resources and operations.

In an enterprise implementation, however, MCP connectivity is only one component of the architecture.

A complete solution also requires identity, authorization, business validation, approval orchestration, monitoring and exception handling.

Reference architecture

A practical architecture can be organized into six layers.

Layer 1 — User and interaction layer

Business users interact with an agent through a supported conversational or application interface, such as Microsoft Copilot Studio or another authorized agent host.

Layer 2 — Agent orchestration layer

The agent interprets the request, determines which information is needed and selects permitted tools.

Layer 3 — Enterprise integration layer

Supported connectors, APIs, MCP tools or Power Automate flows provide controlled access to business functions.

Layer 4 — Business authorization layer

Identity, application permissions, approval policies and segregation-of-duties controls determine what the agent may read, recommend or execute.

Layer 5 — Dynamics 365 transaction layer

Dynamics 365 Finance and Supply Chain Management performs the authorized business operation, applying the relevant application logic and validation.

Layer 6 — Audit and monitoring layer

Operational logs, approval records, transaction history and monitoring tools support traceability and incident investigation.

One of the most important architectural principles is that the agent must not become an uncontrolled shortcut around established ERP business processes.

Where possible, transactions should be performed through supported business interfaces that preserve application validation and security.

4. Five Essential Governance Controls for AI-Driven ERP Transactions

Control 1 — Identity and Role-Based Access

Every AI agent should operate under a clearly defined identity and permission model.

The design must answer:

• Which user or service identity is performing the action?
• What business data can the agent access?
• Which legal entities or business units are within scope?
• Can the agent create, update or approve transactions?
• Are permissions limited to the minimum necessary functions?
• Can actions be traced to the requesting user and executing identity?

For example, an agent supporting procurement analysis may require permission to read purchase orders, vendor information and relevant inventory data.

That does not automatically justify permission to approve purchases, modify vendor bank details or post financial transactions.

Implementation principle: Apply least privilege to agents just as rigorously as to human users.

Control 2 — Human Approval for High-Impact Transactions

Not every ERP action requires the same level of oversight.

Organizations should establish risk-based authorization policies.

These are proposed governance patterns, not universal Microsoft product defaults.

A useful design approach is to separate recommend, approve and execute into distinct stages.

The person approving a transaction should be able to see the exact proposed change and its material business implications.

Control 3 — Business Impact Validation

An AI-generated recommendation may appear reasonable while overlooking important dependencies.

Consider a proposed purchase-order delivery-date change.

Before execution, the organization may need to validate:

• Inventory availability and reservations.
• Production material requirements.
• Planned and released production orders.
• Customer delivery commitments.
• Warehouse and transportation dependencies.
• Alternative sourcing options.
• Financial or contractual consequences.

This is particularly important in manufacturing environments where a seemingly small procurement change can disrupt multiple downstream processes.

An agent should not equate technical permission with business suitability.

Control 4 — Auditability and Explainability

An enterprise must be able to reconstruct how an AI-supported decision was made.

For material actions, I recommend recording:

1. The originating request or event.
2. The requesting user or system.
3. The executing agent and version.
4. The tools or integrations invoked.
5. The relevant ERP transaction identifiers.
6. The proposed change and its original values.
7. The supporting business evidence.
8. The approval decision and approver identity.
9. The execution result.
10. Any error, exception or compensating action.

Sensitive data should be handled according to the organization's security, privacy and retention policies.

The objective is not to log every internal model detail. It is to preserve sufficient business evidence to explain and investigate consequential actions.

Control 5 — Exception Handling and Recovery

ERP transactions are not always reversible through a simple technical rollback.

A purchase order might already have been confirmed.

Inventory may have been reserved.

A warehouse operation may already be underway.

An invoice might have been posted.

Therefore, every agentic transaction design needs a recovery strategy.

At minimum, define:

• What happens when an approval expires?
• What happens if ERP data changes after the recommendation?
• What happens if the API request times out?
• How are duplicate requests prevented?
• What happens when only part of a multistep process succeeds?
• Who receives the exception?
• Which corrective transactions are supported?

For consequential changes, the solution should revalidate critical business conditions immediately before execution.

This helps prevent an agent from acting on a recommendation that was accurate when generated but has become outdated.

5. Step-by-Step Implementation Approach for Dynamics 365

Organizations introducing AI agents into Finance and Supply Chain Management should follow a controlled delivery lifecycle.

Phase 1 — Identify and Classify the Use Case

Start with one measurable business problem.

For example:

Use case: Analyze supplier delivery changes and recommend appropriate procurement responses.

Define:

• Trigger: Supplier communicates a revised delivery date.
• Inputs: Purchase-order data, inventory and relevant planning information.
• Outputs: Impact assessment and recommended action.
• Human decision: Procurement manager approves or rejects the proposed change.
• Execution: An authorized ERP operation updates the permitted transaction.
• Success measure: Reduced analysis time without increased transaction errors.

Avoid beginning with broad objectives such as “let the agent manage procurement.”

Phase 2 — Define Business Rules and Approval Thresholds

Conduct workshops with procurement, manufacturing, finance, security and enterprise architecture teams.

Document which actions are:

Read-only: Data retrieval, reporting and analysis.

Recommendation-only: Impact analysis, alternatives and draft changes.

Approval-required: Material changes to operational or financial commitments.

Restricted: Actions prohibited from autonomous execution.

Approval requirements should consider transaction value, operational impact, regulatory obligations and segregation of duties.

Phase 3 — Validate Dynamics 365 Technical Readiness

Review the following areas:

Application readiness

Confirm the Dynamics 365 application version, enabled capabilities and compatibility with the intended integration approach.

Environment readiness

Separate development, testing, UAT and production environments.

Identity and security

Validate the agent's authentication mechanism, application roles and data access boundaries.

Integration readiness

Identify supported MCP tools, connectors, APIs or custom services for each operation.

Business-process readiness

Confirm the existing approval workflows and transaction validations.

Monitoring readiness

Define how tool invocations, approval outcomes, execution failures and operational exceptions will be captured.

A successful agent demonstration in a development environment is not sufficient evidence of production readiness.

Phase 4 — Build a Controlled Proof of Concept

A practical proof of concept could follow this sequence:

1. A user requests analysis of a supplier delivery delay.
2. The agent retrieves the relevant purchase-order information.
3. The agent obtains available inventory and planning data through approved interfaces.
4. The agent summarizes the potential business impact.
5. The agent proposes an action without changing ERP data.
6. The user reviews the supporting information.
7. An approval workflow captures the decision.
8. An authorized service executes the approved change.
9. The service returns the ERP transaction result.
10. The agent presents the outcome and records any exception.

For an initial implementation, I recommend keeping the agent in read-only or recommendation-only mode until the organization has validated the accuracy and completeness of its analysis.

Phase 5 — Perform Technical and Business Testing

Testing should extend beyond whether the agent produces a plausible answer.

Recommended test scenarios include:

Testing must cover the actual configured tools and application permissions. A model's verbal promise not to perform an action is not an adequate security control.

Phase 6 — Introduce Production Controls

Before go-live, establish:

• Named business ownership for each agent use case.
• Approved operating procedures.
• Documented agent permissions.
• Change and release management.
• Monitoring and alerting.
• Incident escalation.
• A mechanism to disable agent execution.
• Defined support responsibilities.
• Periodic access and performance reviews.

Initially, organizations may choose to run agents in recommendation-only mode and compare their outputs with decisions made by experienced business users.

Controlled automation can be introduced gradually as the evidence supports it.

6. Measuring Whether Agentic ERP Delivers Business Value

Many AI initiatives focus on the number of agents deployed or conversations handled.

Those metrics do not necessarily demonstrate enterprise value.

A better approach is to measure business outcomes.

Operational efficiency

• Average time required to analyze supplier changes.
• Time between issue detection and decision.
• Number of manual handoffs.

Decision quality

• Percentage of recommendations accepted.
• Number of recommendations requiring correction.
• Frequency of material dependencies missed.

Transaction quality

• Unauthorized or failed execution attempts.
• Duplicate transaction incidents.
• Post-execution corrections.
• Approval policy violations.

Adoption and trust

• Active business-user adoption.
• User satisfaction with recommendations.
• Frequency of manual overrides.
• Time spent resolving exceptions.

Business impact

• Avoidable production disruptions.
• Supplier-related delivery delays.
• Procurement exception resolution time.
• Administrative effort saved.

The goal should be to improve business outcomes while maintaining or strengthening control—not simply to maximize automation.

7. Common Mistakes to Avoid

Based on enterprise implementation principles, several design mistakes deserve particular attention.

Mistake 1: Giving an agent broad ERP permissions

An agent should receive only the access necessary for its approved use case.

Mistake 2: Treating AI recommendations as verified facts

Agent-generated conclusions must be supported by current, authoritative business data.

Mistake 3: Automating approval and execution together

Where independent authorization is required, the agent must not approve its own proposed action.

Mistake 4: Ignoring concurrency and stale data

ERP data can change between analysis and execution. Revalidation is essential.

Mistake 5: Designing only the happy path

Production readiness requires testing failures, incomplete information, unauthorized requests and recovery procedures.

Mistake 6: Assuming every ERP operation is reversible

Business transactions may require compensating processes rather than a technical rollback.

Mistake 7: Measuring success only through automation volume

A high number of automated transactions is not valuable if exception rates, operational risks or reconciliation effort increase.

8. My Perspective: The Future Is Governed Autonomy

AI agents have the potential to make enterprise applications more proactive, responsive and efficient.

However, the objective should not be to remove human involvement from every ERP process.

The better objective is to determine where autonomous execution is appropriate, where business approval is essential and where AI should remain advisory.

A useful maturity model is:

Level 1 — Assist

The agent answers questions and retrieves information.

Level 2 — Analyze

The agent evaluates business data and identifies potential impacts.

Level 3 — Recommend

The agent proposes actions supported by relevant evidence.

Level 4 — Execute with approval

The agent initiates authorized actions after the required business approval.

Level 5 — Governed autonomy

The agent performs narrowly defined, low-risk actions within established policies, thresholds, monitoring and escalation controls.

Not every organization or business process needs to reach Level 5.

In fact, for some financial and operational transactions, maintaining mandatory human authorization may be the most appropriate long-term design.

9. Final Thoughts

Microsoft's direction toward agentic ERP is creating significant opportunities for Dynamics 365 customers and implementation partners.

But the real transformation is not simply connecting an AI agent to an ERP system.

It is redesigning how business decisions are analyzed, authorized, executed and governed.

Organizations that combine AI capabilities with strong process ownership, role-based security, business validation, human oversight and operational monitoring will be better positioned to realize sustainable value.

The future of enterprise ERP is not uncontrolled automation.

It is intelligent automation with clear accountability.

And that accountability must remain visible throughout the transaction lifecycle.

A question for ERP leaders, solution architects and AI practitioners:

If an AI agent can identify a supplier delay, recommend a purchase-order change and technically execute the update, at what point should human approval become mandatory?

Is it transaction value, business criticality, operational impact—or a combination of all three?

I'd welcome your perspectives.

OV Prakash Dynamics 365 | Enterprise Delivery | AI & Digital Transformation virajprakash365.com

#Dynamics365 #AgenticAI #ERP #SupplyChainManagement #AIGovernance