Kort antwoord
Ja. Een AI-laag leest de bestelling uit de mailtekst, de pdf of de Excel-bijlage, zoekt klant, artikel en prijsafspraak op in je ERP en zet er een conceptorder van klaar die je binnendienst met één klik bevestigt. Het lezen is het makkelijke deel; of het werkt, hangt af van twee dingen: het matchen op de artikelnummers en prijsafspraken van je klant, en een mailboxkoppeling die precies één mailbox mag lezen. Stuurt je afnemer EDI, dan heb je deze route niet nodig.
Van lezen naar doen.
Business Center Altena / HVS Trading (Henk Verhoeven)Multi-tenant Huurdersportaal met IoT-energiemonitoringIoT + AIgeautomatiseerd meterstanden aflezen

Komt er een bestelling per mail binnen, dan heeft je binnendienst drie vensters naast elkaar open: de mail, de pdf en het orderscherm in je ERP. Daarna volgt regel voor regel overtypen.
Die pdf uitlezen kan een taalmodel inmiddels goed. Orderprojecten lopen dan ook zelden stuk op het lezen, maar op drie andere plekken:
- Wat de klant bedoelt: zijn eigen artikelnummer, zijn eenheid (doos of stuk), zijn "zelfde als vorige week"
- Welke prijs geldt: de prijs in de mail, of de afspraak in je ERP
- Hoe je erbij komt: een koppeling die de bestelmailbox leest, zonder bij de rest van je mail te kunnen
Deze pagina gaat over die drie, voor een groothandel of distributeur die nu orders overtypt uit de mail. Voor een productiebedrijf dat inkooporders van klanten krijgt, werkt het net zo.
Zo gaat een order van de mail naar je ERP
Het proces heeft vijf stappen. Alleen de tweede is "AI" in de zin waarin leveranciers het verkopen.
- Binnenkomst. De bestelling komt binnen in één gedeelde mailbox, bijvoorbeeld orders@. De koppeling krijgt een melding zodra er iets nieuws staat; Microsoft Graph ondersteunt daarvoor meldingen bij wijzigingen en het ophalen van alleen nieuwe berichten.
- Lezen. Het model leest de mailtekst én elke bijlage: pdf, Excel, soms een foto. Het haalt eruit wie bestelt, welke regels, welke aantallen, welke leverdatum en welke referentie van de klant.
- Matchen. De klant herken je aan het afzenderadres en het debiteurnummer in de pdf. Elk artikel zoek je op in je eigen artikelbestand, via het nummer dat déze klant gebruikt. Daar zit het meeste werk.
- Controleren. Elke regel wordt getoetst aan wat je al weet: de prijsafspraak met die klant, de verpakkingseenheid, de voorraad en of hetzelfde ordernummer al eerder binnenkwam.
- Wegschrijven en bevestigen. De order gaat als concept je ERP of WMS in. Iemand van de binnendienst ziet de mail en de conceptorder naast elkaar, bevestigt de groene regels en lost alleen de gemarkeerde op.
Stap 3 en 4 zijn geen AI-werk maar gewone software op jouw data. Dat is de reden dat een losse tool die "pdf naar Excel" doet je binnendienst weinig scheelt: het overtypen verschuift alleen naar het opzoeken.
Per orderbron: waar het misgaat en wat wij inbouwen
Een pdf uit het ERP van je klant faalt op een andere plek dan een doorgestuurde mail of een foto van een bestelbon. Daarom beginnen we elk ordertraject met deze eigen indeling van de orderbronnen binnen het mailkanaal.
| Orderbron | Wat AI moet herkennen | Waar het misgaat | Wat wij inbouwen |
|---|---|---|---|
| Pdf uit het ERP van de klant | Inkoopordernummer, regels, aantallen, leverdatum, afleveradres | Het artikelnummer is dat van de klant, niet het jouwe | Een vertaaltabel klantartikel naar eigen artikel, die zich vult bij elke bevestiging |
| Vrije mailtekst ("graag weer 4 doos van de 16 mm") | Artikel uit een omschrijving, verwijzing naar een eerdere order | "Weer" of "zelfde als vorige keer" zonder ordernummer | Opzoeken in de orderhistorie van die klant; bij twijfel voorstel met de laatste drie orders |
| Excel-bestellijst | Kolommen die per klant anders heten, soms meerdere tabbladen | Lege regels, subtotalen en een aantal in de prijskolom | Per klant een vastgelegde kolomindeling die het model eerst controleert |
| Gescande of gefotografeerde bestelbon | Handschrift, stempels, doorgehaalde regels | Een 1 die een 7 is; een doorgehaalde regel die toch meetelt | Zekerheid per regel; alles onder de drempel gaat naar een mens |
| Doorgestuurde mail van een vertegenwoordiger | De echte klant onder "Fwd:", niet de afzender | De order wordt op de vertegenwoordiger geboekt | Klant bepalen uit de inhoud en het debiteurnummer, niet uit het afzenderadres |
| Wijziging of annulering | Dat het geen nieuwe order is, en op welke order het slaat | Een tweede order naast de eerste in plaats van een aanpassing | Herkennen als mutatie en altijd naar een mens, nooit automatisch |
| Eén mail, meerdere bijlagen | Welke bijlage de order is: pdf, leveringsvoorwaarden, tekening | De algemene voorwaarden van de klant worden als order gelezen | Per bijlage eerst bepalen wat het is, dan pas uitlezen |
Een losse pdf-lezer dekt alleen de tweede kolom. Of je binnendienst het systeem gaat vertrouwen, hangt af van de laatste.
Klantartikelnummers en prijsafspraken: het eigenlijke werk
Stel: een klant bestelt "art. 4471-B", en bij jou heet dat artikel 30120. Een taalmodel kan dat niet raden, en moet dat ook niet proberen.
Wat wel werkt, is een vertaaltabel per klant die zich vult tijdens het werk. Bij de eerste orders stelt het systeem een match voor op omschrijving en maat, de binnendienst bevestigt, en daarna staat de vertaling vast.
Heeft je ERP al een veld voor het artikelnummer van de klant, dan vullen we dat in plaats van een eigen tabel bij te houden.
Hetzelfde geldt voor eenheden: "4 doos" is bij het ene artikel 4 x 50 stuks en bij het andere 4 x 12. Dat staat in je artikelbestand, niet in de mail.
De prijs in de mail is een signaal, geen opdracht. Noemt de klant een prijs, dan vergelijken we die met de afspraak in je ERP.
Klopt hij, dan is dat een extra bevestiging. Wijkt hij af, dan komt de regel bij een mens, met beide bedragen ernaast.
Waarom zo streng? Omdat een groothandel zijn marge in de prijsafspraak heeft zitten: staffels, projectprijzen, jaarafspraken.
Hoe die afspraken in de groothandel werken en waar een pakket daarin stopt, staat in groothandel software: pakket, ERP of maatwerk.
Wat je IT moet regelen: toegang tot één mailbox
Hier stranden projecten die technisch al af zijn. Een app die zonder ingelogde gebruiker een mailbox leest, heeft in Microsoft 365 een applicatierecht nodig.
Geef je dat recht op de gewone manier in Entra ID, dan geldt het voor alle mailboxen in je organisatie.
Microsoft heeft daar een oplossing voor: RBAC for Applications in Exchange Online. Daarmee koppel je het recht aan een afgebakende groep mailboxen, in ons geval precies één; Microsoft noemt het zelf de vervanger van de oudere Application Access Policies.
Twee details uit die documentatie die in de praktijk het verschil maken:
- Rechten tellen bij elkaar op. Heeft de app ook nog
Mail.Readin Entra ID, dan is de beperking tot één mailbox zinloos. Dat recht moet daar weg. - Een wijziging is niet meteen actief. Microsoft noemt een cache van 30 minuten tot 2 uur; de testopdracht
Test-ServicePrincipalAuthorizationlaat direct zien of een mailbox binnen het bereik valt.
Onze checklist voor de mailboxkoppeling
Dit is de volgorde die wij aanhouden. Als Microsoft-partner vragen we via een partnerrelatie (GDAP) om goedkeuring en richten we het daarna zelf in, zonder ooit Global Admin te vragen; je IT-partner hoeft dan niets te doen.
- Kijk waar de orders echt binnenkomen. Met een message trace over tien dagen: alleen afzender, ontvanger en onderwerp, nooit de inhoud.
- Controleer of orders@ een eigen mailbox is of een alias. Is het een alias van info@, dan raakt een bereik op orders@ niets, en geeft een bereik op de onderliggende mailbox de app toegang tot heel info@.
- Kies tussen lezen en lezen-en-schrijven.
Mail.Readis genoeg om te lezen. Moet de app verwerkte mail naar een map verplaatsen, dan is hetMail.ReadWrite; dat recht kan geen mail versturen. - Zet een gemengde mailbox nooit zomaar open. Onze koppeling verplaatst elke mail die hij verwerkt naar een map. Komt er in die mailbox ook andere post binnen, dan maken we een aparte gedeelde mailbox met een transportregel die alleen de ordermail doorzet.
- Geen
Mail.*-rechten bij API permissions in Entra. Het recht staat uitsluitend in Exchange, met het bereik op die ene mailbox. - Test het bereik met
Test-ServicePrincipalAuthorizationop de ordermailbox (InScope = True) én op een andere mailbox (InScope = False). - Leg de vervaldatum van het geheim vast. Wij geven het een looptijd van 24 maanden en zetten die datum in de projectdocumentatie; vergeet je hem, dan stopt de koppeling zonder waarschuwing.
Nog één technische valkuil voor wie het zelf bouwt: Microsoft waarschuwt dat het ID van een bericht kan veranderen na kopiëren of verplaatsen. Verplaats je verwerkte orders naar een map, gebruik dan onveranderlijke ID's, anders verlies je de koppeling tussen mail en order.
Dat de app maar één mailbox kan lezen, is ook voor je privacy een argument: de rest van je mail, met personeels- en klantzaken, blijft buiten bereik. Hoe je het taalmodel zelf binnen de EER houdt, lees je in AI met je bedrijfsdata binnen de EER.
Hoe de order in Exact Online of Picqer landt
Het wegschrijven verschilt per pakket. Twee voorbeelden:
Exact Online. De order gaat via het endpoint SalesOrders.
Bij aanmaken zijn de klant (OrderedBy) en de orderregels verplicht, met per regel een artikel (Exact Online REST API, SalesOrders; SalesOrderLines). Een order met een onbekend artikel komt er dus niet in: de match uit stap 3 moet eerst rond zijn.
Twee velden zijn voor orderinvoer handig. YourRef is de referentie van de klant, en dus de plek om het inkoopordernummer vast te leggen en dubbele orders te weigeren.
Daarnaast kent Exact een goedkeuringsstatus op verkooporders, met 0 voor "wacht op goedkeuring". Welke velden en limieten de Exact-API verder heeft, staat in de Exact Online API uitgelegd.
Picqer. Hier is de conceptorder ingebouwd.
Een order die via de API binnenkomt, krijgt altijd de status concept; pas na "verwerken" is hij definitief en maakt Picqer een picklijst of backorder. Per regel volstaat een product-ID of productcode met een aantal; de prijs is optioneel en werkt als override.
Dat past goed bij de controle die wij willen: de binnendienst bevestigt in Picqer zelf. Hoe Picqer verder aan je webshop en boekhouding hangt, lees je in Picqer koppelen.
Draai je een ander ERP, dan geldt hetzelfde principe zolang er een API of een importfunctie is. Zonder concept- of goedkeuringsstatus in het pakket bouwen we het bevestigingsscherm ernaast, en schrijven we pas weg na akkoord.
Waarom er een mens tussen blijft
Volledig automatisch doorboeken klinkt als het doel. Wij zetten de bevestiging er bewust in, en halen hem per klant pas weg als de cijfers dat rechtvaardigen.
De reden is eenvoudig: een verkeerd gelezen aantal of eenheid is bij een groothandel geen typefout, maar een levering die retour moet. Dat kost meer dan de paar seconden die een bevestiging duurt.
Wat er verandert, is het werk van de binnendienst: in plaats van een leeg orderscherm te vullen, kijken ze naar een ingevulde order met een paar gemarkeerde regels.
Vaste klanten met een vaste pdf-opmaak en een gevulde vertaaltabel kun je later op automatisch zetten; wijzigingen en annuleringen nooit. Waarom die grens bij agents in het algemeen belangrijk is, staat in human-in-the-loop bij AI-agents.
Wanneer je deze route niet nodig hebt
Niet elke order hoort via de mail binnen te komen. Drie grenzen:
- Je afnemer stuurt EDI: gestructureerde berichten van systeem naar systeem, daar valt niets te lezen, alleen te koppelen; zie wat een EDI-koppeling kost
- Je klant bestelt zelf in een portaal of B2B-webshop: mail lezen is voor de klanten die dat niet gaan doen; de portaalkeuze staat in B2B-bestelportaal: pakket of laten bouwen?
- Het gaat om inkoopfacturen: ander proces, zie AI facturatie automatisering
Facturen van je leveranciers lijken op orders, maar daar match je op je eigen inkooporder en boek je in je administratie. Bij verkooporders match je op klantartikel en prijsafspraak.
Ben je vervoerder in plaats van groothandel, dan is het mechanisme hetzelfde, maar de velden verschillen: laad- en losadres, tijdvenster, colli en gewicht, en de order gaat je TMS in. Hoe dat in een kleine vervoerder samenhangt met het planbord, lees je in transport planning software voor een vloot onder de 50 wagens.
Wat het kost en hoe je begint
Wij bouwen orderinvoer als AI-documentverwerking met ERP-koppeling, onderdeel van onze AI-agents. De prijs hangt af van drie dingen: het aantal orderbronnen en opmaken, het ERP waarin je wegschrijft, en of de mailbox al op orde is of eerst gesplitst moet worden.
Onze prijsband: orders uit de mail lezen en als concept in één ERP zetten kost vanaf €3.500 setup plus €250 tot €500 per maand. Schrijf je weg naar meerdere ERP-systemen of wil je een uitgebreide goedkeuringsstap, dan is de setup €8.000 tot €12.000. Bedragen exclusief btw.
Hoe zich dat verhoudt tot andere vormen van AI, staat in ons kostenoverzicht van AI voor bedrijven. Onze vuistregel: vanaf zo'n twintig orders per dag die nu worden overgetypt, loont het.
Begin met één week tellen, voordat je iets koopt:
- Hoeveel orders kwamen er per dag binnen via de mail?
- Hoeveel daarvan als pdf, Excel, vrije tekst of foto?
- Bij hoeveel klanten zat een eigen artikelnummer of een afwijkende prijs?
- In welke mailbox kwamen ze binnen, en wat komt daar nog meer?
Met die vier antwoorden zie je in de tabel hierboven waar jouw risico zit. Meer keuzes rond koppelingen en maatwerk staan in ons overzicht van maatwerk software en koppelingen.
Wil je weten of jouw ordermail zich hiervoor leent? Stuur ons een paar geanonimiseerde voorbeelden.
Neem contact op, bel 085 016 0118 of plan een gesprek.
Opgesteld met AI-ondersteuning, geredigeerd en inhoudelijk verantwoord door het Redactieteam CleverTech AI.









