Integrating AI with your ERP: what it really takes (APIs, data, permissions)

There's one question that shows up in every business AI project, usually at the second meeting, and it decides whether the project happens or stays a slide: "will it connect to our ERP?". It's the right question, because an agent that can't see your real data — prices, stock, customer records, order history — can only write generic text. Value appears when the model works on your numbers, and that's an integration problem, not an artificial intelligence one.

There are essentially three technical routes

The first, and best, is the API: the ERP exposes documented endpoints to read and write data, and the flow calls them with dedicated credentials. Almost every modern cloud ERP has one, often REST, sometimes included in the subscription and sometimes sold as an add-on module. With an API the connection is clean, real-time and reversible: if you change automation tool tomorrow, the data stays where it is.

The second route is direct database access, typical of on-premise systems

It works and it's fast, but handle it carefully: read-only, on a copy or a dedicated view, never writing straight into application tables, because the ERP's validation logic lives in the software, not in the database. Bypass that principle and sooner or later you produce data the ERP itself considers inconsistent.

The third route is a synced export: the ERP periodically produces files — CSV, XML, fixed-width — that the flow reads, normalises and uses. It's the least elegant option and the one I use most often in Italian SMBs, because it works even with old, closed or unlicensed software. The trade-off is data freshness: if the export runs nightly, the agent works on yesterday's picture, which is perfectly fine for a price list and much less so for stock availability.

To find out in half an hour where you stand, four questions to whoever manages the software are enough: is there API documentation, public or vendor-provided; can you create a technical user with limited permissions; is the system in the cloud or on a company server; does an automatic export to other tools already exist, even just to the accountant. Those four answers alone determine which of the three routes is viable and what it will cost.

Then there's the part that gets systematically underrated: permissions and traceability. An agent writing into the ERP must have its own user, with the minimum privileges needed and a log of what it did. It must not use a person's credentials, must not reach tables it doesn't need, and every write must be identifiable. That's not consultant fussiness: it's what lets you work out in ten minutes, the day a number looks wrong, whether the automation or a person made the mistake.

On data quality, a clear warning

Integration does not fix duplicate customer records, item codes written three different ways, or notes fields used as a dumping ground for important information. A language model handles part of that mess — it's actually one of the things it does better than classic automation — but it works no miracles on a catalogue where the same product appears four times at four prices. A minimal clean-up of the data the flow uses is almost always part of the project, and it belongs in the quote from day one.

On timelines: in my experience integration accounts for 40% to 60% of the total duration of a project like this. A documented API connection closes in a few days; an export that needs normalising takes one or two weeks; an ERP customised over the years by several vendors can take longer, and in that case it's better to start from one flow and one data type instead of attempting the full connection.

The closing advice is counterintuitive: don't pick the AI tool first and then check whether it connects. Do the opposite. Look at which data your ERP can hand over and how easily, and design the first use case around that. In nearly every SMB there is at least one high-value process that can be automated with the data already accessible today — that's where to start, while in parallel you assess whether opening the API costs less than what it saves.