Webshop koppelen aan je boekhouding: orders, betalingen en voorraad zonder dubbel werk

Een goede koppeling tussen je webshop en boekhouding doet meer dan elke avond een omzetbedrag doorsturen. Ze verbindt vier stromen die niet altijd op hetzelfde moment lopen: de bestelling, de factuur of verkoopboeking, de betaling en de uitbetaling op je bankrekening. Retours, kortingen, betaalfees en chargebacks moeten diezelfde keten ook terug kunnen volgen.

Voor een kleine webshop met enkele orders per maand kan een gecontroleerde export voldoende zijn. Zodra je regelmatig orders, verschillende btw-tarieven, B2B-klanten of veel retours verwerkt, bespaart een betrouwbare koppeling invoerwerk en voorkomt ze verschillen. Begin niet bij de naam van een connector, maar bij de vraag: welk systeem is eigenaar van welk gegeven, en hoe herstel je een uitzondering?

#Wat moet de koppeling precies doen?

Maak eerst onderscheid tussen de systemen. De webshop kent producten, winkelmandjes, kortingen en orders. De betaalprovider kent de echte betaalstatus en bundelt geld in uitbetalingen. De boekhouding bewaart verkoopdocumenten, btw, openstaande posten en bankmutaties. Een ERP, kassa of magazijnpakket kan daarnaast de voorraad beheren.

Een bruikbare koppeling legt vaste sleutels tussen die werelden vast:

• het ordernummer van de webshop;
• het factuur- en eventueel creditnotanummer uit de boekhouding;
• het transactie-ID van de betaalprovider;
• de referentie van de uitbetaling of settlement;
• de artikelcode of SKU die in alle relevante systemen hetzelfde product aanduidt.

Zonder die sleutels kan je later wel bedragen vergelijken, maar niet betrouwbaar verklaren waarom één order, betaling of retour ontbreekt.

#Drie manieren om je webshop te koppelen

Controleer bij een standaardconnector niet alleen of de logo's van jouw pakketten op de verkooppagina staan. Vraag welke richting elk gegeven op gaat, welke btw-scenario's ondersteund zijn, hoe gedeeltelijke retours werken en waar fouten zichtbaar worden. Een CSV-export kan zelfs de betere oplossing zijn als je weinig orders hebt en je boekhouder het bestand vooraf controleert.

Bij platformen met een API zijn orders, statussen, transacties en retours afzonderlijke objecten. De WooCommerce REST API (opent in een nieuw venster) toont bijvoorbeeld aparte orderregels, btw-regels, coupons, betalingen en terugbetalingen. Dat betekent niet dat elke connector ze ook allemaal correct verwerkt.

#Kies per gegeven één bron

Tweerichtingssynchronisatie klinkt aantrekkelijk, maar veroorzaakt snel een lus: de webshop past een klant aan, de boekhouding stuurt een oudere versie terug en de webshop ziet dat opnieuw als wijziging. Leg daarom per gegevenssoort één eigenaar vast.

Een vaak werkbare verdeling is:

• webshop: bestelling, verkoopprijs op het moment van aankoop, korting en gekozen verzending;
• betaalprovider: betaalstatus, terugbetaling, chargeback, transactiekosten en settlement;
• boekhouding: definitief factuurnummer, boekingsrekening, btw-verwerking en openstaande post;
• ERP of voorraadpakket: artikelstam, voorraad en inkoop, als dat systeem ook winkel en magazijn aanstuurt.

Voorraad is de gevoeligste stroom. Laat niet zowel de webshop als het ERP zelfstandig de hoofdvoorraad aanpassen. Spreek ook af wanneer een retour opnieuw verkoopbaar is: bij het aanvragen van de retour, bij de terugbetaling of pas na fysieke controle. Voor veel bedrijven is alleen dat laatste juist.

#Welke ordergegevens moeten mee?

Een ordertotaal alleen is te grof. Voor een correcte verwerking heb je doorgaans orderregels, aantallen, prijzen exclusief en inclusief btw, btw-tarief, kortingen, verzendkosten, valuta en orderdatum nodig. Voor een factuur komen daar de vereiste klant- en leveranciersgegevens bij.

De Europese Commissie noemt voor een volledige btw-factuur onder meer een uniek volgnummer, namen en adressen, omschrijving en hoeveelheid, eenheidsprijs, transactiedatum en een uitsplitsing per btw-tarief. Een creditnota moet ondubbelzinnig naar de oorspronkelijke factuur verwijzen. Bekijk de officiële Europese factuurvereisten (opent in een nieuw venster) en laat je boekhouder bepalen wat in jouw situatie nodig is.

Stuur tegelijk niet automatisch het hele klantprofiel naar elk systeem. Voor de AVG/GDPR geldt gegevensminimalisatie: verwerk alleen persoonsgegevens die nodig zijn voor het doel. De Europese Commissie licht dat principe toe (opent in een nieuw venster). Een leverinstructie of marketingvoorkeur hoort bijvoorbeeld niet vanzelf in je boekhouding.

#Van klik tot boeking: bepaal het juiste moment

Een geplaatste order is nog geen geslaagde betaling. De klant kan afhaken, de bank kan een betaling weigeren of een kaartbetaling kan eerst alleen geautoriseerd zijn. Gebruik daarom de serverstatus van je betaalprovider en vertrouw niet op de pagina waarnaar de browser na betaling terugkeert.

In de webhookdocumentatie van Mollie (opent in een nieuw venster) staat bijvoorbeeld dat de webshop na een melding de actuele betaalstatus via de API moet ophalen. Dezelfde stroom meldt ook mislukte of verlopen betalingen, terugbetalingen en chargebacks. Het voorbeeld hieronder gaat over voorafbetaling vóór levering; leg daarvoor samen met je boekhouder een beslisregel vast:

1. Order aangemaakt: reserveer eventueel voorraad, maar boek nog geen ontvangen betaling.
2. Betaald: geef de order vrij volgens je leveringsregel en maak de verkoopboeking of factuur. Geautoriseerd betekent alleen dat het bedrag gereserveerd is; het is nog niet ontvangen. Leg apart vast of en wanneer je op basis van zo'n autorisatie mag leveren en wanneer de capture plaatsvindt.
3. Voorafbetaling mislukt, verlopen of geannuleerd: geef een reservering vrij en voorkom een definitieve verkoopboeking zolang nog niet geleverd of gefactureerd is. Bij levering of betaling op factuur blijft de afgesproken leverings- en factuurregel leidend: een bestaande factuur of openstaande post verdwijnt niet doordat een betaalpoging mislukt.
4. Retour of terugbetaling: maak de passende creditboeking en verwerk voorraad apart.

De precieze factuurdatum en het moment waarop btw opeisbaar wordt, hangen af van je transactie en betaalwijze. Laat die regel door je boekhouder bevestigen; de software mag ze daarna uitvoeren.

#Waarom uitbetalingen niet gelijk zijn aan omzet

Betaalproviders storten vaak één nettobedrag voor meerdere orders. Daar kunnen terugbetalingen, chargebacks en kosten vanaf zijn. Boek je alleen het bankbedrag als omzet, dan verdwijnen zowel een deel van je omzet als de bijbehorende kosten uit beeld.

Vereenvoudigd kasstroomvoorbeeld: de provider ontvangt voor drie orders € 100, € 80 en € 50 van klanten, samen € 230 inclusief eventuele btw. Vóór de uitbetaling verwerkt hij een terugbetaling van € 20 en € 4,70 aan kosten. Op de bank komt € 205,30. Dit is geen omzetberekening: in de boekhouding verwerk je verkoop, btw, creditnota of terugbetaling en kosten afzonderlijk volgens de echte facturen en rapporten. De bedragen verklaren alleen waarom de bankuitbetaling € 205,30 is.

Gebruik hiervoor een tussenrekening voor de betaalprovider en koppel elk transactie-ID aan de settlementreferentie. De Mollie Settlement Report-documentatie (opent in een nieuw venster) laat zien dat één uitbetaling betalingen, refunds, chargebacks en kosten kan bevatten. Betalingen en correcties zijn tot op transactieniveau op te vragen, maar sommige kosten en rolling reserves worden alleen per settlement samengevoegd. Andere providers hebben een vergelijkbare specificatie, maar velden en timing verschillen.

Een dagelijkse controle kan dan drie vragen beantwoorden:

• staan alle betaalde webshoporders als verkoop of openstaande post in de boekhouding;
• verklaren de betalingen, correcties en kosten samen elke provideruitbetaling;
• blijven er transacties zonder order, of orders zonder definitieve betaalstatus, over?

#Retours, refunds en andere uitzonderingen

De waarde van een koppeling blijkt niet bij de ideale order, maar bij de afwijking. Ontwerp minstens deze gevallen voordat je live gaat:

• een klant doet twee betaalpogingen voor dezelfde order;
• één van drie artikels wordt teruggestuurd;
• de refund slaagt later of voor een ander bedrag dan de creditnota;
• een kaartbetaling krijgt weken later een chargeback;
• een bestelling wordt deels uitgeleverd of geannuleerd;
• een medewerker maakt handmatig een order of terugbetaling aan;
• de provider meldt dezelfde gebeurtenis twee keer;
• de boekhoud-API is tijdelijk onbereikbaar.

Dubbele meldingen zijn geen theoretisch probleem. Shopify waarschuwt in zijn officiële webhookrichtlijnen (opent in een nieuw venster) dat een webhook meer dan eenmaal kan aankomen en adviseert idempotente verwerking: dezelfde gebeurtenis twee keer ontvangen mag niet tot een tweede factuur of voorraadmutatie leiden. Bewaar daarom het externe gebeurtenis-ID en het resultaat van de verwerking.

Voor Belgische B2B-orders komt er nog een regel bij. Sinds 1 januari 2026 moeten Belgische btw-plichtige ondernemingen voor vrijwel alle onderlinge transacties een gestructureerde e-factuur gebruiken. De Belgische overheid beschrijft het toepassingsgebied en Peppol-formaat (opent in een nieuw venster). Ook een creditnota die zo'n factuur wijzigt, moet volgens de officiële e-facturatie-FAQ (opent in een nieuw venster) in hetzelfde gestructureerde formaat worden verstuurd.

Dat maakt de facturatiestroom verplicht in die situaties, niet een specifieke webshopconnector. Je kunt een order nog handmatig in geschikte boekhoudsoftware verwerken. Een koppeling zorgt er vooral voor dat btw-nummer, orderregels en correcties niet opnieuw hoeven te worden ingegeven. Lees voor de wettelijke afbakening de aparte gids over Peppol en e-facturatie.

#Implementatiechecklist voor je leverancier en boekhouder

#1. Teken de huidige stroom

Volg één normale order en één retour van checkout tot bankafschrift. Noteer waar iemand gegevens overtypt, welke exports bestaan en wie een verschil vandaag oplost. Betrek je boekhouder vóór de technische keuze.

#2. Maak een veld- en regelmatrix

Leg per veld bron, bestemming, formaat en eigenaar vast. Voeg beslisregels toe voor B2C of B2B, btw-tarief, korting, verzending, cadeaubon, valuta, factuurmoment, creditnota en voorraad. Documenteer ook welke order- en transactiereferenties in de boekhouding zichtbaar blijven.

#3. Spreek foutafhandeling af

Een fout mag niet alleen in een technisch logbestand staan. Voorzie een wachtrij of overzicht met een begrijpelijke reden, tijdstip, betrokken order en knop of procedure om opnieuw te verwerken. Maak duidelijk wie reageert en wanneer een automatische retry stopt.

#4. Test een volledige matrix

Test in een testomgeving minstens: geslaagde en mislukte betaling, annulering, volledige en gedeeltelijke refund, dubbele webhook, kortingscode, twee btw-tarieven, verzendkosten, B2B-order met btw-nummer, B2C-order, voorraadconflict en een tijdelijk onbereikbaar systeem. Controleer het resultaat in alle systemen én de settlement naar de bank.

#5. Ga gecontroleerd live

Start desnoods met een beperkte productgroep of controleer de eerste transacties dagelijks. Vergelijk aantallen en bedragen uit webshop, provider en boekhouding. Bewaar de handmatige werkwijze voor een storing en wijzig API-sleutels via een afgesproken beveiligd proces.

#6. Meet uitzonderingen, niet alleen succes

Een dashboard met “99% verwerkt” kan één dure fout verbergen. Volg daarom ook openstaande uitzonderingen, ouderdom van fouten, dubbel geweigerde gebeurtenissen en het verschil op de provider-tussenrekening. Plan periodiek een volledige reconciliatie, ook als de realtime koppeling groen lijkt.

#Wanneer is maatwerk zinvol?

Een standaardconnector past meestal als je één webshop, één administratie, eenvoudige btw-regels en een beperkt retourproces hebt. Maatwerk wordt logischer bij meerdere verkoopkanalen, B2B-prijsafspraken, een ERP als voorraadbron, gedeeltelijke leveringen, meerdere administraties of regels die een standaardconnector niet kan uitleggen.

Vraag in beide gevallen om een demonstratie met jouw uitzonderingen en om een exporteerbaar foutenoverzicht. Controleer wie eigenaar is van de configuratie en data, hoe updates worden getest en hoe je kunt overstappen. Op de Brisk-pagina over koppelingen zie je hoe een API-koppeling wordt opgebouwd; voor de bredere platformkeuze helpt de vergelijking Shopify, WooCommerce of maatwerk.