Yes, in almost every case. AI agent ERP integration runs through 1 of 4 routes: the ERP's API, its database, the files and EDI it already exchanges, or its screens. An ERP with no external API, an on-premise install or a migration in progress changes only the route. IT provides access, a test environment and an owner.
"Will it work with our ERP?" is one of the questions we hear most on calls with manufacturers and distributors. It usually arrives with 2 follow-ups: "Our ERP has no external API, can you still connect?" and "Do we need an integration layer first?" At Lleverage we think the ERP is rarely the reason an AI agent project fails. The reason is usually that nobody agreed up front who gives the agent access, where it is tested and what it may change. We build ERP integrations onto the systems you already run, including the on-premise and API-less ones, and our engineers connect them with your team during delivery. If you want to go through your own systems with us, book a demo.
This guide is ERP-generic. It covers the 4 ways an agent reaches an ERP, the checklist IT needs to prepare, the options when there is no API, on-premise systems behind a firewall, the integration layer question and what to do when you are halfway through a migration. For the details of one system, our pages on AI agents in Business Central, SAP and Exact Online go further.
Will an AI agent work with your ERP?
An AI agent works with your ERP if a person on your team can do the job in it. Anything a person reads, the agent can read; anything a person keys, the agent can key, through the API where there is one and through the screen where there is not. The real questions are access, testing and control.
That sounds like a sales line, so here is what it means. An AI agent that takes a job off a desk, such as order entry or invoice matching, does 2 things with the ERP. It reads master data to check its work: customers, items, prices, open purchase orders. And it writes the result: a sales order, a purchase invoice, a changed delivery date. Neither needs a modern ERP. They need a way in that is reliable, permitted and logged.
The ERP landscape in our market makes this question unavoidable. According to Eurostat's 2025 survey of ICT use in enterprises, 41% of small EU enterprises and 89% of large ones use ERP software. Many of those systems were installed long before anyone thought about AI agents. Some run on a server in the building. Some are versions the vendor no longer sells. Some were customised so heavily that the standard interface misses what the business actually uses.
At Lleverage we start from the opposite assumption to most integration projects. Your ERP stays the system of record, nothing is migrated and nothing is copied into a second database. The agent fills the same fields your team fills, so the ERP checks them the same way it checks a person's work. Turn the agent off and your systems are exactly as they were the day before. That is why an older ERP shapes the design of the project and rarely stops it.
How does an AI agent connect to an ERP?
An AI agent connects to an ERP in 1 of 4 ways: through the ERP's API, directly to its database, through the files and EDI messages it already imports and exports, or by working its screens with a person's login. Most projects use 2 of them, for example the API for writing orders and a file export for reading stock.
| Route | How it works | What IT provides | Fits best when | Watch out for |
|---|---|---|---|---|
| API | The agent calls the ERP's own interface to read and create records | An API user or app registration, the scopes it needs, a test environment | The ERP is a recent cloud or on-premise version with the interface switched on | Some on-premise installs lack the API module |
| Database | The agent reads tables directly, behind the firewall | A read account on the database, the table map | Reading master data, stock and history fast | Writing straight into tables skips the ERP's own checks |
| Files and EDI | The agent reads exports and drops import files where the ERP picks them up | A shared folder, the file layout, the import schedule | The ERP already imports orders or invoices from files | Changes land on the ERP's schedule, not instantly |
| Screen | The agent logs in like a person and keys the fields a person keys | A user account with a person's rights, a test login | There is no API and no import route, such as a green screen or desktop client | Slower than an API and sensitive to screen changes |
The order in that table is also the order of preference. An API is the cleanest route because the ERP applies its own validation and permissions to every request. Reading the database is fast and safe for lookups. Writing straight into an ERP's tables is another matter, because it skips the business logic the vendor built. File imports are often already there for EDI customers. They work well for volumes that do not need an answer within the minute. The screen is the last route and the one that makes "no API" a solvable problem.
The route is chosen for each job. Order entry needs to create a record and read back the order number, so it wants an API or the screen. A demand forecast reads history and writes nothing, so a nightly export can be enough. That is why the first conversation with IT starts with the job the agent will do.
What does IT need to provide for AI agent ERP integration?
IT needs to provide 6 things: a named owner, an account for the agent with only the rights the job needs, a test environment with realistic data, a network route that does not open the ERP to the internet, the list of fields the job touches, and agreement on how failures are reported. Everything else our engineers build.
This is the checklist we go through with IT in the first week. It is short on purpose, because a long list of preconditions is how a project stretches into months.
- A named owner on your side. Usually the ERP administrator or the person who runs the ERP partner relationship. They answer questions about custom fields and approve access. At Microtechniek this was 2 ERP administrators working with our engineers.
- An account for the agent. A separate service account or app registration, never a person's own login. It makes every action traceable to the agent and lets you switch it off without locking anyone out. It carries only the rights the job needs: reading customers and items and creating sales orders, for example, but not the general ledger.
- A test environment. A sandbox or test company that is a copy of production, with real customers and items in it. Without it, the first test happens in production.
- A network route. For a cloud ERP this is the vendor's API. For an on-premise ERP it is a connection your IT team agrees and controls, so nothing is opened to the internet.
- The fields the job touches. Which fields are mandatory, which are custom, which are filled by the ERP itself. Your team knows this; it is rarely written down.
- Agreement on failures. Who gets told when a connection drops or an order cannot be written, and in which channel.
For Business Central online, Microsoft documents the account part precisely. Its guide to service-to-service authentication describes an app registered in Microsoft Entra ID. The app connects as an application, without impersonating a user and without a sign-in prompt, so an integration can run unattended. It is then set up inside Business Central and given its own permission sets. Microsoft's guidance is explicit that applications cannot be given the SUPER permission set and should follow the least-privilege principle. That is exactly the shape we want for an agent. For SAP, an account on your own servers signs in with a user name and password or an API key, and the SAP account decides what the connection can see and change.
The test environment is the item most often missing, and it matters more than it looks. Microsoft's documentation on copying a Business Central environment lists what changes when production is copied to a sandbox. Tasks in the job queue are stopped, outbound HTTP calls from extensions are blocked by default and a list of service connections is disabled. Those precautions are there so a test copy cannot send a real invoice or a real email. They also mean IT should check, before testing starts, which of those settings the job depends on.
What if your ERP has no external API?
If your ERP has no external API, the agent uses another way in: a supported import route, a read connection to the database, or the screen, keyed with the access a person has. Where none of those is allowed, the agent does the reading and deciding upstream and a person enters the result.
"No API" covers several different situations, and the right answer depends on which one you have.
The API exists but is not switched on. Some on-premise ERPs have an interface that is a separate module, a licence option or a setting on the server. Microtechniek ran Ridder iQ on-premise, and the on-premise installation did not expose the API module the cloud version has. The story page says 2 other automation projects at similar companies had already failed at exactly this point. In December 2025 a Ridder specialist installed the API module on-site, and our team adapted the cloud API to work with the on-premise environment. Microtechniek now has around 60 orders a week landing in Ridder iQ on their own, and its story page counts more than 500 hours a year back for the admin desk.
There is an import route. Plenty of older ERPs read order files, EDI messages or a CSV from a shared folder, often because a large customer once insisted on it. If the import exists, the agent can produce the file in the layout the ERP already accepts. Nothing in the ERP changes.
There is only a screen. A green screen on an AS/400 or a desktop client with no interface at all. Here the agent works the screen: it logs in with its own account, reads what a person reads and keys the fields a person keys. It is given the access a person has, and nothing beyond it. This route is slower than an API and needs care when the screens change. It is also often the only one that does not involve the ERP vendor.
Nothing may be written from outside. Some companies decide their system of record stays closed, for reasons of certification, support contracts or caution. That still leaves most of the work. SPL Treatments runs a legacy desktop ERP with no API, no import route and no browser layer. The agent there reads the customer's purchase order, works through the aerospace specifications it references and drafts the route the part should follow, with every recommendation cited. A person checks it and keys the confirmed route into the ERP by hand. The time comes back upstream, in the reading, and the last step stays manual.
We think the last option is underrated. An ERP with no way in is usually treated as the end of the conversation. In practice the slow part of most back office jobs is reading, matching and deciding, and none of that happens in the ERP.
How do you connect an on-premise ERP without opening it to the internet?
You connect an on-premise ERP through a connection our engineers set up with your IT team during delivery, so the ERP is never opened to the internet. The agent then reaches the database, the API or the screen behind your firewall, with its own account and only the access the job needs.
The worry behind this question is reasonable. An ERP on your own server was never designed to face the internet, and IT is right to refuse to open it up. The agent does not need that. The database on your own server and the AS/400 in the corner are reached without opening either one to the internet, and SAP ECC or S/4HANA on your own servers is connected as it runs today.
A few points are worth agreeing with IT in advance:
- What it can reach. Only the ERP, the database and the shared folders the job uses, and within those only the objects and fields you name.
- How it signs in. With the agent's own account, not a shared admin login. For Business Central on your own servers, Microsoft's service-to-service guide notes that the server must be configured for Microsoft Entra authentication with OpenID Connect before an app can connect that way; Navision connects with a user name and password.
- Where the data goes. Lleverage is EU hosted by default, with on-prem where you need it and the data residency you choose.
On-premise is also where the older versions live. Microsoft's own table shows that service-to-service authentication arrived in Business Central online with version 18.3 and on-premise with versions 18.11 and 19.5. An older install, or a Navision system, needs another route. That is a design decision for the first week.
Do you need an integration layer first?
No. You do not need an integration platform, middleware or a data warehouse before an AI agent can work with your ERP. The agent connects to the ERP and the systems around it directly. If you already run an integration layer, the agent can use it, but building one first only delays the project.
This question usually comes from experience. Some IT teams were told by an earlier vendor or partner that the data had to be cleaned, centralised and exposed through middleware first. That advice made sense for dashboards and data projects, where the goal is one consistent copy of the data. An agent works differently. It reads from the systems that already hold the record and writes the work back into them, so there is no second copy to keep in sync.
The same goes for the data itself. The fear that "our data is not clean enough" is the other common reason to wait. SIG Benelux, a building materials distributor running Dynamics 365, found the opposite. The order history in the ERP already held the translations the sales desk had made by hand, from a customer's description to the right article. That history became the rulebook.
"I knew the technology made this possible. My biggest question was the quality of our data. It was a positive surprise to see the order history was enough of a base to get results this fast." Ditte Smit, Marketing Director, SIG Benelux
At SIG the automation sits next to Dynamics 365 and not inside it. Customising the ERP would have cost more and left less room to change course. The flow reads the order, works out what it means and creates a draft order that a salesperson reviews and approves.
There is one case where an existing integration layer helps: when the agent needs data that is already flowing through it, such as EDI messages from a large customer or stock levels from a warehouse system. Then we read from the layer instead of building a second route. When your ERP, WMS and MES do not share data at all, our post on what happens when your ERP, WMS and MES don't talk to each other covers that problem in more depth.
What should you do if you are in the middle of an ERP migration?
If you are mid-migration, start the agent on the ERP you run today, on a job that exists in both systems, and plan the switch as a change of connection. The agent's rules, checks and learned corrections sit in Lleverage, so they move with you. Only the route into the ERP is rebuilt.
A migration is the most common reason companies give for waiting. It is also, in our view, the weakest one. ERP migrations run long, and the back office keeps keying orders and invoices by hand for the whole of it. The SAP timeline makes the point for one large group of companies. In 2020 SAP announced mainstream maintenance for the core applications of SAP Business Suite 7 until the end of 2027. Optional extended maintenance runs until the end of 2030, at a premium of 2 percentage points on the existing maintenance basis, and SAP S/4HANA is maintained until the end of 2040. Many SAP ECC customers will be planning, testing or running a migration for years.
What to do depends on where you are:
| Where you are | What we recommend | What stays the same | What changes at go-live |
|---|---|---|---|
| Choosing a new ERP | Start on the current ERP with one job, such as order entry | The job, the rules and the corrections the agent learns | The connection to the new ERP |
| Building and testing the new ERP | Connect the agent to the old ERP and to the new test environment | The checks the agent applies | Which environment it writes to |
| Go-live in the next 3 months | Run the agent in shadow mode against the old ERP, switch on after go-live | The inbox, the documents and the review step | The fields mapped in the new ERP |
| Old and new ERP side by side | Let the agent write to whichever system holds that entity or site | One process for the desk | Routing rules per entity |
There are 2 reasons this works. First, the slow part of order entry or invoice matching is reading the document and matching it to the right customer, item and order. That logic lives with the agent, outside the ERP. Second, the corrections your team makes while the agent runs become knowledge your company owns, held on your side and exportable in full, so the migration does not wipe them out.
Our longer view of where ERP projects stand is in ERP automation in 2026. If your migration has stalled, the agent can take the manual work off the desk while it is fixed.
How do you test and control what the agent changes in your ERP?
You test the agent in a sandbox or test company first, then in shadow mode next to your team on real documents, and only then let it write to production. In production every connection is scoped per object and per field, and you set the confidence threshold above which a person decides.
Testing runs in 3 steps.
- The test environment. The agent runs on real documents from the last few weeks against a copy of production. Your ERP owner checks the records it created. This is where missing custom fields and odd validation rules show up.
- Shadow running. The agent processes live documents alongside the team without writing anything final, so everyone sees where it is wrong without a customer noticing. SIG Benelux spent the second half of its project building and shadow running before going live.
- Production with a threshold. The agent writes to the live ERP, but only what it is confident about. Below the line, a person decides.
Control is built into the platform on top of the ERP's own permissions. With AI governance in Lleverage an agent has no standing access to anything. Every system it touches is a connection you made, scoped to the objects and the fields you named, with reading and writing as separate permissions. It can work with sales orders and customers in Business Central, for example, without ever touching the ledger. Every action carries what the agent read, what it decided and why, timestamped against the record it touched.
The threshold is the part ERP owners care about most. Every process runs at a threshold you chose, and it only moves when you move it, never because the model grew more confident on its own. One setting returns a process to full supervision. Some companies keep a final click for good: Xpol's agent prepares a webshop order in Business Central that a person signs off, and ambiguous items are left blank rather than guessed. Others let most volume through on its own: at Topa Bathroom Products over 90% of incoming orders are processed directly into Business Central without manual input. Our post on supervised agents and background automation explains how to choose.
Where should you start with AI agent ERP integration?
Start with one job that touches the ERP many times a day, such as order entry, and one inbox. Agree the 6 points on the IT checklist in the first week, test on a copy of production, shadow run on live documents and then switch on. The route into the ERP is chosen for that job.
Order entry is a common first job for a practical reason. It has a clear start, when an order arrives, and a clear end, when a sales order exists in the ERP. A person can tell within a minute whether the agent got it right. Koninklijke Dekker, a timber trader, started there. Its agent reads PDF, Excel and email orders, checks products, availability and pricing, and creates the order in Business Central. Only low-confidence exceptions go to a person. Topa started with the same job and the agent creates the sales order in Business Central via API.
The route follows from the job and the ERP:
- A recent cloud ERP: the vendor's API, with a service account and a sandbox.
- An on-premise ERP with an API module available: switch the module on, then use the API through a connection your IT team controls.
- An on-premise ERP with no API: the import route if there is one, the screen if there is not.
- A system of record that stays closed: the agent does the reading and drafting, a person enters the result.
Our engineers do the connecting. Forward deployed engineers work alongside your team, so work comes off the desk in the first weeks rather than at the end of a project. The awkward systems, on-prem or without an API, are part of that delivery. If order intake is the job you have in mind, our AI order management page shows what the agent does from the inbox to the sales order. To check your own ERP, your version and your constraints with an engineer, book a demo and bring your ERP administrator.
Frequently asked questions
Can an AI agent connect to an ERP with no API?
Yes. Where there is no API, the agent uses an import route the ERP already has, reads the database for lookups, or works the screen with its own account and the access a person has. Where nothing may be written from outside, the agent reads and drafts the work and a person enters the confirmed result in the ERP.
What does IT need to provide to connect an AI agent to our ERP?
IT provides a named owner, a separate account for the agent with only the rights the job needs, a test environment that copies production, a network route that keeps the ERP closed to the internet, the list of fields the job touches and agreement on who is told about failures. Our engineers build the connection itself.
Do we need middleware or an integration layer first?
No. The agent connects directly to the ERP and to the mailboxes, folders and service desk around it. Nothing is copied into a second database, so there is nothing to synchronise. If you already run an integration layer that carries the data the agent needs, such as EDI messages, the agent can read from it instead.
Should we wait until our ERP migration is finished?
No. Start on the ERP you run today with one job that exists in both systems. The rules, checks and corrections sit in Lleverage and move with you; only the connection to the ERP is rebuilt at go-live. The agent can also take manual work off the desk while the migration runs, which is when the team has the least time.
Is it safe to give an AI agent access to our ERP?
The agent only reaches what you connect, scoped per object and per field, with reading and writing as separate permissions. Every action is logged with what it read, what it decided and why. You set the confidence threshold above which a person decides, and one setting returns a process to full supervision.