Why you shouldn't build AI with n8n or Make when you work seriously with ERP

There's a popular route in AI-land that sounds appealing: grab n8n, Make or Zapier, plug a language model into one side and your ERP into the other, and you're done. Cheap, flexible, fast to deploy. For a simple task — categorising a mail,sending a notification — that works fine.

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

Where things go wrong

Take something seemingly simple: an agent that posts an invoice in Exact or AFAS. The generic tool picks up 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 doesn't exist yet in the creditor database. There's a currency difference on the line. The general ledger account depends on the cost-driver project this invoice belongs to. There's a deviating VAT code because it involves an EU service. The invoice belongs to a purchase order that has been partially received, so matching is needed at line level.

The generic builder doesn't know these rules. Doesn't know Exact. Doesn't know AFAS. Doesn't know Business Central. Doesn't know the data model, the entity structure, the dependencies between journals, projects, cost centres and general ledger accounts. Doesn't know your process.

What you're left with is an agent that works in the lucky case, and produces silent errors in every deviating case. That's worse than no automation, because no one looks at it anymore.

Domain knowledge isn't a side matter

Here's the core. A working AI agent on an ERP requires three kinds of knowledge you need simultaneously:

• Knowledge of the ERP itself. What are the entities, which fields are mandatory, what dependencies exist between objects, how does the API behave with exceptions,what posting rules are 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 deviating VAT rule apply, which projects have their own posting rules, who authorises what.
• Knowledge of AI deployment 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 tool choice, it's a design question. And that's why we structurally work with partners — ERP consultants and process advisors who know the data models and the customer — who handle the configuration. We deliver the platform and the AI technology, they bring the domain knowledge.

Security and rights — the topic that only stands out when things go wrong

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

An AI agent doesn't automatically inherit the rights of the user invoking it. In your ERP, a buyer has different access than a project leader, and a project leader has different access than a controller. If you don't explicitly enforce that in the agent, you get one of two problems: either the agent has too many rights and can dothings the user personally isn't allowed to, or it has too few and works half the time.

A structural solution enforces that an agent acts within the rights of the invoking user. That an audit log records exactly who had what executed. That sensitive fields— salary data, confidential customer data — don't end up in prompts that landin places you don't want.

These aren't nice-to-haves. This is why AI agents working with ERP data in production run on a mature platform, not on a loose orchestration tool.

What this means for you

As a manager or director of a mid-sized company, the trade-off isn't "cheap and flexible versus expensive and rigid. The trade-off is experiment that works for three weeks versus something that lasts four years and moves with your organisation.

So don't start with a tool choice. Start with the question: who in my environment understands both my ERP configuration and my process? That's who you build the first agent with— on a platform made for that purpose, not on a generic integration layer.

Want to talk through what such a configuration would look like, or which partners do this for your ERP? We'd be glad to help.