AI-agent voor inkooporders in Exact Online: van brondata naar vrijgave

Deze proefroute is bedoeld voor een inkoper of operations-team dat Exact Online gebruikt en gecontroleerd wil automatiseren. Je wilt voorraad, leveranciersvoorwaarden en contractprijzen sneller naar een bestelvoorstel brengen, maar wilt voorkomen dat een taalmodel zonder controle een financiële mutatie maakt.

Een AI-agent voor inkooporders leest brondata uit je ERP, leveranciersvoorwaarden en voorraadgegevens, maakt een controleerbaar bestelvoorstel en zet dat eerst in een staginglaag. Een aparte vrijgavecontrole vergelijkt bron, prijs, voorraad, payload en goedkeuring. Pas daarna maakt een beperkte uitvoerder de inkooporder aan. Het taalmodel beslist dus niet zelf of een write is toegestaan.

Exact Online is hier een concrete proefroute, omdat de actuele REST-referentie de bronnen en inkooporderobjecten bij elkaar brengt. Dezelfde opzet werkt met een ander ERP zolang je bronvelden, contractversie, status en vrijgave buiten het taalmodel kunt afdwingen. Ik heb de actuele Exact-, automatiserings- en securitybronnen op 4 oktober 2026 gecontroleerd; per bron staat de eigen controledatum in de bronlijst.

Wat je nodig hebt: bronvelden vóór modeluitvoer

Begin niet met een prompt. Begin met de vraag welke feiten een inkoper nodig heeft om een order te kunnen verdedigen als iemand hem morgen terugleest.

Plan voor deze proefroute minimaal vier soorten kennis:

Budgetorde voor een beperkte pilot: reken hieronder met één divisie, één artikelgroep, één goedkeuringspad en geen automatische leveranciersmail. Dit zijn werkramingen voor 4 oktober 2026, geen offertes. De actuele, op 4 oktober 2026 gecontroleerde Exact Online Developer-pagina vermeldt € 15 per maand exclusief btw voor een ontwikkelabonnement met testadministraties; je klantlicentie en eventuele productie-uitbreidingen vallen daarbuiten.

Bij hogere ordervolumes, meerdere administraties, leveranciersmail of strengere auditretentie lopen vooral bouw, modelgebruik en beheer op. Zet die posten apart in je businesscase; een goedkope workflowlicentie maakt de releasecontrole niet gratis.

Voor Exact Online heb je een applicatie in het Exact App Centre nodig, OAuth-toegang en de juiste divisie. Een divisie is de administratie waarin je voorraad, leveranciers en orders staan. Gebruik nooit een divisienummer uit je testomgeving als vaste instelling. Haal de actuele context op en bewaar die bij iedere run.

De actuele Exact Online REST-referentie toont aparte routes voor StockPosition, SupplierItem, PurchaseOrders en PurchaseOrderLines. De routes zitten onder /api/v1/{division}/. Dat is belangrijk: een succesvolle aanvraag tegen de verkeerde divisie is nog steeds de verkeerde data.

Je hebt deze bouwstenen nodig:

• Een afgebakende trigger. Bijvoorbeeld: een artikel komt onder het bestelpunt, een bestelvoorstel wordt aangemaakt of een inkoper start handmatig een proefrun. Laat de eerste versie één artikelgroep of één magazijn behandelen.
• Een artikel- en leverancierssleutel. Leg vast hoe je SKU, Exact-artikel-ID, leveranciersartikelcode, leverancier-ID, magazijn en eenheid aan elkaar koppelt. Een artikelnummer dat in de webshop anders heet dan in Exact hoort naar de uitzonderingsqueue.
• Voorraad en vraag. Lees actuele voorraad, gereserveerde aantallen, verwachte ontvangsten, openstaande inkoop en de vraagperiode. Maak onderscheid tussen voorraad die fysiek aanwezig is en voorraad die alleen is toegezegd.
• Leveranciersvoorwaarden. Bewaar minimale afname, verpakkingseenheid, levertijd, bestelkalender, valuta, betalingsconditie en de geldigheidsperiode van de prijs. Een contractprijs zonder begin- en einddatum is geen vrijgavebewijs.
• Een prijsbron. Dat kan SupplierItem in Exact zijn, een goedgekeurde prijslijst of een contractbestand met versienummer. Bewaar de bronlocatie, gecontroleerd tijdstip en een hash van het bestand of de inhoud.
• Een staginglaag. Gebruik bijvoorbeeld PostgreSQL, Supabase, een datatabel in n8n of een eigen wachtrij. Daar staat het voorstel voordat een live ERP-record wordt aangemaakt. Slack of e-mail mag een melding dragen, maar niet het formele goedkeuringsrecord.
• Een menselijke eigenaar. De eigenaar controleert afwijkingen. De aanvrager en de goedkeurder zijn bij risicovolle orders niet automatisch dezelfde persoon.
• Een testadministratie en replay-regel. Je hebt een veilige plek nodig voor proeforders en een vaste aanpak voor time-outs. Een onbekende API-uitkomst mag nooit leiden tot blind opnieuw posten.

Normaliseer de gegevens in je eigen stagingmodel. Bewaar de oorspronkelijke Exact-velden ook, zodat je later kunt verklaren hoe een intern veld is gevuld.

De actuele Exact-documentatie voor PurchaseOrderLines noemt onder meer InStock, ProjectedStock, QuantityInPurchaseUnits, NetPrice en PurchaseOrderID. QuantityInPurchaseUnits is het veld dat de documentatie aanwijst bij het aanmaken van een inkooporderregel. Zie die namen als de brug naar je mapping, niet als een reden om ieder beschikbaar veld blind door te geven aan een agent. Vraag alleen op wat je besluit nodig heeft.

0/7

• Kies één magazijn, artikelgroep en besteltrigger voor de proef
• Leg Exact-divisie, artikel-ID, leverancier-ID en eenheid vast
• Verzamel voorraad, openstaande inkoop en verwachte ontvangst
• Bewaar prijs, valuta, geldigheidsperiode en bronversie
• Richt staging in buiten het live schrijfpad
• Wijs een eigenaar en een bevoegde goedkeurder toe
• Maak een testorder, request_id en veilige replay-regel

De checklist voorkomt een veelgemaakte denkfout: dat een model met “voorraad” en “leverancier” genoeg context heeft. Zonder geldigheidsdatum, eenheid en openstaande inkoop kan het antwoord overtuigend zijn en toch financieel verkeerd.

Concrete stappen: van Exact-data naar een vrijgegeven inkooporder

Met deze route bouw je een gecontroleerde AI-inkoopflow: je leest Exact-data, leveranciersvoorwaarden en voorraad, berekent buiten het model een bestelvoorstel, legt de payload vast, laat een bevoegde medewerker vrijgeven en schrijft daarna veilig naar Exact Online. Na afloop kun je iedere order reconstrueren en een time-out afhandelen zonder dubbele bestelling.

Volg deze acht stappen in deze volgorde:

1. Maak van de trigger een controleerbare regel

Schrijf de eerste opdracht als een bedrijfsregel, niet als een open vraag aan een taalmodel:

“Maak een bestelvoorstel wanneer de geprojecteerde voorraad op het verwachte bestelmoment onder het bestelpunt komt. Gebruik alleen actieve leveranciersvoorwaarden en zet ieder voorstel met een ontbrekende bron in de uitzonderingsqueue.”

De rekenkern hoort in code of SQL. Een eenvoudige vorm is:

geprojecteerde voorraad = actuele voorraad + bevestigde ontvangsten - gereserveerde vraag

bestelhoeveelheid = afronden naar verpakkingseenheid(maximale doelvoorraad - geprojecteerde voorraad)

Pas daarna controleer je minimale afname. Als de berekende hoeveelheid 80 is en de leverancier minimaal 120 stuks levert, wordt het voorstel 120. Het model mag uitleggen waarom, maar het mag deze aantallen niet zelf optellen.

Splits de agentactie in kleine gereedschappen:

1. read_purchase_context: haal alleen de toegestane velden op.
2. check_supplier_terms: controleer bron, geldigheid en versie.
3. calculate_order_proposal: voer vaste rekenregels uit.
4. stage_purchase_proposal: maak een onveranderlijk voorstel.
5. release_purchase_order: schrijf alleen een goedgekeurde payload.
6. reconcile_purchase_order: lees de order terug en vergelijk de waarden.
7. replay_purchase_order: controleer eerst of de vorige write al is gelukt.

Maak geen algemene tool met de naam update_exact die willekeurige objecten, velden en aantallen accepteert. Daarmee verschuif je je procesbeleid naar het taalmodel.

2. Lees Exact Online met de divisie en de quota in beeld

Haal eerst de huidige gebruikerscontext op via /api/v1/current/Me en bepaal daarna welke divisie de token mag zien. De REST-referentie vermeldt ook de Divisions-route. Cache die mapping, maar controleer hem periodiek opnieuw. Een testdivisie die toevallig hetzelfde nummer heeft als een productieadministratie is geen betrouwbare configuratie.

Gebruik voor de bronlaag bijvoorbeeld:

• /api/v1/{division}/logistics/StockPosition voor de voorraadpositie;
• /api/v1/{division}/logistics/SupplierItem voor de leverancier-artikelrelatie;
• /api/v1/{division}/purchaseorder/PurchaseOrders voor bestaande inkooporders;
• /api/v1/{division}/purchaseorder/PurchaseOrderLines voor regels, aantallen, prijzen en ontvangsten;
• /api/v1/{division}/sync/PurchaseOrder/PurchaseOrders voor een grotere synchronisatie van gewijzigde orders.

Haal niet iedere keer de hele administratie op. Gebruik selecties, filters op wijzigingsdatum en paginering. Bewaar een high-water mark van de laatste geslaagde run. Praktijkonderzoek naar Exact Online laat zien dat limieten per divisie en per minuut en dag gelden, dat de response headers de resterende ruimte tonen en dat overschrijding HTTP 429 oplevert. Lees die headers en stuur je planning bij. Een eigen teller is slechts een schatting.

Behandel OAuth-vernieuwing als onderdeel van je proces. Sla een nieuw refresh token veilig op voordat je de oude sessie weggooit. Een tokenprobleem dat pas na drie weken wordt ontdekt, maakt je voorraadbeeld stilletjes oud. Zet daarom de laatste geslaagde synchronisatie en de ouderdom van ieder bronrecord in de stagingweergave.

3. Maak één intern voorraad- en prijsbeeld

Exact is je bron, maar je vrijgave heeft een eigen contract nodig. Maak één interne record per voorstel, bijvoorbeeld:

{
  "request_id": "PO-2026-1004-KRAAN-400",
  "division": 123456,
  "warehouse_id": "exact-warehouse-id",
  "supplier_id": "exact-supplier-id",
  "item_id": "exact-item-id",
  "item_code": "KRAAN-400",
  "quantity_in_purchase_units": 140,
  "unit_price": 18.4,
  "currency": "EUR",
  "contract_version": "SUP-047-2026-10",
  "stock_checked_at": "2026-10-04T07:45:00+02:00",
  "terms_checked_at": "2026-10-04T07:46:00+02:00",
  "status": "awaiting_approval",
  "payload_hash": "sha256:..."
}

De namen in dit voorbeeld zijn jouw interne contractvelden. Map ze naar de echte Exact-ID’s voordat je schrijft. Leg bij een prijs altijd vast of het om UnitPrice of NetPrice gaat, welke btw-code geldt en of de prijs per stuk of per inkoopeenheid is. De actuele Exact-documentatie onderscheidt onder meer Quantity, QuantityInPurchaseUnits, UnitPrice en NetPrice. Een agent die die eenheden door elkaar haalt kan een order met een factor tien verkeerd maken.

Controleer minimaal:

• artikel bestaat in de gekozen divisie en hoort bij de leverancier;
• magazijn is actief en past bij de ontvangst;
• valuta en prijsbron zijn geldig;
• prijs is binnen de afgesproken geldigheidsperiode;
• verpakkingseenheid en minimale afname zijn bekend;
• openstaande inkoop wordt niet nogmaals besteld;
• verwachte ontvangstdatum valt binnen de leveranciersbelofte;
• hoeveelheid is positief, afgerond en niet groter dan een ingestelde bovengrens;
• request_id is nog niet eerder vrijgegeven.

Een ontbrekende waarde is geen uitnodiging om te gokken. Zet het voorstel op needs_review met een concrete reden.

4. Laat de agent voorwaarden interpreteren, niet de administratie rekenen

Hier voegt AI wel iets toe. Leveranciersvoorwaarden kunnen als PDF, e-mail of contractnotitie binnenkomen. Laat de agent daaruit alleen een gestructureerd voorstel maken:

{
  "condition": "minimum_order_quantity",
  "value": 120,
  "unit": "purchase_units",
  "valid_from": "2026-09-01",
  "valid_to": "2026-12-31",
  "source_ref": "voorwaardenbestand:SUP-047-2026-10",
  "evidence": "Bestellingen onder 120 stuks worden niet verwerkt.",
  "confidence": "supported"
}

Sla de bronpassage, URL, controledatum en inhoudshash op. Laat de agent twee bronnen als conflict markeren in plaats van één prijs te kiezen. De vaste rekenlaag bepaalt daarna de hoeveelheid.

Gebruik voor de agent een rechtenmatrix:

Dit sluit aan op de eerder uitgewerkte veldrechten, bronregistratie en menselijke vrijgave voor AI-agenten. De CRM-velden heten hier anders, maar de grens is gelijk: read, propose, write en deny zijn procesrechten, geen woorden in een prompt.

5. Stage de exacte payload en vraag menselijke goedkeuring

Een stagingrecord is meer dan een conceptorder. Het is een bevroren besluitvoorstel. Neem minstens op:

• de bron-snapshot en gecontroleerde tijdstippen;
• huidige voorraad, openstaande inkoop en de gebruikte formuleversie;
• leverancier, artikel, magazijn, valuta en hoeveelheid;
• contractversie en bewijsfragment;
• de exacte payload die naar Exact zou gaan;
• request_id, payload_hash, aanmaker, vervaltijd en status;
• wie mag goedkeuren en welke afwijking een tweede controle vraagt.

De beoordelaar moet in één scherm kunnen zien wat verandert. Toon de volledige berekening: voorraad 38, gereserveerd 12, verwachte ontvangst 20, doelvoorraad 180, verpakking 20, minimale afname 120, contractprijs € 18,40, bron gecontroleerd om 07:46 en verwachte ontvangst op 16 oktober.

Gebruik n8n als drager als je een overzichtelijke proefroute wilt. De officiële n8n-documentatie beschrijft een Human Review-stap die de workflow pauzeert, de tool en parameters aan een beoordelaar toont en bij goedkeuring pas uitvoert. Slack kan een melding leveren, maar bewaar besluit, tijdstip, beoordelaar en payloadhash in je staginglaag.

Een afwijzing gaat naar rejected met reden. Geen reactie gaat naar expired of een tweede beoordelaar. Een goedkeuring die na de vervaltijd binnenkomt, is ongeldig. Zo wordt een drukke inbox nooit een stilzwijgende vrijgave.

6. Schrijf pas na een tweede broncontrole naar Exact

De release-uitvoerder leest de stagingrecord opnieuw. Hij voert zelf deze controles uit:

1. status is exact awaiting_approval.
2. De goedkeurder is bevoegd voor deze leverancier, waarde en artikelgroep.
3. De payloadhash is gelijk aan wat de goedkeurder zag.
4. Artikel, leverancier, magazijn, valuta en prijs bestaan nog.
5. Contractprijs en voorwaarden zijn nog geldig.
6. De actuele voorraad en openstaande inkoop wijken niet af buiten jouw afgesproken tolerantie.
7. request_id staat nog niet als geslaagd in je vrijgavetabel.
8. Alleen toegestane header- en regelvelden staan in de write-payload.

Maak daarna één create-request naar PurchaseOrders met de leverancier, headervelden en de geneste verzameling PurchaseOrderLines. De actuele Exact-documentatie voor PurchaseOrders zegt dat een POST een geldige leverancier en orderregels vereist. De pagina voor PurchaseOrderLines vermeldt expliciet dat regels niet individueel mogen worden gepost, ook al bestaat er een apart endpoint voor lezen en muteren. Gebruik geen vrije tekst als vervanging voor een Exact-ID. Bewaar de response, het Exact-order-ID en het leesmoment.

Dezelfde Exact-documentatie noemt OrderStatus 10 voor Open, 20 voor Partial, 30 voor Complete en 40 voor Canceled. Controleer die code na de write, maar behandel de feitelijke status als uitkomst van de administratie: pakket, rechten, ontvangst- en factuurinrichting en workflow kunnen bepalen welke velden je ziet en wanneer een order van status verandert. De documentatie maakt de endpointbeschikbaarheid bovendien afhankelijk van het pakket: Manufacturing, Wholesale & Distribution en bepaalde Professional Services-edities. Test de specifieke POST daarom in een proefdivisie met dezelfde artikel-, btw-, magazijn- en goedkeuringslogica als productie.

Maak het aanmaken van de inkooporder niet automatisch gelijk aan het versturen naar de leverancier. Een order kan eerst intern openstaan. Een leveranciersmail of EDI-bericht is een aparte actie met een eigen vrijgave, zeker als de prijs, hoeveelheid of leverdatum commercieel bindend is.

7. Maak replay veilig voordat je productie raakt

Een time-out na een POST is het gevaarlijkste moment. Je weet niet of Exact de order heeft aangemaakt. Blind opnieuw posten kan een dubbele order maken.

Gebruik daarom een lokale vrijgavetabel met een unieke sleutel op request_id. Leg vóór de write vast dat de sleutel de status approved heeft. Na een time-out zet je de status op unknown en doe je eerst een zoekactie:

• is er in dezelfde divisie een kandidaat met dezelfde YourRef; Exact documenteert YourRef als een referentieveld, niet als een unieke idempotency-sleutel;
• accepteert jouw tenant een OData-zoekactie zoals GET /api/v1/{division}/purchaseorder/PurchaseOrders?$filter=YourRef eq 'PO-2026-1004-KRAAN-400'; zo niet, haal dan een beperkt ordervenster op en filter lokaal;
• bestaat een order-ID in een gedeeltelijke response en bevatten de bijbehorende PurchaseOrderLines dezelfde leverancier, artikel-ID, hoeveelheid en prijs;
• klopt de divisie met de goedgekeurde payload en is de order nog Open, niet geannuleerd of aangepast.

Vind je de juiste order, dan koppel je hem aan de request en sluit je de replay als reconciled. Vind je niets, dan gaat het item terug naar een menselijke controle. Alleen een expliciet goedgekeurde herhaalactie mag nogmaals posten, met hetzelfde request_id en een nieuwe pogingsteller.

Controleer na iedere write de order terug. Vergelijk leverancier, OrderStatus, prijs, hoeveelheid, valuta, ontvangstdatum en de regels. Een HTTP 201 is geen bewijs dat het ERP de order inhoudelijk heeft opgeslagen zoals jij bedoelde.

8. Test uitzonderingen als onderdeel van de eerste proef

Maak geen demonstratie met alleen één nette order. Gebruik een set met:

• verlopen contractprijs;
• ontbrekende leveranciersartikelcode;
• vrije voorraad die tijdens review verandert;
• openstaande inkoop die de voorgestelde hoeveelheid al dekt;
• andere verpakkingseenheid dan de voorraadseenheid;
• valuta die niet overeenkomt;
• twee gelijktijdige triggers voor hetzelfde artikel;
• HTTP 429 tijdens het lezen;
• verlopen OAuth-token;
• time-out na het aanmaken van de header;
• gedeeltelijke ontvangst;
• gewijzigde payload na goedkeuring.

Kijk eerst hoeveel orders doorlopen. Meet ook hoeveel voorstellen naar de uitzonderingsqueue gaan, hoe vaak brondata verouderd is, hoe lang goedkeuring duurt, hoeveel voorstellen worden afgewezen en of er dubbele request_id’s zijn. Een hogere uitzonderingsgraad in de eerste proef kan juist aantonen dat je controle werkt.

Valkuilen: waar de orderflow ontspoort

Je laat AI de hoeveelheid bepalen

Een taalmodel kan een leverancierstekst goed samenvatten en toch 120 met 1.200 verwarren. Mitigatie: laat code de voorraadprojectie, afronding, minimale afname en bovengrens berekenen. AI levert labels, bronnen en een uitleg.

Je geeft één brede Exact-sleutel

Een token met brede schrijfbevoegdheid maakt ieder promptprobleem een ERP-mutatie. Mitigatie: beperk de bronlaag tot lezen en laat één aparte uitvoerder alleen de vaste ordervelden schrijven. Controleer de allowlist server-side.

Je behandelt een contractprijs als een los getal

€ 18,40 zegt niets zonder valuta, eenheid, leverancier en geldigheidsperiode. Mitigatie: sla de prijs als versie op en stuur een conflict naar een mens. Laat een prijs zonder geldigheidsdatum niet automatisch vrijgeven.

Je verwart voorraad met beschikbare voorraad op het ontvangstmoment

InStock is een momentopname. Een ordervoorstel moet ook reserveringen, verwachte ontvangsten en openstaande vraag meenemen. Mitigatie: bereken geprojecteerde voorraad op de leadtime en toon de onderdelen aan de goedkeurder. Dezelfde scheiding tussen patronen herkennen en vaste rekenregels uitvoeren staat ook centraal in de AI-voorraadprognose met Exact Online.

Je laat een order uit iedere melding opnieuw starten

Een webhook, planning en handmatige knop kunnen hetzelfde artikel tegelijk aanbieden. Mitigatie: gebruik een unieke sleutel op divisie, magazijn, artikel en bestelrun. Laat een tweede trigger het bestaande voorstel bijwerken of naar controle sturen.

Je hardcodeert de divisie

Een divisie-ID is geen universele bedrijfsidentifier. Mitigatie: haal toegankelijke divisies op, sla de gekozen administratie expliciet op en toon hem in de goedkeuringskaart.

Je bouwt alleen een minuutlimiet in

Exact kan ook een daglimiet raken. De limietstrategie draait daarom om headers lezen, incrementeel synchroniseren en geplande en interactieve verzoeken uit elkaar houden. Mitigatie: gebruik een wachtrij, prioriteer live vrijgave en verwerk historische data via een aparte synchronisatie.

Je bewaart goedkeuring alleen in Slack

Een bericht kan verdwijnen, worden bewerkt of zonder payload worden doorgestuurd. Mitigatie: Slack is een kanaal voor de melding. Het formele besluit staat in staging met goedkeurder, tijdstip, reden en payloadhash.

Je rekent na goedkeuring opnieuw

Als de agent na de klik opnieuw naar voorraad kijkt en een andere payload vormt, is niet duidelijk wat de mens heeft goedgekeurd. Mitigatie: voer exact de bevroren payload uit. Wijkt de bron af, maak dan een nieuw voorstel.

Je sluit een gedeeltelijke ontvangst te vroeg af

Een inkooporder kan openstaan terwijl een deel al ontvangen is. Mitigatie: vergelijk besteld, ontvangen en resterend. Sluit de order niet omdat één ontvangstbericht is binnengekomen.

Je noemt logging, maar beschermt de log niet

Een audit trail bevat leveranciers, prijzen, adressen en soms financiële gegevens. Mitigatie: beperk toegang, log alleen wat je nodig hebt, stel bewaartermijnen vast en maak een incidentpad. Een logboek is geen vrijplaats voor alle ruwe API-antwoorden.

De veiligheidsreden is niet theoretisch. OWASP noemt excessive agency juist het risico dat een agent te veel functies, rechten of autonomie krijgt en adviseert autorisatie in het doelsysteem af te dwingen. Voor een inkoopflow betekent dat: de agent kan een voorstel maken, maar Exact en jouw vrijgaveservice beslissen samen of een write mag doorgaan. Als een toepassing onder de hoog-risicoregels van de AI Act valt, vraagt artikel 14 bovendien om menselijk toezicht waarmee iemand de uitkomst kan interpreteren, negeren of veilig onderbreken in de geconsolideerde tekst die op 27 juli 2026 is bijgewerkt. Of dat juridische regime op jouw toepassing van toepassing is, moet je afzonderlijk laten beoordelen.

Beslis-kader: native Exact, n8n, Make of maatwerk?

De beste route hangt niet eerst af van het model. Kijk naar het aantal systemen, uitzonderingen, leveranciersregels, ERP’s en mensen die moeten kunnen ingrijpen.

Kies native Exact Online als je één divisie hebt, de bestelregels stabiel zijn, de inkoper in Exact werkt en je vooral een voorstel wilt laten zien. Laat de agent lezen en stage-en. Laat de bevoegde medewerker de order handmatig vrijgeven. Dit is vaak de juiste eerste stap bij een klein volume.

Kies n8n met staging als je Exact, webshop, voorraadbron en meldingen wilt combineren. n8n past goed wanneer je een self-hosted route, code in de flow en één duidelijke wachtrij wilt. De actuele prijsweergave toont op 4 oktober 2026 € 20 per maand bij jaarlijkse betaling voor Starter met 2.500 workflow-uitvoeringen en onbeperkte stappen. Pro toont € 50 per maand bij jaarlijkse betaling voor 10.000 uitvoeringen. De uitvoeringen zijn volledige runs, niet losse stappen. Bewaar je audittrail buiten de korte standaardretentie van de cloudplannen. De n8n-prijspagina bevestigt deze uitvoeringslogica en limieten.

Kies Make als een visuele scenario-editor en veel standaardapplicaties zwaarder wegen dan self-hosting. De actuele prijsweergave toont voor 10.000 credits per maand $ 9 voor Core, $ 16 voor Pro en $ 29 voor Teams. Make telt iedere moduleactie die data leest, schrijft of transformeert als credit; één run kan dus veel duurder uitvallen dan één credit. Dat past bij een overzichtelijke flow, maar maak vooraf een raming van de volledige keten. De officiële Make-prijspagina legt uit hoe credits per moduleactie worden verbruikt.

Kies maatwerk als de release meerdere ERP’s, entiteiten of contracttypes raakt, als je eigen auditlaag nodig hebt of als een onbekende write-uitkomst betrouwbaar moet worden gereconcilieerd. Bouw dan eerst de policy- en staginglaag. Voeg pas daarna de agent en de ERP-adapters toe.

Automatiseer nog niet als je leveranciersvoorwaarden nergens versieerbaar zijn, artikel- en eenheidscodes niet betrouwbaar matchen of niemand bevoegd is om een uitzondering te beslissen. Een agent maakt een ontbrekende proceseigenaar niet zichtbaar genoeg om het probleem op te lossen.

Hoeveel systemen leveren brondata voor één inkoopvoorstel?

Alleen Exact OnlineExact en andere systemen

De keuzehulp geeft hetzelfde advies als het kader erboven. Native is een goede uitkomst wanneer de mens in Exact beslist. n8n of Make past bij een beheersbare tussenlaag. Maatwerk is pas nodig wanneer de beslissing zelf bedrijfslogica wordt.

Uitgewerkt voorbeeld: een gewijzigde voorraad vóór vrijgave

Dit is een synthetisch rekenvoorbeeld, geen klantcase. Stel dat een technische groothandel op 4 oktober 2026 een bestelvoorstel maakt voor artikel KRAAN-400 in magazijn WH-01.

De eerste lezing uit Exact geeft:

• actuele voorraad: 38 stuks;
• gereserveerde vraag: 12 stuks;
• bevestigde inkomende voorraad: 20 stuks;
• bestelpunt: 60 stuks;
• doelvoorraad: 180 stuks;
• verpakkingseenheid: 20 stuks;
• minimale afname bij leverancier SUP-047: 120 stuks;
• geldige contractprijs: € 18,40 per stuk;
• verwachte levertijd: 10 werkdagen.

De rekenlaag maakt de geprojecteerde voorraad:

38 + 20 - 12 = 46 stuks

De voorraad ligt dus 14 stuks onder het bestelpunt. Om de doelvoorraad te bereiken is 134 stuks nodig. Afronden op een verpakkingseenheid maakt 140 stuks. De minimale afname van 120 is lager dan 140 en verandert de uitkomst niet. Het voorstel wordt:

{
  "request_id": "PO-2026-1004-KRAAN-400",
  "supplier": "SUP-047",
  "warehouse": "WH-01",
  "item": "KRAAN-400",
  "quantity": 140,
  "unit_price": 18.4,
  "currency": "EUR",
  "receipt_date": "2026-10-16",
  "status": "awaiting_approval"
}

De agent voegt bronbewijs toe: voorraadcontrole om 07:45, voorwaardencontrole om 07:46, contractversie SUP-047-2026-10 en de uitleg dat de hoeveelheid op 20 stuks is afgerond. Hij maakt geen Exact-order aan.

Om 08:12 komt een nieuwe ontvangstbevestiging binnen. De bevestigde inkomende voorraad stijgt van 20 naar 60 stuks. De release-uitvoerder vergelijkt de actuele snapshot met de stagingrecord en blokkeert de order. Dat is geen fout. Het is precies de controle waarvoor staging bestaat.

De nieuwe berekening is:

38 + 60 - 12 = 86 stuks

De doelvoorraad vraagt nu 94 stuks. Afronden op 20 maakt 100 stuks, maar de minimale afname blijft 120. Het nieuwe voorstel wordt dus 120 stuks, met een totaal van € 2.208 exclusief btw. De oude payload van 140 stuks vervalt. Een mens keurt de nieuwe payload goed.

Daarna doet de release-uitvoerder één create-write en twee controles:

1. Hij post naar PurchaseOrders met de gekozen divisie, leverancier, magazijn, YourRef, ontvangstdatum en de geneste regel met artikel-ID, QuantityInPurchaseUnits=120, eenheid en UnitPrice=18,40.
2. Hij leest de aangemaakte orderheader en de bijbehorende PurchaseOrderLines terug.
3. Hij controleert order-ID, leverancier, OrderStatus=10 voor Open, hoeveelheid, prijs, valuta en ontvangstdatum. Als de tenant een andere workflowstatus teruggeeft of een vereist veld niet beschikbaar is, stopt de release en gaat het voorstel naar handmatige controle.

Stel dat de verbinding na de eerste aanvraag wegvalt. De lokale status wordt unknown. De replaycontrole zoekt eerst naar YourRef=PO-2026-1004-KRAAN-400 in dezelfde divisie en controleert of de gevonden order exact dezelfde regel bevat. Als die order bestaat, wordt geen tweede order gemaakt. Als hij ontbreekt, beslist een bevoegde medewerker of dezelfde goedgekeurde payload opnieuw mag worden aangeboden.

Het eindresultaat is niet “AI bestelde 120 kranen”. Het is: een bronversie, een berekening, een menselijke beslissing, één Exact-order, een terugleescontrole en een aantoonbare reden waarom 140 stuks niet meer zijn vrijgegeven.

Vergelijkingstabel: vier routes naar dezelfde inkooporder

De prijzen en productlimieten in deze tabel zijn gecontroleerd op 4 oktober 2026. Bedragen van leveranciers, bouwtijd, hosting, modelgebruik en beheer vallen buiten de softwareprijs.

Een inkooporder is pas echt geautomatiseerd wanneer de herkomst van ieder getal zichtbaar blijft, een mens de exacte payload kan weigeren en een time-out niet in een dubbele bestelling eindigt. De agent mag het voorbereidende denkwerk versnellen. De grens tussen voorstel en financiële werkelijkheid hoort bij je regels, je ERP en een controleerbare vrijgave te liggen.