AI-agent voor verkooporders in de groothandel: veilige ERP-vrijgave

De order ligt al in de gedeelde inbox. De pdf noemt klantnummer 1048, productcode P-400 en 90 stuks, maar de klantmail vraagt levering vrijdag op een ander adres. Als je die mail rechtstreeks door een AI-agent in je ERP laat zetten, heb je geen automatisering gebouwd. Je hebt een fout met een voorraad- en prijsbelofte geautomatiseerd.

Deze route is voor de verkoop- of operationsmanager van een groothandel die orders uit e-mail, pdf of een portal wil laten voorbereiden en alleen gevalideerd in het ERP wil laten landen. Het onderwerp is verkooporders, dus de klant aan de ene kant van de transactie. De gecontroleerde AI-flow voor inkooporders in Exact Online gaat over leveranciers en bestelvoorstellen. Prijslijsten, herordertriggers en klantcommunicatie gaan over onderhoud en communicatie rond prijzen. Hier ligt de grens vlak vóór de verkooporder: bewijs, match, contractprijs, beschikbare voorraad, leverbelofte, vrijgave en terugleescontrole.

De externe documentatie en productpagina's in deze gids zijn gecontroleerd op 10 oktober 2026. Waar een bron een eigen versie- of updatedatum noemt, neem ik die mee.

Een gecontroleerde verkooporderflow is een proces waarin een orderbron eerst als bewijs wordt bewaard, waarna klant, artikelen, hoeveelheden, contractprijs en leverdatum tegen vaste bronnen worden gecontroleerd. De agent mag tekst uitlezen en een voorstel maken. Alleen een ongewijzigde payload met geldige voorraad, prijs en menselijke goedkeuring mag daarna één ERP-write krijgen.

Wat je nodig hebt: bewijs vóór modeluitvoer

Begin met het record dat je morgen aan een klant, collega of accountant moet kunnen laten zien. Een naam uit een e-mail is geen klantidentiteit en 90 stuks is geen complete orderregel zolang de eenheid, het artikel en de prijsbron ontbreken.

Voor een eerste proef heb je deze bouwstenen nodig:

• Een afgebakend ingangskanaal. Kies één gedeelde mailbox, één uploadmap of één portalformulier. Bewaar het oorspronkelijke bericht, de pdf of de portalpayload onveranderd. Leg afzender, ontvangen tijdstip, bestandsnaam, bericht-ID en een hash vast.
• Een klantregister. Je hebt de ERP-ID van de besteller, het factuuraccount, het afleveraccount, bekende contactpersonen en toegestane afleveradressen nodig. Een domeinmatch of een vergelijkbare bedrijfsnaam mag een kandidaat opleveren, maar niet zelfstandig een klantrecord kiezen.
• Een artikelregister met eenheden. Leg je eigen artikelcode, klantartikelcode, GTIN of barcode, standaardeenheid, omrekenfactor en magazijn vast. 1 pallet en 1 stuk zijn geen varianten van hetzelfde getal.
• Een versieerbare prijsbron. Bewaar klant, artikel, valuta, staffeldrempel, prijs, eenheid, ingangsdatum, einddatum en bronversie. De prijs moet opnieuw uitlegbaar zijn nadat de order is vrijgegeven.
• Een voorraadbeeld voor de beloofde datum. Je hebt vrije voorraad, fysieke voorraad, gereserveerde voorraad, geplande uitgaande bewegingen, bevestigde inkomende bewegingen, magazijn en peiltijd nodig. Kies één formule en tel velden niet dubbel.
• Een staginglaag en uitzonderingsqueue. PostgreSQL, Supabase, een eigen wachtrij of een datalaag in n8n kan het voorstel bewaren. E-mail of Slack kan een melding dragen, maar is niet het formele goedkeuringsrecord.
• Een smalle ERP-schrijfroute. Gebruik beperkte API-rechten, een vaste payload en een aparte uitvoerder. Een agenttool met update_order(anything) is geen controlelaag.
• Een bevoegde orderdesk. Wijs iemand aan die klant-, prijs- en leverafwijkingen beslist. Zet een vervaltijd op ieder voorstel, zodat een goedkeuring van gisteren niet stilletjes op de voorraad van vandaag wordt uitgevoerd.
• Rollen en vaardigheden. Benoem een proceseigenaar/ordermanager met kennis van klant-, prijs- en voorraadbeleid en beslissingsbevoegdheid, een integratie-engineer met Exact Online REST/OAuth, least-privilege, idempotentie, staging, read-back en geautomatiseerd testen, en iemand met document-AI/LLM-vaardigheden voor OCR, schema-extractie, evaluaties en prompt-injectionrisico's. Laat een orderdeskmedewerker de exacte payload goedkeuren; combineer rollen in een kleine pilot alleen als goedkeuring en productie-write gescheiden blijven. NIST beschrijft het vastleggen, trainen en onderscheiden van rollen en menselijke oversight in de AI-lifecycle.
• Budgetorde voor de pilot. Voor één ingangskanaal, één ERP, twee à drie orderformats, een testadministratie, staging, menselijke vrijgave, read-back en overdracht reserveer je als eigen scope-inschatting € 10.000–€ 25.000 eenmalig, exclusief btw, plus € 100–€ 500 per maand voor workflow, opslag, OCR/LLM, monitoring en support. Dit is geen offerte en sluit ERP-licenties, datamigratie en uitzonderlijk maatwerk uit. De bandbreedte veronderstelt ongeveer 80–160 implementatie-uren; het in 2026 gepubliceerde gemiddelde van € 94 per uur voor een Nederlandse zzp-softwaredeveloper is alleen een referentiepunt, geen tariefbelofte. Knab publiceerde dat gemiddelde op 1 juli 2026.

Voor pdf's en scans kun je Azure AI Document Intelligence gebruiken als uitleeslaag. De actuele modeldocumentatie, gecontroleerd op 10 oktober 2026, beschrijft voor versie 4.0 Layout voor tekst, tabellen en koppen en custom extraction voor eigen formulieren. Pdf, afbeeldingen en Office-bestanden worden ondersteund; een custom model kan met vijf voorbeelden van hetzelfde formuliertype beginnen. Dat maakt het geschikt om velden en bewijsposities te vinden, niet om te beslissen of een order commercieel klopt. De Microsoft-documentatie beschrijft die scheiding tussen layout, custom extraction en ondersteunde invoer.

Als een klant al een gestructureerd portal of GS1 EDI-bericht aanlevert, begin dan niet met een taalmodel. Een vaste ordermapping is daar meestal betrouwbaarder. GS1 EDI definieert machineleesbare berichten voor order, levering en financiële afhandeling. De GS1-standaard beschrijft EDI als een raamwerk voor geautomatiseerde zakelijke berichten in de hele toeleveringsketen.

De checklist is geen administratieve voorwaarde achteraf. Zonder deze gegevens kan een model een keurige ordervorm invullen, terwijl de orderdesk niet kan uitleggen waarom deze klant, dit artikel of deze leverdatum is gekozen.

Concrete stappen: van binnenkomende order naar gecontroleerde vrijgave

Met onderstaande route bouw je eerst een bewijsrecord en pas daarna een gecontroleerd ordervoorstel. De agent leest en structureert. De vaste regels rekenen. De menselijke vrijgave gaat over de exacte payload. De tweede broncontrole bepaalt of het voorstel nog geldig is.

Werk deze acht stappen in volgorde af:

1. Leg de intake en dubbele orders vast

Maak per binnenkomende order een request_id, bijvoorbeeld SO-2026-1010-8742. Combineer die sleutel met bronsoort, bericht-ID, portalinzending of een hash van het oorspronkelijke bestand. Bewaar de bron zelf in alleen-lezen opslag. Een pdf die later opnieuw wordt geüpload, herken je aan de hash; een reply op hetzelfde bericht herken je aan de bericht-ID en de nieuwe versie.

Zet de eerste route op received, extracted, needs_review, staged, approved, written, reconciled of rejected. Een status is geen tekstlabel in een prompt, maar een overgang die de uitvoerder server-side controleert. Een tweede trigger mag geen nieuw voorstel maken zolang hetzelfde verzoek nog openstaat.

Behandel EDI en een ingelogd portal anders dan een vrije e-mail. Bij EDI is de zender en het berichttype al onderdeel van de afgesproken koppeling. Bij e-mail blijft de afzender een aanwijzing totdat je hem aan een bestaand klantrecord en een bekende ordercontext hebt gekoppeld.

2. Zet de bron om in een getypt orderconcept

Laat OCR of document-AI eerst tekst, tabellen en posities uitlezen. Laat een taalmodel daarna alleen een vast schema vullen en onbekende waarden expliciet markeren. Een confidence-score is een reden om te kijken, geen toestemming om te schrijven.

Een bruikbaar intern schema bevat minstens:

{
  "request_id": "SO-2026-1010-8742",
  "source": {"type": "email_pdf", "message_id": "<...>", "sha256": "..."},
  "customer_claimed": "1048",
  "delivery_address_claimed": "Industrieweg 12, Utrecht",
  "requested_delivery_date": "2026-10-14",
  "lines": [
    {"customer_item_code": "P-400", "description": "Kraan 400", "quantity": 90, "unit": "stuk"}
  ],
  "evidence": {"quantity": "pagina 1, regel 7", "date": "pagina 1, regel 3"}
}

Normaliseer getallen en datums, maar verander de bron niet. Bewaar de tekstpassage of coördinaten waarmee een medewerker de waarde kan terugvinden. Een handgeschreven 1.200 mag niet stil worden omgezet naar 1200 als de taal, eenheid of lay-out daar twijfel over geeft. Zet hem naar de queue met ambiguous_number.

3. Bewijs de klant en de afleverrelatie

Match de besteller in deze volgorde:

1. een exact klantnummer of portalklant-ID uit de bron;
2. een geauthenticeerde portalrelatie of een bekende contactpersoon;
3. een afleveradres dat als actief adres bij het account staat;
4. factuuraccount en afleveraccount die samen een geldige relatie vormen.

Een afzenderdomein, bedrijfsnaam of oud ordernummer mag een kandidaat versterken, maar is geen zelfstandig bewijs. Laat je ERP de blokkades en mandaten teruggeven: een klant op kredietstop, een geblokkeerd afleveradres of een account zonder verkooptoestemming hoort niet in de groene zone.

Gebruik in Exact Online voor de uiteindelijke header de juiste relaties OrderedBy, InvoiceTo en DeliverTo. De actuele REST-documentatie maakt OrderedBy verplicht voor een nieuwe verkooporder en vermeldt dat bestaande klantrelaties niet vrij kunnen worden gewijzigd. De Exact-documentatie over SalesOrders beschrijft deze relaties, de afleverdatum, valuta, klantreferentie YourRef en de approval-status.

4. Match ieder artikel en iedere eenheid

Maak per regel één kandidaatkeuze. Zoek eerst op een exact klantartikelnummer, GTIN of intern artikel-ID. Gebruik omschrijving en semantische overeenkomst alleen om kandidaten te tonen. Een agent mag P-400 aan drie mogelijke artikelen koppelen, maar mag er niet zelf één kiezen omdat de omschrijving ongeveer klopt.

Controleer daarna:

• standaardeenheid en verkoopeenheid;
• omrekenfactor tussen doos, stuk, pallet of meter;
• artikelstatus en eventuele vervanger;
• magazijn en verkoopkanaal;
• positieve hoeveelheid en toegestane decimalen.

In Exact Online kun je de uitkomst mappen naar Item, Quantity, UnitCode, CustomerItemCode en UnitPrice op de verkooporderregel. De regel bevat ook DeliveryDate, Pricelist, NetPrice en DeliveryStatus. Gebruik de echte ERP-ID's in de payload, niet alleen de tekst die uit de pdf kwam.

5. Bereken de contractprijs buiten het taalmodel

Een contractprijs is een versieerbare beslissing. Controleer klant, artikel, gevraagde hoeveelheid, prijs-eenheid, valuta en orderdatum tegen de actieve bron. Neem staffeldrempels mee. Als de klant 90 stuks vraagt, mag je niet de prijs voor 100 stuks kiezen omdat dat gunstiger lijkt.

Exact Online heeft hiervoor de SalesItemPrices-bron. De actuele documentatie noemt een klantaccount, valuta, start- en einddatum, prijs, eenheid, omrekenfactor en minimale hoeveelheid. De bron kan dus klant- en periodegebonden zijn. De Exact-documentatie over SalesItemPrices beschrijft deze klant-, datum- en staffelvelden.

Leg in staging vast: price_source_id, price_source_version, price_checked_at, currency, unit, minimum_quantity en het bewijs waarom deze regel is gekozen. Als de pdf € 17,90 noemt en de geldige klantprijs € 18,40 is, laat je de orderdesk beslissen. De agent mag het verschil signaleren, niet gladstrijken.

De berekening blijft deterministisch. Korting, btw, valutaomrekening, toeslag en afronding horen in code of in de prijsfunctie van je ERP. De agent kan de uitkomst uitleggen in gewone taal.

6. Beloof alleen wat je voorraadmodel kan dragen

Gebruik niet het veld InStock als synoniem voor leverbaar. Exact Online maakt in zijn StockPosition-functie onderscheid tussen FreeStock, InStock, PlanningIn, PlanningOut, ProjectedStock en ReservedStock. FreeStock is de hoeveelheid beschikbare voorraad; ReservedStock is voorraad die al is toegezegd. De actuele Exact-documentatie over StockPosition benoemt deze velden en de functie-URI per divisie.

Kies één van deze twee rekenroutes en documenteer hem:

beschikbaar nu = vrije voorraad

beschikbaar op datum = vrije voorraad + bevestigde inkomende voorraad vóór de datum - geplande uitgaande bewegingen vóór de datum - veiligheidsbuffer

Of gebruik een door het ERP berekende projectiestand. Tel dan niet nogmaals alle geplande bewegingen bij ProjectedStock op. Dat is de klassieke dubbele telling.

Controleer ook de leverlogica. Een order met twee regels kan één regel op voorraad hebben en één regel pas over drie weken. Splitsen, backorderen of een andere locatie kiezen zijn commerciële keuzes. Zet die naar de orderdesk tenzij je beleid ze expliciet toestaat. Geef nooit een concrete datum terug omdat de klant daarom vraagt; de datum moet uit magazijnkalender, verwerkingstijd en voorraadbewijs volgen.

7. Stage de payload en definieer de groene zone

Een stagingrecord is een bevroren voorstel, geen vriendelijke samenvatting. Sla minimaal op:

De groene zone is een beleidsgrens, geen modelscore. Een voorstel komt er alleen in als alle onderstaande voorwaarden waar zijn:

• precies één klant, één afleverrelatie en één kandidaat per orderregel;
• bron, artikel, hoeveelheid en eenheid zijn volledig en herleidbaar;
• contractprijs en valuta zijn actief op de orderdatum;
• beschikbare voorraad en leverdatum voldoen aan de afgesproken buffer;
• geen krediet-, artikel-, adres- of mandaatblokkade;
• geen openstaand identiek request_id of dubbele bron;
• totaal en korting blijven binnen de autorisatiegrens;
• de laatste broncontrole is jonger dan de ingestelde vervaltijd.

Alles daarbuiten gaat naar de uitzonderingsqueue. Gebruik vaste redencodes zoals customer_ambiguous, item_ambiguous, price_expired, price_mismatch, insufficient_available_stock, delivery_date_unverifiable, duplicate_candidate en source_stale. Toon de medewerker de bronpassage, de kandidaat, de gebruikte ERP-velden, de berekening en één concrete vervolgstap. Een queue waarin alleen "AI confidence low" staat, schuift het werk gewoon door.

8. Laat een mens goedkeuren, schrijf één keer en lees terug

De orderdesk moet de originele bron naast het genormaliseerde voorstel kunnen openen. Toon klant, afleveradres, iedere regel, eenheidsfactor, prijsbron, voorraadpeiltijd, leverdatum, totaal, afwijkingen en de exacte payload. Een klik op goedkeuren bind je aan actor, tool, doelrecord, genormaliseerde parameters, payloadhash, tijdstip en vervaltijd.

De release-uitvoerder doet daarna opnieuw de controles. Hij weigert de write als de klant, prijs, voorraad, leverdatum of payloadhash is veranderd. Hij maakt dan een nieuw voorstel. Hij rekent niet stil opnieuw met andere waarden na de goedkeuring.

Voor Exact Online betekent dit een POST naar salesorder/SalesOrders met de verplichte klantrelatie en de geneste SalesOrderLines. De REST-referentie ondersteunt GET, POST, PUT en DELETE, maar schrijft voor dat de regels bij een POST als SalesOrderLines worden meegegeven. De endpoint is beschikbaar voor Wholesale & Distribution en Manufacturing. Laat ApprovalStatus aansluiten op je ERP-inrichting: 0 is awaiting approval, 1 automatisch en 2 approved. Zet niet blind 2 omdat iemand jouw stagingrecord heeft goedgekeurd; dat vereist in Exact de juiste SalesOrderApproval-rechten en moet onderdeel zijn van je beleid.

Lees na de write de orderheader en alle regels terug. Vergelijk minimaal ERP-order-ID, klant, afleveradres, valuta, orderdatum, leverdatum, artikel-ID, hoeveelheid, eenheid, prijs, prijsbron en orderstatus. Een succesvolle HTTP-response bewijst niet dat je order inhoudelijk overeenkomt met wat de medewerker zag.

Bij een time-out zet je de status op unknown. Zoek eerst naar een order met dezelfde klantreferentie en controleer daarna klant, datum, regels, hoeveelheid en prijs. Gebruik YourRef als correlatie, niet als enige idempotentiegarantie. Vind je een exacte match, koppel je die aan het stagingrecord en maak je geen tweede order. Vind je geen match, dan beslist een bevoegde medewerker of dezelfde payload opnieuw mag worden aangeboden.

Valkuilen: waar de verkooporder ontspoort

Een hoge uitleesscore wordt een vrijgave

OCR of een taalmodel kan een tabel goed lezen en toch een verkeerde eenheid of klantregel kiezen. Mitigatie: gebruik bewijsposities, schema-validatie en een unieke match tegen je registers. Confidence bepaalt hooguit de route naar controle.

De afzender wordt als klantidentiteit gebruikt

Een doorgestuurde mail, een gedeeld verkoopadres of een lookalike domein kan de verkeerde accountkeuze veroorzaken. Mitigatie: combineer klantnummer of geauthenticeerde portalrelatie met contact en afleveradres. Geen unieke match betekent queue.

De agent kiest de gunstigste prijs

Een prijs uit een oude pdf, een staffel voor een andere hoeveelheid of een korting zonder geldigheid kan de marge wegdrukken. Mitigatie: lees de actieve prijsbron opnieuw, bewaar versie en valuta, en laat prijsconflicten door de orderdesk beslissen.

Vrije voorraad wordt verward met fysieke voorraad

Fysiek aanwezige voorraad kan al aan een andere klant zijn toegezegd. Mitigatie: toon vrije, gereserveerde en geplande voorraad afzonderlijk en leg vast welke waarde je leverbelofte draagt.

De leverdatum wordt een standaardtekst

Een orderbevestiging met "levering vrijdag" is een commerciële belofte. Mitigatie: bereken de datum met magazijn, verwerkingstijd, reserveringen, bevestigde ontvangst en veiligheidsbuffer. Kan je model geen bewijs leveren, stuur dan geen datum.

Een brede ERP-tool maakt de agent almachtig

Een agent die dezelfde sleutel kan lezen, wijzigen, goedkeuren en mailen heeft geen controlegrens meer. Mitigatie: scheid uitlezen, voorstellen, vrijgave en schrijven in verschillende functies en autorisaties. OWASP adviseert voor ingrijpende acties een aparte validatie van scope, bevoegdheid en approval state, plus binding van goedkeuring aan de exacte parameters en replay-bescherming. De OWASP AI Agent Security Cheat Sheet werkt deze controles uit voor financiële en extern zichtbare acties.

De voorraad is veranderd na goedkeuring

Een voorstel van 09:00 kan om 09:15 al geen leverbelofte meer dragen. Mitigatie: zet een vervaltijd en doe vlak vóór de write een tweede broncontrole. Bij drift maak je een nieuw voorstel.

Een time-out wordt een dubbele order

Na een onbekende API-uitkomst is opnieuw posten geen herstelstrategie. Mitigatie: sla request_id en payloadhash op vóór de write, zoek eerst naar een bestaande exacte order en laat alleen een bevoegde herhaling toe.

De uitzonderingsqueue wordt een rommellade

Als iedere afwijking dezelfde status krijgt, weet niemand welke order eerst moet. Mitigatie: gebruik reden- en prioriteitscodes, wijs een eigenaar toe, toon het bewijs en meet ouderdom, doorlooptijd, afwijzing en terugkerende oorzaken.

Een orderbevestiging vertrekt vóór de terugleescontrole

Dan beloof je de klant een order die misschien niet in het ERP staat of anders is opgeslagen. Mitigatie: verstuur pas na een geslaagde read-back en registreer welke ERP-order de bevestiging draagt.

Beslis-kader: native, workflowtool of maatwerk?

De keuze gaat minder over het beste taalmodel dan over de stabiliteit van je orderbron, het aantal systemen en de prijs van een verkeerde leverbelofte. Productdetails en prijzen hieronder zijn gecontroleerd op 10 oktober 2026.

Kies een directe EDI- of portal-koppeling als de klant al vaste ID's, een afgesproken berichtformaat en een betrouwbare authenticatie aanlevert. Een deterministische mapping is dan beter dan documentinterpretatie. Gebruik AI alleen voor uitzonderingen of voor het orderdesk-scherm.

Kies native ERP met een eigen stagingrecord als je één ERP, één magazijn en stabiele klant- en prijsregels hebt. De orderdesk kan de voorstellen in of naast het ERP vrijgeven. Dit is de beste start als het aantal uitzonderingen klein is en een extra workflowtool meer beheer dan voordeel oplevert.

Kies n8n met staging als je mailbox, documentuitlezing, ERP, meldingen en een eigen wachtrij wilt verbinden. De officiële n8n-documentatie biedt Human-in-the-loop voor afzonderlijke tools: de workflow pauzeert, toont tool en parameters, en voert pas na approve uit. De actuele cloudprijzen zijn € 20 per maand voor Starter met 2.500 volledige workflow-uitvoeringen en € 50 per maand voor Pro met 10.000 uitvoeringen, beide bij jaarlijkse betaling. n8n rekent per volledige uitvoering, met onbeperkte stappen; die waarden zijn gecontroleerd op 10 oktober 2026. De n8n-documentatie beschrijft de goedkeuringsstap en de beschikbare kanalen. De actuele n8n-prijspagina vermeldt de uitvoeringslimieten en prijzen.

Kies Make met staging als je vooral een visuele scenario-editor en veel standaardapps nodig hebt. Op de actuele prijspagina kosten 10.000 credits per maand bij maandbetaling $ 12 voor Core, $ 21 voor Pro en $ 38 voor Teams. Iedere moduleactie, zoals een Gmail-lezing of een databasebewerking, verbruikt een credit. Reken dus de volledige orderroute door, niet alleen het aantal binnenkomende orders. Deze waarden zijn gecontroleerd op 10 oktober 2026. Make legt de credit-eenheid en de actuele planprijzen uit op de prijspagina.

Kies maatwerk als meerdere ERP's, entiteiten, prijscontracten, magazijnen of afleverregels samenkomen, of als je eigen auditlaag, replayservice en bevoegdheden nodig hebt. Bouw eerst policy, staging en read-back. Voeg pas daarna de agent toe. Een agent maakt complexe bedrijfsregels niet eenvoudiger; hij maakt ze sneller zichtbaar.

Automatiseer nog niet als klant- en artikelcodes niet betrouwbaar zijn, contractprijzen geen geldigheidsperiode hebben of niemand de uitzonderingsqueue mag beslissen. Dan is de juiste eerste stap datamodel en procesbeheer, niet een duurder model.

De keuzehulp is dezelfde beslissing in compacte vorm. Vaste EDI- of portaldata vraagt een directe koppeling. Wisselende e-mail en pdf's passen bij n8n of Make zolang de regels beheersbaar blijven. Hoge financiële of operationele impact, meerdere policies en meerdere ERP's rechtvaardigen maatwerk.

Uitgewerkt voorbeeld: een order die eerst groen lijkt

Dit is een synthetisch rekenvoorbeeld, geen klantcase. Stel dat een technische groothandel op 10 oktober 2026 een pdf-order ontvangt van klantrecord AC-1048. De pdf noemt klantartikel P-400, 90 stuks, levering op 14 oktober en afleveradres Industrieweg 12, Utrecht.

Stap 1, bron. De intake bewaart de e-mail, pdf, bericht-ID en hash en maakt SO-2026-1010-8742. Hetzelfde pdf-bestand dat later nogmaals wordt doorgestuurd, wordt als mogelijke duplicaatbron gemarkeerd.

Stap 2, uitlezen. Document Intelligence haalt klantnummer, klantartikel, hoeveelheid en datum uit de pdf. Het orderconcept bevat bewijsposities voor de 90 en de leverdatum. Geen van die waarden is al een ERP-mutatie.

Stap 3, klant. Klantnummer AC-1048 vindt precies één actief account. De afzender staat als contactpersoon bij dat account en het afleveradres is actief. OrderedBy, InvoiceTo en DeliverTo worden gevuld met ERP-ID's. Een ander adres in de mail zou de order uit de groene zone halen.

Stap 4, artikel. P-400 is de klantartikelcode voor intern item KRAAN-400. De eenheid is stuk en de omrekenfactor is 1. Er is geen tweede kandidaat.

Stap 5, prijs. De klantprijs is € 18,40 per stuk, in EUR, geldig van 1 oktober tot en met 31 december 2026 en actief vanaf een minimumhoeveelheid van 50. De bron is de klantgebonden SalesItemPrices-regel. De orderwaarde vóór btw is 90 × € 18,40 = € 1.656,00. De pdf noemt geen afwijkende korting.

Stap 6, voorraad. De testlezing uit StockPosition geeft InStock=300, ReservedStock=140 en FreeStock=160. Voor 14 oktober staat PlanningOut=40 gepland. De policy reserveert 20 stuks als buffer. De beschikbare hoeveelheid voor deze belofte is daarom:

160 - 40 - 20 = 100 stuks

De gevraagde 90 stuks passen binnen de groene zone. ProjectedStock wordt niet nogmaals opgeteld, omdat de geplande beweging al in deze berekening zit.

Stap 7, staging. Het voorstel bevat de exacte header, de ene regel, de prijsbron, de voorraadvelden, de berekening, een payloadhash en de status awaiting_approval. De orderdesk ziet de pdf naast de ERP-waarden. Hij keurt precies deze payload goed.

Stap 8, tweede controle. Vlak vóór de write leest de release-uitvoerder klant, prijs en voorraad opnieuw. Als FreeStock inmiddels 110 is geworden door een andere reservering, wordt de berekening 110 - 40 - 20 = 50. De order past dan niet meer en gaat naar insufficient_available_stock. De oude goedkeuring blijft niet geldig.

Stap 9, ERP-write en read-back. Als de tweede controle gelijk blijft, maakt de uitvoerder één verkooporder aan met OrderedBy, InvoiceTo, DeliverTo, DeliveryDate, Currency, YourRef en de geneste regel voor KRAAN-400, hoeveelheid 90, eenheid stuk en prijs € 18,40. Daarna leest hij header en regels terug. Pas als klant, regel, prijs, datum en status kloppen, wordt de orderbevestiging verstuurd.

Als de verbinding na het aanmaken wegvalt, blijft de lokale status unknown. De uitvoerder zoekt in dezelfde divisie naar de correlatie SO-2026-1010-8742 en controleert de volledige combinatie van klant, datum, artikel, hoeveelheid en prijs. Een gevonden exacte order wordt gekoppeld. Zonder match volgt menselijke controle. Er komt nooit automatisch een tweede verkooporder.

Het interessante resultaat is niet dat een model 90 stuks heeft herkend. Het resultaat is dat de orderdesk kan aanwijzen welke bron, welke klantrelatie, welke prijsregel, welke voorraadstand en welke goedkeuring samen de ERP-order vormen.

Vergelijkingstabel: vijf routes voor dezelfde sales-order-intake

Valkuilen bij de keuze

Kant-en-klaar is verstandig als je vooral een mailbox, één ERP en een eenvoudig approvalpad hebt. Het wordt krap wanneer uitzonderingen de kern van je orderproces zijn. Maatwerk is dan niet automatisch beter, maar het maakt je beleid expliciet: welke klant mag bestellen, welke prijs geldt, wat is leverbaar, wie keurt goed en wat gebeurt er bij een onbekende write.

Kies n8n of Make niet op basis van de maandprijs alleen. Een workflow met drie bronlezingen, documentuitlezing, een prijscontrole, voorraadcontrole, approval, ERP-write en read-back heeft meer stappen dan de naam "één order" doet vermoeden. Tel bij Make credits per moduleactie. Tel bij n8n volledige uitvoeringen, maar begroot opslag, monitoring en eventuele self-hosting apart.

Kies ook geen AI omdat de orders uit pdf komen. Als de pdf altijd hetzelfde formulier heeft, is een vaste extractor of custom model genoeg. AI wordt interessant wanneer je verschillende formulieren, vrije e-mails en uitzonderingen moet structureren. De vrijgavebeslissing blijft dan nog steeds een beleidstaak.

Tot slot

Een verkooporder is niet veilig omdat een model de tekst goed heeft gelezen. Hij is veilig wanneer klantidentiteit, artikelidentiteit, contractprijs, beschikbare voorraad, leverdatum en menselijke toestemming op exact dezelfde payload wijzen. De groene zone mag daarom klein zijn. Een goede uitzonderingsqueue is geen mislukking, maar het bewijs dat onduidelijkheid niet stil in je ERP verdwijnt.