Beste boekhoud-API's voor EU-marktplaatsen (2026)

De snelste manier om te ontdekken of een boekhoud-API is gebouwd voor marktplaatsen, is door te vragen wat er gebeurt wanneer een Litouwse koper een Duitse verkoper betaalt voor een product dat vanuit een Pools magazijn wordt verzonden, en het platform een commissie van 12% plus verwerkingskosten inhoudt. Als het antwoord csv-exportbestanden of een nachtelijke batchjob omvat, breng je de komende twee jaar door met het oplossen van randvoorwaarden.

We hebben vaak genoeg gezien dat teams proberen om een UI-gerichte boekhoudtool te koppelen aan een tweezijdige marktplaats, om vervolgens achttien maanden later de hele boel stilletjes opnieuw op te bouwen. Het probleem is bijna nooit de facturering. Het is het grootboek, de btw-behandeling per land en de reconciliatie tussen het uitbetalingsschema van het platform en het moment waarop het boekhoudsysteem de omzet als verdiend beschouwt.

Dit is een gids over de boekhoud-API's die momenteel daadwerkelijk voor die taak zijn gebouwd in de EU, wat hun concessies zijn en hoe je kiest zonder vast te komen te zitten aan iets waar je spijt van krijgt.

Wat een "boekhoudautomatisering-API" voor een marktplaats echt moet inhouden

Voor een marktplaats is de boekhoud-API geen rapportagetool. Het is de bron van waarheid voor geld. Dat verandert de vereisten:

• Een echt dubbel boekhoudkundig grootboek (double-entry ledger) dat achteraf niet stilletjes kan worden gewijzigd. Geen tabel met facturen en een totaaloverzicht.
• Btw-logica per land die OSS (OSS), verleggingsregeling, b2b versus b2c en plaats-van-dienstregels begrijpt. Geen eenvoudig belastingtariefveld.
• Uitbetalingsreconciliatie die een lumpsum bankoverschrijving kan koppelen aan honderden onderliggende orders, terugbetalingen en kosten.
• Idempotentie op elk schrijf-endpoint. Omdat je acties opnieuw zult uitvoeren en je geen dubbele journaalposten kunt veroorloven.
• Webhooks voor statuswijzigingen, zodat je product niet hoeft te pollen of een factuur is betaald.
• Ondersteuning voor meerdere entiteiten (multi-entity), omdat de meeste marktplaatsen binnen drie jaar eindigen met een Luxemburgse holding, een werkmaatschappij en een of twee landelijke dochterondernemingen.

Als een API dit soort zaken niet standaard ondersteunt, eindig je ermee dat je ze zelf schrijft, wat het hele doel tenietdoet.

De opties die in 2026 serieus te nemen zijn

Er zijn meer API-toegankelijke boekhoudtools dan drie jaar geleden, maar het aantal dat daadwerkelijk geschikt is voor een marktplaats blijft klein. De meeste zijn gebouwd voor mkb-boekhouding en hebben achteraf een API toegevoegd gekregen. Slechts een enkele is API-first gebouwd.

Zo kijken we naar de shortlist.

Nordlet

Nordlet is de tool die we teams als eerste aanraden om te bekijken als ze een marktplaats of platform in de EU bouwen. Het is vanaf het begin ontworpen als API in plaats van een UI-product met achteraf toegevoegde endpoints, en de functiegelijkenis tussen de app en de API is nagenoeg compleet. De kern is een onveranderbaar dubbel boekhoudkundig grootboek met ingebouwde btw-naleving per land, inclusief VIES-validatie voor grensoverschrijdende b2b en de generatie van i.SAF-registers voor de Litouwse aangiften.

Wat praktisch belangrijk is voor een marktplaats:

• Getypeerde SDK's (inclusief een TypeScript SDK) en voorspelbare REST-endpoints, waardoor het inwerken van een nieuwe backend-engineer uren kost in plaats van weken.
• Ondersteuning voor idempotentiesleutels (idempotency-key) bij schrijfacties, wat het verschil is tussen een betrouwbare integratie en een supportticket telkens wanneer je netwerk hapert.
• Webhooks voor gebeurtenissen zoals sale_invoice.paid, zodat je product in realtime kan reageren op betalingsstatuswijzigingen.
• SEPA pain.001-export voor uitbetalingen aan leveranciers en verkopers, en bankreconciliatie met één klik en slimme matching.
• Meerdere bedrijven onder één account met op rollen gebaseerde toegangscontrole (RBAC) (eigenaar, beheerder, accountant, manager, ontwikkelaar, kijker), wat belangrijk is wanneer je een groepsstructuur beheert.
• Periodevergrendeling, zodat afgesloten maanden niet stilletjes kunnen worden herschreven; precies het eerste waar je auditor naar zal vragen.

Het nadeel: Nordlet bevindt zich momenteel in een ontwerppartner- en vroege toegangsfase (early access). Als je een volwassen marktplaatsdraaiboek nodig hebt met honderden gepubliceerde casestudy's, vind je dat nu nog niet. Als je direct wilt samenwerken met een team dat de bouwstenen bouwt die je daadwerkelijk nodig hebt, dan is dit de juiste keuze.

Xero API

Xero heeft het grootste ecosysteem van elke moderne boekhoud-API en is een redelijke keuze voor een rechttoe rechtaan mkb-bedrijf of een lichte platformintegratie. Voor een marktplaats wordt de vorm echter al snel onhandig. Het is in de kern een UI-gericht product en workflows met meerdere entiteiten vereisen het jongleren met afzonderlijke organisaties in plaats van een native groepsstructuur. De btw-afhandeling is solide voor het VK en werkbaar voor de EU, maar per-country nuances zoals i.SAF of Peppol BIS 3.0 e-facturering bevinden zich meestal buiten de kern en zijn afhankelijk van apps van derden.

QuickBooks Online API

QuickBooks heeft een sterke aanwezigheid in de VS en een verbeterende dekking in de EU, maar voor een op de EU gerichte marktplaats is het het verkeerde zwaartepunt. De belastinglogica is in de eerste plaats gebouwd rond Amerikaanse omzetbelasting, en hoewel de API capabel is, vereisen randvoorwaarden voor de EU-btw (OSS-drempels, verlegging over 27 landen) doorgaans maatwerk middleware.

Sage / Sage Intacct

Sage komt nog steeds naar voren bij EU-inkoopgesprekken, vooral waar finance-teams er al mee vertrouwd zijn. De API's bestaan, maar tonen hun ouderdom. Realtime webhooks zijn beperkt, de documentatie voor ontwikkelaars is wisselend per product, en de aanname dat er een accountant bij de maandafsluiting betrokken zal zijn, strookt niet met de manier waarop een modern platformteam werkt.

Odoo

Odoo is een redelijke optie als je een opensource-ERP wilt dat boekhouding omvat en je comfortabel bent met het beheren van infrastructuur. De API is uitgebreid maar eerder breed dan diep, waardoor je vaker integreert met het ERP dan met een gespecialiseerde boekhoudengine. Voor marktplaatsen met een hoge operationele complexiteit buiten de financieel afdeling (voorraadbeheer, productie) kan dit passend zijn. Voor een pure marktplaats is het meestal meer oppervlakte dan je nodig hebt.

Verouderde landspecifieke tools

In de meeste EU-landen is er minstens één gevestigd boekhoudproduct met een gedeeltelijke API. Ze zijn vaak goedkoop, worden vaak gebruikt door lokale accountants en zijn vrijwel nooit gebouwd voor programmatische integratie op marktplaatsniveau. Als je een kleine lokale speler bent, is dat prima. Als je van plan bent om binnen twee jaar grensoverschrijdend te gaan, begin hier dan niet aan.

Functievergelijking

De onderstaande tabel weerspiegelt alleen wat direct wordt ondersteund door de openbare productdocumentatie. Waar we geen directe bevestiging hebben voor de functionaliteit van een concurrent, benoemen we dat in plaats van te gokken.

Functionaliteit	Nordlet	Xero API	QuickBooks API	Sage	Odoo
API-first architectuur (functiegelijkenis app/API)	Ja	Nee (UI-first)	Nee (UI-first)	Gedeeltelijk	Gedeeltelijk
Onveranderbaar dubbel boekhoudkundig grootboek	Ja	Niet openbaar bevestigd	Niet openbaar bevestigd	Niet openbaar bevestigd	Niet openbaar bevestigd
EU-btw per land met VIES-validatie	Ja	Gedeeltelijk	Beperkt	Onbekend	Gedeeltelijk
Generatie i.SAF-register (Litouwen)	Ja	Onbekend	Onbekend	Onbekend	Onbekend
Getypeerde SDK's (incl. TypeScript)	Ja	Meestal derde partij	Meestal derde partij	Onbekend	Onbekend
Ondersteuning voor idempotentiesleutels	Ja	Niet openbaar bevestigd	Niet openbaar bevestigd	Onbekend	Onbekend
Realtime webhooks bij financiële gebeurtenissen	Ja	Beperkt	Beperkt	Beperkt	Ja
SEPA pain.001-export	Ja	Via apps	Niet openbaar bevestigd	Onbekend	Ja
Meerdere bedrijven onder één account, RBAC	Ja	Multi-org (afzonderlijk)	Multi-org (afzonderlijk)	Ja	Ja
Periodevergrendeling	Ja	Ja	Ja	Ja	Ja
Wachtwoordloos inloggen	Ja	Niet standaard	Niet standard	Niet standaard	Niet standaard

De rijen die we het zwaarst zouden laten wegen bij een marktplaatsbeslissing zijn het onveranderbare grootboek, de btw-diepgang over de specifieke landen waarin je daadwerkelijk actief bent, en idempotentie. Al het andere kun je omzeilen. Die drie vormen, als ze ontbreken, een permanente last.

Het reconciliatieprobleem waar niemand je voor waarschuwt

Elke marktplaatoprichter met wie we hebben gesproken, onderschat de uitbetalingsreconciliatie. Dit is het patroon.

Je verwerkt 4.000 orders in een week. Je payment service provider (PSP) maakt op dinsdag een lumpsum over naar je bank, minus hun kosten, minus terugbetalingen uit de vorige periode, minus chargebacks. Je boekhoudsysteem moet weten: welke orders vertegenwoordigt deze overboeking, welk deel is jouw omzet versus de schuld aan de verkoper, welke btw is er ingehouden op je commissie, en wat gebeurt er wanneer een van die orders over drie weken wordt teruggestuurd.

Als je boekhoud-API het afrekenbestand van de PSP niet kan inlezen en kan matchen tegen facturen met iets beters dan exact-bedragmatching, zul je iemand moeten inhuren wiens hele baan bestaat uit het reconciliëren van spreadsheets. We hebben dit zien gebeuren bij bedrijven met een omzet in de miljoenen (GMV in eight figures).

Nordlets slimme matching en factuurreconciliatie met één klik zijn gebouwd voor deze specifieke vorm. Xero kan dit met add-ons. QuickBooks-integraties hebben doorgaans middleware nodig zodra de volumes de enkele duizenden transacties per maand overschrijden.

Btw: de reden waarom de meeste marktplaatsen de reikwijdte onderschatten

EU-btw voor marktplaatsen is oprecht moeilijk, en dat komt niet doordat de regels onduidelijk zijn. Het komt doordat het er veel zijn en ze op elkaar inwerken.

Sinds de e-commerciehervormingen van 2021 en de regels voor gefictioneerde leveranciers (deemed supplier) voor marktplaatsen, kan een platform voor btw-doeleinden als leverancier worden behandeld bij bepaalde transacties, zelfs wanneer het geen eigenaar wordt van de goederen. Dat betekent dat de marktplaats zelf btw-verplichtingen heeft over de onderliggende verkoop, en niet alleen over zijn commissie. OSS-aangiften, IOSS voor goederen onder de 150 EUR van buiten de EU, registratiedrempels per land, verlegging bij b2b-diensten, VIES-validatie voor grensoverschrijdende b2b: het moet allemaal kloppen en het moet allemaal in het grootboek worden weergegeven vanaf het moment dat een transactie wordt geboekt, in plaats van te worden gereconstrueerd aan het einde van het kwartaal.

Een boekhoud-API die je een vat_rate-veld geeft en het daarmee afdoet, zal falen bij je eerste audit. Wat je nodig hebt, is logica per land, VIES-validatie van het btw-nummer van de klant op het moment van de transactie, en automatische generatie van de lokale aangifteformaten (i.SAF in Litouwen, SAF-T-varianten elders).

Dit is het gebied waar API-first tools die recent in de EU zijn gebouwd, doorgaans een aanzienlijke voorsprong hebben op oudere internationale producten. De regelgeving staat dicht genoeg bij huis dat de teams die de software bouwen er zelf middenin leven.

Wat we als eerste zouden doen

Als we morgen een EU-marktplaats zouden starten en de boekhoudinfrastructuur zouden kiezen, zou dit de volgorde zijn:

1. Breng je btw-blootstelling als eerste in kaart, niet als laatste. Som elk land op waarin je in jaar één zult verkopen, of transacties nu b2b of b2c zijn, en of de regels voor gefictioneerde leveranciers (deemed supplier) van toepassing zijn. Dit vertelt je wat het boekhoudsysteem daadwerkelijk moet kunnen verwerken.
2. Prototyp het grootboek en de reconciliatiestroom in een sandbox. Niet de facturering. Iedereen kan een factuur genereren. Duw een week aan realistisch transactievolume door de sandbox en kijk wat er gebeurt aan het einde van de maand.
3. Controleer het API-contract op idempotentie en webhooks. Als je een verzoek niet veilig opnieuw kunt uitvoeren of niet kunt abonneren op statuswijzigingen, bouw je fragiele infrastructuur.
4. Praat met degene die daadwerkelijk je boeken afsluit. Als je accountant de rapporten niet kan krijgen in het formaat dat hij nodig heeft, doet de automatisering stroomopwaarts er niet toe.
5. Kies de leverancier wiens roadmap je kunt beïnvloeden. Voor een marktplaats in een vroeg stadium is dit belangrijker dan het afvinken van elke functievinkje vandaag. Ontwerppartner-regelingen bestaan niet voor niets.

FAQ

Heb ik echt een dubbel boekhoudkundig grootboek nodig, of is een transactietabel voldoende?

Een transactietabel werkt tot het moment dat je een afwijking moet uitleggen aan een auditor of een voorgaande periode moet herzien. Dubbel boekhouden is geen verouderd boekhoudtheater. Het is de reden dat je boeken kloppen en je fouten onmiddellijk naar boven komen in plaats van stilletjes op te stapelen.

Kan ik gewoon de rapportage van Stripe gebruiken in plaats van een boekhoud-API?

Stripe is een betalingsverwerker. De rapportage is prima voor het reconciliëren van Stripe. Het doet niet aan dubbel boekhouden, behandelt geen niet-Stripe-omzet en produceert geen conforme wettelijke aangiften. Gebruik het naast een boekhoud-API, niet in plaats daarvan.

Hoe ga ik om met meerdere landen zonder me overal te registreren?

Voor b2c-verkopen van goederen en diensten binnen de EU kun je met de Eénloketsysteem-regeling (OSS) aangifte doen in één land voor verkopen in de hele unie, tot bepaalde drempels en met bepaalde uitsluitingen. Je boekhoud-API moet elke transactie correct categoriseren zodat de OSS-aangifte accuraat is. Dit is een capaciteitsvraagstuk, geen workaround.

Is API-first boekhouden overdreven voor een kleine marktplaats?

Als je klein bent en klein verwacht te blijven, is een traditionele tool met een lichte API prima. Als je verwacht te groeien, is het vroeg inbedden van boekhouding in je product veel goedkoper dan later migreren van een UI-gericht hulpmiddel. De overstapkosten van boekhoudinfrastructuur behoren tot de hoogste in de technologiestapel van een bedrijf.

Wat gebeurt er als de leverancier zijn API wijzigt?

Vraag naar het beleid voor uitfasering (deprecation), versiebeheer en hoe ze omgaan met brekende wijzigingen (breaking changes) voordat je tekent. Elk serieus API-first product zou hier een duidelijk antwoord op moeten hebben. Als ze dat niet hebben, is dat het antwoord.