factuurverwerking automatiseren.

Iemand zit facturen over te typen

Er komt een PDF binnen op de factuurmailbox. Iemand opent hem, leest de leverancier, het bedrag, de factuurdatum, het factuurnummer, het BTW-bedrag en het IBAN, en tikt dat over in Exact Online als inkoopboeking. Daarna de volgende. Vijftig keer per maand, of driehonderd.

Dat overtypen kan weg. Het goedkeuren niet. Deze pagina gaat over het eerste.

Dit is een drukke markt, en dat moet je weten

Exact Online heeft zelf een scan- en herkenfunctie. Daarnaast bestaan er gevestigde pakketten die precies dit doen, Basecone bijvoorbeeld, onderdeel van Wolters Kluwer. Die producten zijn af en worden onderhouden. Voor een groot deel van de bedrijven is dat genoeg, en dan is maatwerk laten bouwen weggegooid geld.

Maatwerk wordt pas interessant in vier situaties:

• Je goedkeuringsroute wijkt af. Budgethouder per kostenplaats, tweede akkoord boven een bedrag, of een projectleider die helemaal niet in Exact werkt.
• De factuurdata moet ook ergens anders heen. Een projectsysteem, een ERP, een calculatietool waarin je kosten per project bewaakt. Dan bouw je feitelijk een API-integratie en is de boeking in Exact maar één van de bestemmingen.
• Je hebt veel administraties. In de Exact Online API is elke administratie een eigen division in het pad. Twintig administraties betekent twintig keer dezelfde route doorlopen. Werk je op een kantoor, kijk dan ook naar automatisering in de accountancy.
• Eén leverancier stuurt iets wat geen standaardpakket leest. Een bouwbon, een verzamelnota met vijftig regels, een Excel als bijlage in plaats van een factuur.

Herken je geen van deze vier, gebruik dan wat Exact al biedt.

Het uitlezen van de PDF is het makkelijke deel

Tekst uit een factuur halen is standaardwerk. Het probleem zit in de vier stappen erna.

De leverancier koppelen aan de juiste crediteur. Op de factuur staat “Van der Meer Techniek B.V.”, in Exact staat “Vd Meer Techniek”. Of er staan drie crediteuren met bijna dezelfde naam omdat ooit iemand een dubbele heeft aangemaakt. Matchen op naam alleen is niet genoeg. Je matcht op wat er hard op de factuur staat en ook in Exact vastligt. Het BTW-nummer staat als VATNumber op de relatie zelf, net als ChamberOfCommerce. Het IBAN niet: dat hangt aan een aparte BankAccounts-entiteit onder de relatie, en het veld dat je daar nodig hebt heet BankAccount. Het veld dat letterlijk IBAN heet staat in de documentatie als obsolete gemarkeerd, dus daar bouw je niet op. Reken er ook op dat VATNumber bij een deel van je crediteuren gewoon leeg is, want niemand vult een optioneel veld in. Staat er niets bruikbaars op, dan val je terug op de naam en gaat de factuur naar een stapel “onbekende leverancier” in plaats van naar een gok.

De juiste grootboekrekening kiezen. Bij een vaste leverancier die altijd hetzelfde levert is dat een vaste regel. Bij een leverancier die zowel materiaal als abonnementen factureert moet je naar de regels op de factuur kijken. Dat is precies waar het misgaat als je het volledig blind laat lopen.

De BTW goed splitsen. Hoog en laag door elkaar op één factuur, verlegde BTW bij onderaannemers, intracommunautaire leveringen zonder BTW, een factuur uit een land buiten de EU. Elk van die gevallen boekt anders.

De randgevallen. De creditnota die eruitziet als een gewone factuur maar met een minteken. De jaarfactuur die over twee boekperiodes loopt. De factuur die al een keer eerder is binnengekomen omdat de leverancier een herinnering stuurde met dezelfde PDF eronder.

Over herkenkwaliteit zijn we eerlijk: vaste leveranciers met een vaste lay-out gaan goed, want dat is elke maand hetzelfde document. Een eenmalige leverancier of een ingescand papieren bonnetje gaat regelmatig mis. Dat is geen reden om het niet te doen. Het is de reden dat er een mens tussen blijft zitten.

Een mens die goedkeurt is het ontwerp, niet een tekortkoming

De automatisering leest de factuur, zoekt de crediteur op, kiest de grootboekrekening en zet een concept inkoopboeking klaar in Exact Online. Meer niet. Iemand opent die concepten, scant ze en keurt goed.

Dat is bewust. Twee redenen.

Het is goedkoper om te bouwen. Een systeem dat zelfstandig definitief boekt moet elk randgeval afvangen, want een fout komt pas maanden later boven bij de accountant. Een systeem dat concepten aanlevert mag ernaast zitten, want de controle zit erachter. Dat scheelt een flink stuk van de bouwtijd.

En het is veiliger. Een verkeerd geboekte BTW-code corrigeer je zolang de boeking nog concept is. Na de aangifte kost hetzelfde foutje je een correctie en een gesprek met je accountant.

Hoe de koppeling er technisch uitziet

De REST API werkt met OAuth2 en n8n heeft geen kant-en-klare Exact Online node, dus je bouwt het met de HTTP Request node en een OAuth2 credential. Hoe je die verbinding opzet staat stap voor stap in het artikel over Exact Online automatisering.

Twee dingen die specifiek voor factuurverwerking uitmaken. De limiet van 60 requests per minuut geldt per administratie, met daarnaast 5.000 per dag per administratie en een plafond van 20.000 per dag over je hele contract, dus bij twintig administraties plan je de runs uit elkaar. En het IBAN van een crediteur staat niet op de relatie zelf maar in een aparte BankAccounts-entiteit, dus je matchingtabel is een eigen query en geen veld dat je meekrijgt.

Voor Capptions draait er een ketting die per bedrijf de juiste beslisser opzoekt, die persoon classificeert en het resultaat als taak in HubSpot zet, gebouwd met n8n en Claude. Dat is een ander systeem en heeft niets met facturen of Exact te maken. Het zegt alleen iets over het patroon: een keten die het werk voorbereidt en een mens die bevestigt, in het systeem waar de klant al werkt.

Wanneer je dit niet moet automatiseren

• Je verwerkt weinig facturen. Reken het zelf na: aantal facturen per maand, maal de minuten die het overtypen kost, afgezet tegen EUR 3.000 bouwkosten. Komt daar een terugverdientijd van meer dan een jaar uit, blijf dan overtypen.
• Elke factuur is anders. Zonder een kern van vaste leveranciers is er geen patroon om op te bouwen en corrigeer je alsnog alles met de hand.
• Er is geen vaste goedkeuringsroute. Als per factuur wisselt wie er akkoord geeft, automatiseer je chaos. Leg die route eerst vast, daarna pas de techniek.
• De scanfunctie van Exact dekt het al. Dan betaal je voor iets wat je al hebt.

Herken je jezelf in een van deze vier, dan zeggen we dat in het eerste gesprek. Wij bouwen liever niets dan iets wat je over een jaar uitzet.

Wat het kost

Een factuurstroom zonder taalmodel, met vaste regels per leverancier, begint bij EUR 3.000. Komt er een model aan te pas dat de factuur echt moet lezen en interpreteren, reken dan vanaf EUR 4.000. Een ketting van vijf tot tien workflows, bijvoorbeeld inclusief goedkeuring en doorschrijven naar een tweede systeem, zit tussen EUR 6.000 en EUR 10.000. Losse uren zijn EUR 125. Hosting kost EUR 20 tot 200 per maand.

Let op één extra post: modelgebruik rekenen we per verwerkt item af. Bij factuurverwerking is elk document een item, dus die kosten schalen mee met je volume. Reken die post apart door op jouw volume voordat je tekent. Bij lage aantallen verdwijnt hij naast de hosting, bij hoge aantallen is het een eigen regel op je maandrekening.

Zit de pijn aan de inkomende kant, bij orders die vanuit je webshop of CRM in Exact moeten landen, kijk dan naar orderverwerking automatiseren. Gaat het om facturen die je zelf verstuurt en die te laat betaald worden, dan is debiteurenbeheer automatiseren je pagina. Wil je breder kijken dan alleen inkoopfacturen, dan valt dit onder administratie automatiseren.