Embedded Accounting: Build vs Buy for Marketplaces
Een lijst met functionaliteiten, een kostenmodel met expliciete aannames en de voorwaarden waaronder elk antwoord juist is.
Elke marktplaats bouwt uiteindelijk een eigen grootboek (ledger). De enige vraag is of dit bewust gebeurt, als een systeem met controles, of per ongeluk, als een balance-kolom waar drie services naar schrijven en die niemand echt vertrouwt.
Dit artikel helpt om die keuze bewust te maken. Het behandelt wat het werk daadwerkelijk omvat, hoe je de kosten berekent zonder jezelf voor de gek te houden en onder welke specifieke voorwaarden zelf bouwen het juiste antwoord is - want soms is dat inderdaad zo.
Wat "embedded accounting" hier betekent
Embedded accounting betekent dat de boeken zich binnen je product bevinden in plaats van in een applicatie die iemand apart opent. Je software legt de boekingen vast zodra er gebeurtenissen plaatsvinden, je gebruikers zien wat je interface hun toont en niemand hoeft aan het einde van de maand een spreadsheet te exporteren naar een boekhouder.
Voor een marktplaats omvat dit minstens: ontvangen betalingen van kopers, verschuldigde bedragen aan verkopers, verdiende commissie, transactiekosten, btw over je eigen vergoeding en over de onderliggende levering, terugbetalingen (refunds), chargebacks, reserves, uitbetalingen (payouts) en de aflettering (reconciliation) van dit alles tegen een bank of betaalprovider.
Wat je daadwerkelijk bouwt als je ervoor kiest om te bouwen
Het grootboek zelf is slechts het kleine deel. Teams schatten het eerste onderdeel vaak correct in, maar ontdekken de rest pas achteraf.
| Onderdeel | Wat het behelst |
|---|---|
| Journaalposten en rekeningen | Sluitende mutaties, grootboekschema, rekeningtypes, openingssaldi |
| Onveranderbaarheid (immutability) | Alleen-toevoegen opslag (append-only storage), correctie- en tegenboekingsworkflow, geen in-place wijzigingen |
| Periodebeheer | Afsluiten, vergrendelen, weigeren van late boekingen, gecontroleerd heropenen met een auditlog |
| Idempotentie | Sleutels, opslaan van eerdere antwoorden, detectie van botsingen bij gewijzigde payloads |
| Geldverwerking | Exacte decimale of cent-rekenkunde, valuta-codes, wisselkoersen en hun bron, afrondingsrekeningen |
| Btw-engine | Tarieven per land met geldigheidsculsen, plaats van de dienst (place of supply), verleggingsregeling, regels voor fictieve leveranciers (deemed supplier), vrijstellingen |
| Btw-identificatiecontroles | Validatie tegen het officiële register, caching, tijdstempels, verzoekidentificaties, een handmatige beoordelingswachtrij bij fouten |
| Documenten | Facturen, creditnota's, kloppende doorlopende nummering per reeks en jaar, PDF-rendering, verzending |
| E-facturatie | Gestructureerde formaten zoals EN 16931 UBL en nationale formaten per land waar verplicht |
| Bankintegratie | Afschriftimport of een gekoppelde bankverbinding met toestemming, ontdubbeling van reeds geïmporteerde transacties |
| Aflettering (reconciliation) | Matchingsregels, scoring, gedeeltelijke matches, uitzonderingen die een mens kan oplossen |
| Uitbetalingen (payouts) | Genereren van betaalbestanden, uitbetalingsbatches, terugkoppelen van uitbetalingen aan de onderliggende items |
| Rapportage | Proef- en saldibalans, balans, winst- en verliesrekening, kasstroomoverzicht, btw-overzichten, ouderdomsanalyse van vorderingen |
| Belastingregisters en -aangiften | Wat je landen ook vereisen, in het formaat dat de autoriteit accepteert |
| Audit | Actor, actie, entiteit en de wijziging zelf, doorzoekbaar, voor elke mutatie |
| Bewaring en export | Tien jaar bewaarplicht voor OSS-records, volledige gegevensexport, verdedigbaar archief |
Ongeveer twee van die zeventien rijen vormen het gedeelte dat de meeste teams voor zich zien wanneer ze zeggen "we bouwen wel even een grootboek".
Eerlijk begroten
Elk bedrag hangt af van je team, dus beschouw het volgende als een methode in plaats van een offerte. Neem de onderdelen hierboven, geef elk een omvang in engineer-weken op basis van de snelheid van je eigen team en pas vervolgens drie correcties toe die schattingen meestal vergeten.
Correctie één: de compliance-componenten zijn niet eenmalig. Tarieven veranderen, drempels veranderen, formaten veranderen en het btw-pakket voor het digitale tijdperk (VAT in the Digital Age) van de EU brengt verplichte data met zich mee - OSS- en IOSS-wijzigingen vanaf 1 januari 2027, uitgebreide platformregels vanaf 1 juli 2028 en grensoverschrijdende digitale rapportage vanaf 1 juli 2030. Zelf bouwen betekent dat je verantwoordelijk bent voor elk van die migraties.
Correctie twee: correctiewerk duurt langer dan feature-ontwikkeling. De eerste versie verwerkt het ideale scenario. De eindeloze uitzonderingen zijn terugbetalingen na uitbetaling, gedeeltelijke terugbetalingen, chargebacks die weken later binnenkomen, valuta-afrondingen, dubbele webhooks en afrekenbestanden die niet overeenkomen met je eigen administratie. Dit is waar de planning uit de bocht vliegt.
Correctie drie: de accountant is een belanghebbende, geen recensent. Boeken die een financieel professional niet wil goedkeuren zijn niet af, en die feedback komt vaak laat in het bouwproces binnen.
Een nuttige sanity check: bereken de kosten van de kleinste geloofwaardige opzet - grootboek, correcties, periodevergrendeling, idempotentie, geldverwerking, btw van één land, facturen, bankimport, matching en een basisset aan rapporten - en vergelijk dit met een jaar van een abonnementsdienst op basis van gebruik. Nordlet's gepubliceerde tarieven beginnen bij € 10 per maand inclusief 3.000 verzoeken en lopen op tot € 300 per maand met 200.000 verzoeken. Als bouwen een fractie kost van één engineer-jaar, dan is dat een steekhoudend argument om te bouwen. Als het meerdere engineer-jaars kost plus permanent onderhoud, dan valt de vergelijking niet te winnen, en dat wordt elk jaar dat de regels veranderen alleen maar erger.
Wanneer zelf bouwen echt de juiste keuze is
Drie situaties, die allemaal in de praktijk voorkomen.
Je grootboek is je product. Als je een betaalplatform, een bankproduct of een wallet bouwt waarbij het gedrag van het saldo onder gelijktijdige verzoeken (concurrency) het onderscheidende vermogen is, dan is het grootboek essentieel en hoort het bij jou te liggen. Overweeg dan wel producten voor grootbookinfrastructuur in plaats van alles vanaf nul te bouwen, en houd de wettelijke boekhouding apart.
Je model past in geen enkel boekhoudsysteem. Sommige marktplaatsen hebben werkelijk ongebruikelijke afrekenstructuren - opdelingen tussen meerdere partijen met voorwaardelijke vrijgaves, escrow met gefaseerde mijlpalen, complexe reservebeleidsregels. Als geen enkel product dit ondersteunt en de workarounds erger zijn dan het zelf bouwen, ga dan bouwen.
Je volume maakt prijzen op basis van gebruik onvoordelig. Bij extreem hoge transactievolumes houdt op pricer per verzoek op aantrekkelijk te zijn. Reken dit door met echte getallen voordat je dit aanneemt, want "extreem" ligt hier hoger dan de meeste platformen bereiken.
Wanneer inkopen de juiste keuze is
Inkopen wint wanneer boekhouden noodzakelijk is, maar niet onderscheidend, wat in de meeste gevallen zo is. Niemand kiest voor jouw marktplaats omdat je journaalposten zo elegant zijn. Ze merken het alleen op als de boeken niet kloppen.
Inkopen is ook de juiste beslissing wanneer je te maken hebt met verplichtingen in meerdere landen. Btw-regels per land, het bewaren van bewijsmateriaal en verplichtingen rond e-facturatie zorgen voor permanent onderhoud, en een leverancier kan dat werk spreiden over alle klanten. Nordlet levert btw per EU-land met VIES-validatie, berekening van OSS- en IOSS-aangiften, i.SAF-registers en EN 16931 UBL voor Peppol als onderdeel van het product in plaats van als een project dat je zelf moet inplannen.
Een gulden middenweg waar de meeste teams op uitkomen
Het praktische antwoord is meestal geen van beide. Het is: koop het grootboek, bouw de workflow.
De accounting-backend is eigenaar van de boekingen, de fiscale behandeling, de documenten, de periodesluiting en het auditlog. Jouw product is eigenaar van alles wat je gebruikers zien en van elke bedrijfsregel die specifiek is voor jouw marktplaats - wanneer fondsen worden vrijgegeven, wat het reservebeleid inhoudt, hoe geschillen worden afgehandeld, wat het verkopersdashboard toont. Je roept de accounting-API aan op de momenten dat geld wordt vastgelegd en je behoudt de onderdelen die echt van jou zijn.
Die grens is ook beter bestand tegen veranderingen dan de alternatieven. Een nieuw land toevoegen betekent configuratie in plaats van een volledig project. Een nieuw uitbetalingsbeleid is jouw code, geen verzoek aan een leverancier.
Wat je moet beslissen voordat je de knoop doorhakt
- Is je grootboek onderscheidend of een verplichting? Wees eerlijk; de meeste zijn een verplichting.
- Hoeveel landen, en wat vereist elk land? Alleen tarieven, of ook aangiften, registers of indiening?
- Wat is je plan voor correcties? Terugbetalingen na uitbetaling en late chargebacks zijn de situaties die een zwak ontwerp blootleggen.
- Wie tekent de boeken af? Betrek die persoon voordat het ontwerp definitief is, niet achteraf.
- Wat is het plan voor de bewaarplicht van tien jaar? OSS-gegevens moeten tien jaar worden bewaard vanaf het einde van het transactiejaar, en een archief is een systeem, geen back-up.
- Hoe ziet een migratie er over drie jaar uit? In beide richtingen. Bouw op dag één een testexport en zorg dat deze blijft werken.
FAQ
Hoe lang duurt het om een marktboekhouding te bouwen?
Een eerste versie die sluitende mutaties boekt, kan binnen enkele weken draaien. Een versie die omgaat met terugbetalingen na uitbetaling, late chargebacks, afronding in meerdere valuta's, dubbele webhooks van providers, periodesluiting en een audit die een accountant goedkeurt, kost aanzienlijk meer tijd, en het onderhoud stopt nooit. Reken op die tweede optie, want dat is wat productieomgeving betekent.
Kunnen we beginnen met een balance-kolom en later migreren?
Dat kan, en veel teams doen dat, maar houd er rekening mee dat de migratie ingewikkelder is dan de oorspronkelijke bouw. Het achterhalen van de geschiedenis vanuit een veranderbaar saldo is alleen mogelijk als je elke gebeurtenis hebt bijgehouden die het saldo heeft gewijzigd - wat eigenlijk neerkomt op het feit dat je al een grootboek had.
Vervangt een embedded accounting-API ons financiële team?
Nee. Het neemt handmatige registratie en aflettering weg. Er is nog steeds iemand nodig om de maand af te sluiten, uitzonderingen te beoordelen, professionele oordelen te vellen en aangiften in te dienen.
Hoe zit het met de AVG (GDPR) als het grootboek onveranderbaar is?
Bewaar monetaire feiten en pseudonieme verwijzingen in de onveranderbaar opgeslagen records, en persoonlijke gegevens in een afzonderlijk systeem met een eigen bewaar- en verwijderingsproces. Onveranderbaarheid geldt voor de financiële gebeurtenis, niet voor elk attribuut dat eraan is gekoppeld.
Is open-source boekhoudsoftware een middenweg?
Het is een reële optie, die de kosten wel verplaatst in plaats van wegneemt: je neemt zelf hosting, upgrades, lokalisatie per land en compliance-updates voor je rekening. Reken die kosten eerst door voordat je de besparing op de licentie als het hele verhaal ziet.