e-boekhouden koppeling laten maken.

Facturen inboeken zonder overtypen

Een leverancier mailt een PDF. Iemand opent hem, zoekt de leverancier, leest bedrag, factuurnummer en btw, en boekt hem in e-Boekhouden als ontvangen factuur. Tien keer per maand is dat te doen. Honderd keer is het een dagtaak.

e-Boekhouden.nl heeft een gedocumenteerde REST API en nodigt zelf uit om er eigen koppelingen op te bouwen. Het lastige zit niet in het versturen, maar in de keuzes per factuur: welke leverancier, welke grootboekrekening, welke btw-code. Die keuzes leggen wij vast in regels, en alles wat buiten die regels valt gaat langs een mens.

Mutaties: zo denkt e-Boekhouden

Wie in e-Boekhouden werkt, kent het woord: alles is een mutatie. De API volgt dezelfde logica. Een boeking post je naar /v1/mutation, met een soort erbij:

• factuur ontvangen
• factuur verstuurd
• betaling van een factuur ontvangen
• betaling van een factuur verstuurd
• geld ontvangen
• geld uitgegeven
• memoriaal

Een inkoopfactuur uit je mailbox wordt dus een mutatie “factuur ontvangen”. Een factuur die je ergens anders maakt, zet je erin als “factuur verstuurd”. Betalingen leg je vast met de betaalsoorten. Dat maakt de koppeling voorspelbaar: elke stroom heeft precies één soort mutatie.

Btw per regel, niet per gevoel

e-Boekhouden werkt met vaste btw-codes, zoals HOOG_VERK_21 en LAAG_VERK_9. Elke regel in een mutatie of factuur krijgt er één. Dat is streng, en dat is goed: de koppeling kan niets stilzwijgend aannemen.

Wij leggen vooraf per leverancier en per product vast welke code erbij hoort. Een factuur met een tarief dat daar niet bij past, of met hoog en laag door elkaar op een manier die je regels niet kennen, wordt geen boeking. Hij gaat naar de uitzonderingslijst, met de reden erbij. Liever een factuur die een dag wacht dan een btw-aangifte die je moet corrigeren.

Van mailbox naar mutatie

1. Ophalen. De workflow leest een vaste factuurmailbox uit.
2. Lezen. Een taalmodel haalt leverancier, factuurnummer, datum, bedragen en btw uit de PDF.
3. Toewijzen. Een vaste regel koppelt de leverancier aan een relatie en een grootboekrekening, via /v1/relation en /v1/ledger.
4. Controleren. Klopt het totaal met de regels? Past de btw-code? Is deze factuur al eens geboekt?
5. Boeken. Alleen als alles klopt: een mutatie “factuur ontvangen”. Anders de uitzonderingslijst.

Of de PDF zelf via de API aan de boeking vast kan, zoeken we voor de start uit. Lukt dat niet, dan bewaren we hem op een vaste plek met het factuurnummer in de bestandsnaam. Meer over de lastige kant van facturen uitlezen staat bij factuurverwerking automatiseren.

Webshoporders als verkoopfactuur

De andere richting. Je webshop meldt een bestelling, de workflow zoekt de klant als relatie, maakt hem aan als hij nieuw is, en maakt via /v1/invoice een verkoopfactuur. De API kent geen verkooporders, dus we werken met facturen.

Voor webshops als Shopify bestaan kant-en-klare apps die dit ook doen. Werkt die voor jou, dan heb je ons hier niet voor nodig. Wij bouwen het als orders uit meer bronnen komen, of als je per product vaste afspraken over grootboek en btw hebt die een app niet kent.

Openstaande posten haal je op via /v1/mutation/invoice/outstanding. Dat is een handig startpunt om elke ochtend te laten checken wat er nog openstaat, en dat door te zetten naar debiteurenbeheer.

Waar het fout kan lopen

Een herinnering met dezelfde PDF. Leveranciers sturen een aanmaning met de oorspronkelijke factuur eronder. Wij controleren op leverancier plus factuurnummer voordat er iets geboekt wordt.

Twee leveranciers die op elkaar lijken. “Van der Meer Techniek” en “Vd Meer Techniek”. Is de koppeling niet zeker, dan kiest een mens. Eén keer, daarna onthoudt de regel het.

Een grootboekrekening die er nog niet is. Een nieuwe kostensoort valt buiten je regels en wordt geen boeking op een verzamelrekening.

Token en sessie

n8n heeft geen e-Boekhouden node, dus we gebruiken de HTTP Request node. Het API token maak je zelf aan in je e-Boekhouden instellingen. Je ziet het één keer. De koppeling stuurt het naar POST /v1/session en krijgt een kortlevend sessietoken terug, dat in de Authorization header van elk volgend verzoek gaat.

Lijsten haal je op met limit (standaard 100, maximaal 2000) en offset, en je filtert met operators als [like] en [range]. Hoeveel verzoeken per minuut de API toelaat, staat niet in de specificatie. Dat vragen we na, en een grote eerste import spreiden we sowieso over de tijd. Het algemene verhaal over hoe wij systemen aan elkaar knopen, staat bij api integratie.

Wanneer niet

• Je boekt een handvol facturen per maand. De bouw verdient zich dan niet terug. Doe de som eerst met wat automatisering kost.
• Elke factuur komt van een andere leverancier. Zonder terugkerende leveranciers zijn er geen regels om vast te leggen.
• Een webshop-app regelt het al. Dan is maatwerk dubbel werk.
• Niemand weet wie goedkeurt. Spreek dat eerst af.

Kosten

Wil je alleen webshoporders als verkoopfactuur in e-Boekhouden, zonder taalmodel, dan begint het bij EUR 3.000. Moet een taalmodel je inkoopfacturen lezen, reken dan vanaf EUR 4.000 en tel de modelkosten per document erbij op. Inkoop, verkoop, betalingen en een uitzonderingslijst als één keten: EUR 6.000 tot 10.000. Een aanpassing achteraf kost EUR 125 per uur, de hosting van je n8n-omgeving EUR 20 tot 200 per maand. Meer over de prijsbanden: wat kost een ai agent.

Groei je naar Exact? Lees Exact Online automatiseren. Op Moneybird? Zie Moneybird koppeling.