Why n8n or Make fall short for complex ERP-integrated AI

There is a popular route in AI land that sounds appealing: take n8n, Make or Zapier, plug a language model into one end and your ERP into the other, and you are done. Cheap, flexible, fast to deploy. For a simple task — categorising an email, sending a notification — that works fine.

For serious ERP processes, it works for three weeks. Then it breaks.

Where it goes wrong

Take something that is seemingly simple: an agent booking an invoice in Exact or AFAS. The generic tool takes the PDF, uses a language model to extract supplier, invoice number and amount, and sends that as an API call to your ERP. In a demo, it looks perfect.

Then comes reality.

• The supplier does not yet exist in the accounts payable ledger.

• There is a currency difference on the line.

• The ledger account depends on the cost centre project to which this invoice belongs.

• There is a divergent VAT code because it concerns an EU service.

• The invoice belongs to a purchase order that has been partially received, so matching at line level is required.

The generic builder does not know these rules. Does not know Exact. Does not know AFAS. Does not know Business Central. Does not know the data model, the entity structure and the dependencies between journals, projects, cost centres and ledger accounts. Does not know your process.

What you are left with is an agent that works in the happy path, and in every exceptional case produces silent errors. That is worse than no automation, because no one is looking at it anymore.

Domain knowledge is not a side issue

Here is the core. A working AI agent on an ERP requires three types of knowledge that you must have at the same time:

• Knowledge of the ERP itself. What are the entities, which fields are mandatory, what dependencies exist between objects, how does the API behave in case of exceptions, what are the booking rules in the system.

• Knowledge of this customer's process. Every company has deviations from the standard. Which creditors fall under which approval flow, when does a divergent VAT rule apply, which projects have their own booking rules, who authorises what.

• Knowledge of AI implementation itself. Where do you let the language model decide and where not, how do you design an agent that is transparent about what it does, how do you prevent hallucinations from polluting the administration.

Combining those three is not a choice of tool, it is a design issue. And that is why we structurally work together with partners — ERP consultants and process advisors who know the data models and the customer — who take care of the configuration. We provide the platform and the AI technology, they bring the domain knowledge.

Security and permissions — the topic that only gets noticed when things go wrong

Another point that is almost always overlooked in generic tools: who is allowed to do what.

An AI agent does not automatically inherit the permissions of the user who calls it. In your ERP, a buyer has different access rights than a project manager, and a project manager different than a controller. If you do not explicitly enforce that in the agent, you get one of two problems: either the agent has too many permissions and can do things that the user personally is not allowed to, or it has too few and does not work half the time.

A structural solution enforces that an agent acts within the permissions of the user who initiates the action. That an audit log records exactly who executed what. That sensitive fields — salary data, confidential customer data — do not end up in prompts that land in places where you do not want them.

These are not ‘nice-to-haves’. This is why AI agents working with ERP data in production run on a mature platform, and not on a loose orchestration tool.

What this means for you

As a manager or director of a medium-sized company, the trade-off is not ‘cheap and flexible versus expensive and rigid’. The trade-off is an experiment that works for three weeks versus something that lasts four years and moves with your organisation.

So do not start by choosing a tool. Start with the question: who in my environment understands both my ERP configuration and my process? That is the person with whom you build the first agent — on a platform designed for it, not on a generic integration layer.

Would you like to talk about what such a configuration would look like, or which partners do this for your ERP? We are happy to help you.