Waarom n8n of Make tekortschieten voor complexe ERP-geïntegreerde AI
n8n of Make inzetten om een taalmodel aan je ERP te koppelen klinkt aantrekkelijk: goedkoop, flexibel en snel. Voor eenvoudige taken werkt het prima, maar voor serieuze ERP-processen loopt het na drie weken vast en ontstaan er onopgemerkte fouten. Waarom domeinkennis, de juiste partners en strikte beveiliging onmisbaar zijn bij het bouwen van AI op ERP-data.
Robert Keunen
4 min

Er is een populaire route in AI-land die aantrekkelijk klinkt: pak n8n, Make of Zapier, plug een taalmodel aan de ene kant en je ERP aan de andere kant, en je bent klaar. Goedkoop, flexibel, snel uit te rollen. Voor een simpele taak — het categoriseren van een mail, het sturen van een notificatie — werkt dat prima.
Voor serieuze ERP-processen werkt het drie weken. Daarna gaat het stuk.
Waar het misgaat
Neem iets dat ogenschijnlijk simpel is: een agent die een factuur in Exact of AFAS boekt. De generieke tool pakt de PDF, gebruikt een taalmodel om leverancier, factuurnummer en bedrag te extraheren, en stuurt dat als API-call naar je ERP. In een demo ziet het er perfect uit.
Dan komt de realiteit.
• De leverancier bestaat nog niet in de crediteurenadministratie.
• Er is sprake van een valutieverschil op de regel.
• De grootboekrekening is afhankelijk van het kostenplaats-project waartoe deze factuur behoort.
• Er is sprake van een afwijkende btw-code omdat het een EU-dienst betreft.
• De factuur hoort bij een inkooporder die gedeeltelijk is ontvangen, dus is matching op regelniveau vereist.
De generieke bouwer kent deze regels niet. Kent Exact niet. Kent AFAS niet. Kent Business Central niet. Kent het datamodel, de entiteitsstructuur en de afhankelijkheden tussen dagboeken, projecten, kostenplaatsen en grootboekrekeningen niet. Kent jouw proces niet.
Wat je overhoudt is een agent die werkt in het gelukkige geval, en in elk afwijkend geval stille fouten produceert. Dat is erger dan geen automatisering, want er kijkt niemand meer naar om.
Domeinkennis is geen bijzaak
Hier is de kern. Een werkende AI-agent op een ERP vereist drie soorten kennis waarover je tegelijkertijd moet beschikken:
• Kennis van het ERP zelf. Wat zijn de entiteiten, welke velden zijn verplicht, welke afhankelijkheden bestaan er tussen objecten, hoe gedraagt de API zich bij uitzonderingen, wat zijn de boekingsregels in het systeem.
• Kennis van het proces van deze klant. Elk bedrijf heeft afwijkingen van de standaard. Welke crediteuren vallen onder welke goedkeuringsflow, wanneer is een afwijkende btw-regel van toepassing, welke projecten hebben hun eigen boekingsregels, wie autoriseert wat.
• Kennis van AI-implementatie zelf. Waar laat je het taalmodel beslissen en waar niet, hoe ontwerp je een agent die transparant is over wat hij doet, hoe voorkom je dat hallucinaties de administratie vervuilen.
Het combineren van die drie is geen toolkeuze, het is een ontwerpvraagstuk. En daarom werken we structureel samen met partners — ERP-consultants en procesadviseurs die de datamodellen en de klant kennen — die de configuratie verzorgen. Wij leveren het platform en de AI-technologie, zij brengen de domeinkennis.
Beveiliging en rechten — het onderwerp dat pas opvalt als het misgaat
Een ander punt dat in generieke tools bijna altijd over het hoofd wordt gezien: wie mag wat.
Een AI-agent neemt niet automatisch de rechten over van de gebruiker die hem aanroept. In je ERP heeft een inkoper andere toegangsrechten dan een projectleider, en een projectleider andere dan een controller. Als je dat niet expliciet afdwingt in de agent, krijg je een van de twee problemen: of de agent heeft te veel rechten en kan dingen die de gebruiker persoonlijk niet mag, of hij heeft er te weinig en werkt de helft van de tijd niet.
Een structurele oplossing dwingt af dat een agent handelt binnen de rechten van de gebruiker die de actie aanroept. Dat een audit log precies vastlegt wie wat heeft uitgevoerd. Dat gevoelige velden — salarisgegevens, vertrouwelijke klantdata — niet terechtkomen in prompts die belanden op plekken waar je ze niet wilt hebben.
Dit zijn geen ‘nice-to-haves’. Dit is waarom AI-agents die met ERP-data werken in productie op een volwassen platform draaien, en niet op een losse orchestratietool.
Wat dit voor jou betekent
Als manager of directeur van een middelgroot bedrijf is de afweging niet ‘goedkoop en flexibel versus duur en rigide’. De afweging is een experiment dat drie weken werkt versus iets dat vier jaar meegaat en meebeweegt met je organisatie.
Begin dus niet met de keuze voor een tool. Begin met de vraag: wie in mijn omgeving begrijpt zowel mijn ERP-configuratie als mijn proces? Dat is degene met wie je de eerste agent bouwt — op een platform dat daarvoor gemaakt is, niet op een generieke integratielaag.
Wil je eens doorpraten over hoe zo’n configuratie eruit zou zien, of welke partners dit voor jouw ERP doen? We helpen je graag.