How AI in ERP Turns APIs Into Governed Actions
AI in ERP works through APIs: a model or agent reads and writes ERP data by calling governed endpoints, often exposed as tools over the Model Context Protocol (MCP), under the same security roles a human user has. Gartner’s June 2025 forecast says over 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value or inadequate risk controls, so the integration and governance layer decides whether AI in ERP delivers. Related reading: ERP Modernization With AI-Driven MVPs.
If you run SAP, Oracle, Dynamics 365 or NetSuite, AI in ERP is mostly an integration problem, not a modeling one. The model is rented. What you own in AI in ERP is the contract between the model and your ledger, so API development and integration work, the core of ERP integration, decides whether AI in ERP ships or stalls. McKinsey’s State of AI 2025 survey, cited in its January 2026 ERP analysis, found only about 40 percent of companies report any enterprise-level EBIT impact from AI.
This guide covers five ERP integration patterns for AI in ERP, what each major vendor exposes, how MCP changes tool calling, how to make write-back safe, and where projects go wrong.
How AI in ERP Works Through APIs Today
AI in ERP runs in three layers: the ERP as system of record, an API or tool layer that exposes governed actions, and a model or agent that chooses which call to make. The model never touches the database: it calls an endpoint, and the ERP checks permissions and does the work.
- System of record: the ERP keeps the ledger, the approvals and the audit trail. Nothing about that changes.
- Tool layer: REST or OData endpoints, events, or an MCP server that wraps them for tool calling as named, typed actions.
- Reasoning layer: in AI in ERP, the language model or AI agents that read a request, pick a tool and explain the result.
That split is the whole design for AI in ERP. It inherits the controls you already trust (roles, approval workflows, audit logs) instead of inventing new ones, which is the main advantage of API-based ERP integration. McKinsey makes the same point from the business side: it expects AI agents to work as an extension of ERP for high-volume, well-defined workflows and exception cases, not to replace ERP in the near or medium term.
Think of the API as the vocabulary your AI in ERP stack is allowed to speak. A narrow tool such as “get open invoices for vendor” leaves little room for error. A raw SQL endpoint leaves a lot. Good tool calling is mostly good API design.
Five Ways to Connect AI in ERP Systems
There are five working ERP integration patterns for AI in ERP, and most production setups combine two or three. Choose by what the model must do: read, explain, recommend or act.
| Pattern | What It Does | Best For | Main Risk |
| Embedded vendor AI in ERP | Assistant or agent inside the ERP itself | Fast AI in ERP wins, lowest effort | Limited to the vendor’s scope and roadmap |
| RAG over ERP data | Retrieves records and documents into the prompt | Questions, summaries and policy lookups in AI in ERP | Stale or unauthorized data in answers |
| Tool calling over APIs | Model invokes ERP endpoints as functions | Status checks, drafting transactions | Wrong call or wrong parameters |
| MCP server in front of the ERP | Standard tool interface for any compliant client | Several AI agents, one governed gateway | Token misuse, tool sprawl |
| Event-driven agents | ERP events trigger an agent that proposes or completes work | Exceptions, approvals, reconciliation | Runaway loops, duplicate postings |
Techverx practitioner judgment: spend the first quarter on the first two patterns. Move to tool calling, MCP servers or autonomous AI agents only when you have a named workflow, tested tools and an owner for each tool.
Skipping straight to autonomous AI agents is the most common way AI in ERP stalls. Gartner calls out “agent washing”, where vendors relabel chatbots and RPA as agents, and estimates only about 130 of the thousands of agentic AI vendors are real.
What SAP, Oracle and Dynamics 365 Expose
All three vendors now run AI in ERP inside the ERP’s own security model, but the depth of API access differs. This section lists only what each vendor’s own pages state as of October 2026, so confirm details before designing ERP integration or MCP tool calling around them.
Microsoft Dynamics 365
Microsoft documents the most specific surface. Its Dynamics 365 ERP MCP server, described on Microsoft Learn (page updated August 2026), exposes three kinds of tools for AI in ERP: data tools for create, read, update and delete through data entities, form tools that mimic user actions on forms, and action tools that call developer-defined business logic.
The server returns only what the authenticated user’s security role can reach, and calls outside that role are rejected. Narrowing the role also narrows the agent’s context, which Microsoft says improves orchestration. The older 13-tool static server was retired on October 1, 2026, and the current one needs app version 10.0.47 or a qualifying update. Known limits include en-us only metadata and no availability during servicing windows.
Oracle Fusion
Oracle’s Fusion AI agents page (updated October 2026) says AI shares the same security, data governance, data model and transactions as the rest of Fusion. It lists interoperability through MCP and A2A for AI agents, human-in-the-loop approval workflows and a Data Access Advisor agent that explains data access rules. It does not detail the permission model, so request that in writing before you finalize an architecture for AI in ERP.
SAP
SAP describes Joule Agents that work across business functions, with dedicated finance, procurement and supply chain pages, and Joule Studio for building and deploying custom agents. The SAP pages we reviewed did not mention MCP, so confirm current protocol support for AI agents with your account team. SAP’s productivity claims, such as everyday tasks completed up to 90 percent faster, are vendor benchmarks on a modeled company, not independent results.
We could not verify current AI and MCP documentation for NetSuite or Infor, so check their release notes directly.
MCP and Agent Tool Calling Over ERP APIs
The Model Context Protocol (MCP) is an open standard that lets an AI client discover and call tools on a server through one interface, so you build the ERP integration once instead of once per model, which is why MCP is now central to AI in ERP. Tool calling is the older idea: the model returns a structured request and your code runs the function. MCP makes that portable across AI agents.
MCP’s authorization rules matter more for ERP than the tool list does. The June 2025 revision of the specification requires an MCP server to validate that a token was issued for it, and forbids passing the client’s token through to an upstream API. The MCP server can act as its own OAuth client to the ERP, using a separate token. The July 2026 revision keeps the same audience rule: a server accepts only tokens issued for it. Skip that and you invite the confused deputy problem.
Authorization is also optional in the specification itself (the July 2026 revision still says so), so a compliant MCP server can still be unsafe. Treat every MCP server that fronts AI in ERP as a security-reviewed service.
Design Tools Like an API for a Junior Clerk
- Name by intent: use get_open_invoices_for_vendor, not run_query.
- Type and bound parameters: enums, date ranges and maximum row counts keep calls predictable.
- Return less: send only the fields the task needs. It cuts cost and shrinks the prompt-injection surface.
- Separate read and write tools: you can then grant them to different identities, and write-back tools get their own scopes and approvals.
- Return errors a model can act on: “vendor not found, try the vendor ID” beats a stack trace.
Microsoft’s own guidance prefers data tools over form tools for standard record changes because they need fewer calls, which also means less MCP tool calling overhead. The same logic applies to any ERP: purpose-built endpoints beat a model clicking through screens.
If you need help wrapping legacy endpoints safely, a team with enterprise system integration experience can shorten the path.
Write-Back Safety: The Four-Rung Ladder
Write-back safety for AI in ERP means no AI-generated change reaches the ledger without a gate sized to its risk. A four-rung ladder works well: Read, Draft, Propose, Commit. This is Techverx practitioner judgment, not sourced data.
| Rung | What the AI Can Do | Gate | Example |
| Read | Query and summarize | Role-scoped access, logged | Open purchase order status |
| Draft | Create unposted documents | Draft state only, nothing posts | Draft a vendor credit memo |
| Propose | Submit for approval with evidence | Named approver sees the diff | Price change request |
| Commit | Post without a human | Hard limits, reversible, sampled audit | Release low-value matched invoices |
Score each action on four questions before choosing a rung. Can it be reversed? What is the maximum dollar or customer impact? Does it touch regulated records such as tax, payroll or financial close? Can you explain it from the logs? Any “no” or “high” keeps it at Propose or below.
Hypothetical example: an accounts payable team lets an agent handle three-way match exceptions. At Draft, it attaches evidence and suggested coding. At Propose, a clerk approves in one click. Only low-value exceptions from vendors with a clean history reach Commit, with a weekly sample audit.
Read-only RAG and tool calling carry little risk. Write-back tools carry most of it, so treat each one in AI in ERP as a change to production.
Two engineering habits make the ladder safe for AI in ERP. Give every write tool an idempotency key so a retried call cannot post a duplicate invoice. And log every AI-initiated action, which McKinsey’s January 2026 analysis also recommends alongside human-in-the-loop governance and adequate testing for AI in ERP.
Security and Access Controls for AI in ERP
The safest rule for security in AI in ERP is to let the ERP, not the model, decide what is allowed. OWASP’s 2025 entry on Excessive Agency names three root causes: excessive functionality, excessive permissions and excessive autonomy. Its fix is to enforce authorization in downstream systems instead of trusting the LLM.
- Run as the user when a person asks: user-context tokens with minimal scopes mean ERP roles apply automatically to AI in ERP requests.
- Give background agents their own least-privilege identity: Microsoft’s System agent role grants no permissions by itself, so you assign only the roles the agent needs.
- Treat retrieved text as untrusted: OWASP describes indirect prompt injection, where instructions hidden in files or web content change model behavior. Label and separate external content.
- Require approval for high-risk actions: OWASP lists human-in-the-loop approval as a core mitigation, and human-in-the-loop gates belong in every AI in ERP design.
- Log and rate-limit: these do not prevent excessive agency, but OWASP notes they limit the damage when AI agents misuse tool calling or MCP access.
Where data goes matters as much as who can act in AI in ERP. Ask where inference runs, what the model provider retains, and whether bank details, personal data and pricing need masking before they reach a prompt. Involve legal and privacy teams early, because contract terms and residency options vary by vendor and region.
RAG Over ERP Data and the Latency Problem
RAG, or retrieval-augmented generation, in AI in ERP means fetching relevant records and documents at question time and giving them to the model. It suits questions and explanations better than write-back, and it pairs well with tool calling for live numbers. It fails when the index is stale or when retrieval ignores who is asking.
- Retrieve with the user’s permissions: RAG must filter at query time, not after the model has seen the data.
- Index the narrative, query the numbers: use RAG for contracts, notes and policies. Use a live tool call for balances, stock and status. Never let a model quote a balance from an embedding.
- Stamp freshness: every RAG or tool calling answer should carry a timestamp so users can judge how fresh each retrieved fact is.
Latency in AI in ERP needs the same discipline. Transactional ERPs are built for postings, not for a model firing ten exploratory queries. Route heavy reads to a replica or warehouse, keep the live ERP for single-record lookups and writes, and use asynchronous jobs for anything a user is not waiting on.
Plan for downtime too: Microsoft’s server is unavailable during environment servicing, so your AI agents need a fallback. A clean AI-ready data foundation makes every one of these choices easier.
Best First Use Cases for AI in ERP
The best first use cases for AI in ERP are high-volume, rule-heavy workflows where a person already reviews the exceptions. McKinsey’s January 2026 analysis points the same way: agents add the most value in highly scaled transactions with well-defined workflow logic, plus exception cases that need heavy manual effort.
- Invoice and three-way match exceptions: AI agents gather evidence and suggest coding, and a clerk approves the write-back.
- Procurement and vendor questions: RAG over contracts and policies, plus live tool calling for order status.
- Reconciliation and close support: event-driven agents flag mismatches and draft journal entries for review.
- Self-service ERP questions: read-only answers on stock, orders and balances, through ERP integration that applies the asker’s own role.
This list is Techverx practitioner judgment. Pick one workflow and name its owner.
Anti-Patterns That Sink AI in ERP Projects
- Raw SQL or admin credentials for AI agents: it bypasses every control the ERP has.
- One mega-agent for every process: narrow AI agents with narrow tools are easier to test and audit.
- Letting the model do arithmetic or tax logic: compute in the ERP, and let the model explain.
- Skipping data cleanup: AI in ERP amplifies bad masters, so duplicate vendors and inconsistent item masters turn into confident wrong answers.
- No owner per tool: when a tool in your AI in ERP stack misbehaves, nobody is accountable for fixing it.
- Treating MCP as a security boundary: MCP standardizes tool calling, but it does not make a tool safe. Authorization is optional in the MCP specification, so your ERP integration team must add it.
- Underbudgeting change management: McKinsey’s rule of thumb, repeated in its January 2026 ERP analysis, is that for every 1 dollar spent developing a model, you need 3 dollars in change management for AI in ERP.
When to Wait
If your master data is unreliable or you cannot name an owner for the workflow, hold off on AI in ERP. Fix data quality and approvals first. A model on top of bad vendor records only produces confident errors faster.
A 90-Day Plan for AI in ERP
- Days 1 to 30: pick one AI in ERP workflow with high volume, clear rules and measurable exceptions. Map the roles involved and stand up read-only tools using RAG and tool calling.
- Days 31 to 60: add the Draft and Propose rungs of write-back, build an evaluation set from real historical cases, and turn on action logging.
- Days 61 to 90: review exception rates and approval overrides. Promote only the narrowest, safest slice of AI in ERP to Commit.
For a second pair of eyes, Techverx’s ERP implementation and agentic AI automation teams work on exactly this boundary between ERP integration and AI agents. Read next: ERP Implementation Success.
Short Verdict
AI in ERP succeeds when the API layer is boring: narrow tools, role-scoped access, logged actions and human gates sized to risk. Start AI in ERP with reads, climb the ladder only as evidence builds, and buy standard vendor capabilities before building your own. The model is the easy part. The hard part is ERP integration done well.
