orderverwerking automatiseren.

Van bestelling naar verkooporder, zonder overtypen

Er komt een order binnen. Iemand opent Exact Online, zoekt de klant op, maakt een verkooporder aan, typt de regels over, kiest de juiste grootboekrekening en slaat op. Een paar minuten per order. Vermenigvuldig dat met het aantal orders per dag en je weet waarom deze pagina bestaat.

Exact Online is het meestgebruikte boekhoud- en ERP-pakket van Nederland, ruwweg 500.000 bedrijven en accountants werken ermee. De REST API kan verkooporders en verkoopfacturen aanmaken. Wat de API niet doet is bepalen wélke klant, wélk artikel en wélke grootboekrekening. Dat is het werk.

Eerst kijken of een standaardkoppeling het al doet

Voor WooCommerce, Shopify en Magento naar Exact Online bestaan kant-en-klare koppelingen, en die staan in het App Centre van Exact zelf. Ze zijn af, ze worden onderhouden en ze kosten een fractie van maatwerk. Werkt dat voor jou, neem dat.

Maatwerk wordt pas interessant als je bron er niet tussen staat, als orders uit meerdere systemen tegelijk komen, als je een controlestap nodig hebt die het standaardproduct niet kent, of als de order onderweg nog ergens anders heen moet dan alleen Exact. Herken je dat niet, dan is deze pagina niet voor jou.

Waar je orders vandaan komen bepaalt de helft van het werk

“Een order” is geen eenduidig ding. De bron bepaalt hoeveel werk het is.

Webshop. Het makkelijkste geval. WooCommerce, Shopify of Magento sturen een webhook met nette JSON: klantgegevens, regels, aantallen en prijzen in vaste velden. Hier zit het werk in het koppelen, niet in het lezen.

CRM. Een deal die op gewonnen gaat in HubSpot, Pipedrive of Teamleader. Ook gestructureerd, maar de regels staan vaak in line items die je artikelbestand niet één op één volgen, of erger, in een vrij tekstveld in de offerte.

E-mail met een PDF. Hier stopt de structuur. Elke klant heeft zijn eigen inkooporderformaat. Een taalmodel kan de PDF uitlezen en er velden van maken, maar dat blijft een interpretatie met een zekerheidsscore. Deze bron heeft altijd een controlestap nodig.

Excel van een vertegenwoordiger. Lijkt gestructureerd, is het niet. Kolommen verschuiven, iemand typt “2 st” in een aantalveld, productnamen worden afgekort. Je bouwt hier tegen menselijke variatie.

Klantportaal of EDI. Netjes gestructureerd, alleen in een eigen formaat dat je moet vertalen naar de velden die Exact verwacht.

Meerdere bronnen tegelijk kan prima. Je bouwt per bron een aparte ingang die uitkomt op dezelfde verwerkingsstap, zodat de controlelogica maar één keer bestaat.

Het matchen is waar de tijd in gaat

Dit deel bepaalt de bouwtijd, en het is zelden waar mensen vooraf aan denken.

Een order noemt een klant. Exact kent relaties. Die twee moeten aan elkaar. “Jansen BV” in je webshop kan “Jansen Groothandel B.V.” heten in Exact, of er drie keer in staan omdat iemand ooit dubbel heeft aangemaakt. Hetzelfde geldt voor elke orderregel: een SKU of een productnaam uit de bron moet uitkomen op precies één artikel, met de juiste artikelcode, prijs en btw-behandeling.

Wat werkt is een vast koppelveld aan beide kanten, bijvoorbeeld het relatienummer uit Exact opslaan in je webshop of CRM. Wat ook werkt is een mappingtabel voor artikelen die je zelf bijhoudt. Wat niet werkt is puur op naam matchen en hopen dat het goed gaat.

Hoe schoner je klant- en artikelbestand, hoe korter dit stuk duurt. Is het een zooitje, dan hoort opschonen bij het project.

Wat er misgaat, en waar je dat tegenhoudt

Automatisering die de verkeerde dingen doorlaat kost je meer dan handwerk. Drie klassiekers:

Dubbele orders. Een webhook vuurt twee keer, of een retry na een timeout maakt de order nog een keer aan. Dit vang je af met een idempotency key: sla het ordernummer uit de bron op in een vrij veld op de verkooporder en controleer daarop voordat je aanmaakt. Bestaat hij al, dan sla je over.

Verkeerde grootboekrekening. Een nieuw artikel of een buitenlandse klant valt buiten je regels en belandt op een verzamelrekening. Dat merk je pas bij de afsluiting. Regel: onbekend is geen standaardwaarde, onbekend is een uitzondering.

Een klant die nog niet bestaat. Je kunt automatisch een relatie aanmaken, maar bepaal dan vooraf welke velden verplicht zijn. Vaak is het beter om die order te parkeren en er even iemand naar te laten kijken.

De veiligheidsklep heeft in alle drie de gevallen dezelfde vorm. Een order die niet volledig klopt wordt geen boeking, maar komt in een uitzonderingsrij te staan met de reden erbij. Iemand keurt hem goed of corrigeert hem, en alles wat wel klopt gaat zonder tussenkomst door. In het begin kun je orders ook standaard als concept aanmaken en door een mens laten bevestigen, tot je genoeg vertrouwen hebt om die stap eruit te halen.

Dit patroon, automatisch voorbereiden en een mens laten bevestigen, bouwden we voor Capptions: een n8n-keten zoekt per bedrijfsnaam de juiste beslisser, Claude classificeert die persoon, en het resultaat komt als taak in HubSpot te staan waar iemand alleen nog op verzenden klikt. Ander systeem, geen Exact, geen orders. Alleen dezelfde opbouw.

Wat er onder de motorkap gebeurt

n8n heeft geen kant-en-klare Exact Online node. Je koppelt via de HTTP Request node met een OAuth2-credential, en n8n ververst het access token zelf. Je app registreer je binnen Exact Online zelf, via Bedrijfsnaam, Import/Export, App registrations. Er zit geen scope-parameter in het autorisatieverzoek: de gebruiker kiest bij het toestemming geven welke administraties je app mag benaderen, en verder bepaalt zijn eigen licentie wat er kan.

De endpoints zien er zo uit: https://start.exactonline.nl/api/v1/{division}/salesorder/SalesOrders voor de order en .../salesinvoice/SalesInvoices voor de factuur. Zodra de verkooporder klopt, is die factuurstap klein werk. De limieten zijn 60 verzoeken per minuut en 5.000 per dag per administratie, met een plafond van 20.000 per dag over je hele contract. Bij een bulkrun zet je er dus een Wait-node of een batchinstelling tussen en spreid je het werk, want dat contractplafond raak je eerder dan de minuutlimiet. Parallelle aanroepen zijn niet toegestaan. De volledige technische kant staat in ons overzicht van Exact Online automatisering, en hoe wij koppelingen opbouwen lees je bij api integratie.

Wanneer je dit niet moet automatiseren

• Je verwerkt een handvol orders per week. Dan haal je de bouwtijd er niet uit. Zet er een vaste checklist naast en besteed je geld ergens anders.
• Elke order is een onderhandeling. Als prijs, korting en levervoorwaarden per order verschillen, automatiseer je een sjabloon dat structureel niet klopt.
• Je artikelbestand verandert dagelijks. Elke wijziging raakt je mapping. Zorg eerst voor een stabiel assortiment, anders onderhoud je de koppeling vaker dan je hem gebruikt.
• Je hebt geen stabiele orderbron. Komen orders via WhatsApp, telefoon en drie mailboxen door elkaar, dan is je eerste stap één vaste ingang maken, niet automatiseren.

Loop je tegen een van deze punten aan, dan zeggen we dat in het eerste gesprek. Een koppeling die je niet terugverdient is voor ons ook geen goede referentie.

Wat het kost

Eén bron naar Exact Online, zonder taalmodel, start vanaf EUR 3.000. Een keten van 5 tot 10 workflows, met meerdere bronnen, de factuurstap en een uitzonderingsrij, zit tussen EUR 6.000 en EUR 10.000. Aanpassingen achteraf kosten EUR 125 per uur, hosting van je n8n-omgeving EUR 20 tot 200 per maand.

Komt er een taalmodel bij om PDF-orders uit te lezen, dan begint het bij EUR 4.000. Daar bovenop komen modelkosten per verwerkt document, dus die post schaalt mee met je ordervolume. De volledige prijsbanden staan bij wat kost een ai agent.

Gaat het juist om facturen die binnenkomen in plaats van orders die uitgaan, dan is factuurverwerking automatiseren je pagina. Loopt je orderstroom eenmaal, dan is de logische volgende stap de rest van je administratie automatiseren. Heb je al een n8n-omgeving en wil je alleen iemand die dit bouwt of nakijkt, dan huur je ons in als n8n consultant.