Orders, klanten en voorraad blijven vanzelf gelijk tussen webshop en administratie. Een idempotente koppeling die nooit dubbel boekt, geen order laat vallen en fouten opvangt in plaats van negeert.
Voor een e-commerce merk bouwde ik de koppeling tussen webshop en boekhouding zo dat ze elkaar bijhouden zonder handwerk. Elke order stroomt van Shopify of WooCommerce naar Moneybird of Exact, klanten worden gematcht in plaats van dubbel aangemaakt en voorraad loopt de andere kant op terug. Het lastige aan zo een koppeling zit niet in de gelukkige route, maar in wat er misgaat: een webhook die twee keer binnenkomt, een order die precies tijdens een storing valt, een voorraadwijziging die de andere overschrijft. De demo hieronder toont de sync als een dashboard. De opzet erachter is gebouwd om juist die randgevallen netjes op te vangen.
Vereenvoudigde demo met voorbeelddata · een voorproef, geen volledig product
De webshop wist alles van orders en klanten, de boekhouding wist alles van facturen en voorraad, en tussen die twee zat een mens met een export en een importknop. Dat werkte totdat het volume groeide: een order die niet werd overgezet, een klant die dubbel in de administratie stond, voorraad die in de shop nog op voorraad zei terwijl het magazijn leeg was. Elke handmatige export is een moment waarop iets kan worden vergeten of dubbel gedaan, en elke fout kost of een verkeerde factuur of een misgelopen verkoop.
Orders en klanten stromen van de shop naar de administratie, voorraad stroomt terug. Beide kanten kijken naar dezelfde gegevens in plaats van naar hun eigen kopie.
De koppeling is idempotent: dezelfde order die twee keer binnenkomt levert nog steeds één factuur op. Geen dubbele boekingen, geen dubbele klanten.
Wat misgaat verdwijnt niet stil. Een mislukte sync gaat in de wachtrij, probeert het opnieuw en meldt zich als het echt vastloopt.
De keuzes achter de demo, eerlijk uitgelegd. Dit is de opzet zoals ik hem in de praktijk bouw, geen afgeschermde black box.
De shop stuurt een webhook bij elke nieuwe of gewijzigde order, maar ik verwerk die niet meteen. Ik zet elke gebeurtenis eerst in een duurzame wachtrij, want webhooks komen in de praktijk soms dubbel, in de verkeerde volgorde of tijdens een storing helemaal niet aan. Die wachtrij is de buffer die dat opvangt: hij ontkoppelt het ontvangen van het verwerken, zodat een piek aan orders of een korte storing aan de boekhoudkant nooit betekent dat er iets verloren gaat.
Elke order krijgt een stabiele externe sleutel, het order-id uit de shop, en daarop dedupliceert de verwerking. Komt dezelfde webhook twee keer binnen, dan herkent de koppeling dat het om dezelfde order gaat en maakt geen tweede factuur aan. Ik bouw dit expliciet in omdat webhooks een at-least-once belofte doen, niet exactly-once: het systeem moet er dus zelf voor zorgen dat dubbel afleveren geen dubbel boeken wordt. Dit is de kern waarom de koppeling betrouwbaar is en niet alleen meestal klopt.
Een webshop en een boekhoudpakket spreken niet dezelfde taal: btw-tarieven, productcodes, betaalmethodes en de manier waarop een klant wordt geïdentificeerd verschillen per systeem. Ik bouw een expliciete mappinglaag die een Shopify- of WooCommerce-order vertaalt naar een correcte verkoopfactuur in Moneybird of Exact, en die een bestaande klant matcht op e-mail of KvK-nummer in plaats van er een nieuwe naast te zetten. Die laag maak ik zichtbaar en aanpasbaar, omdat de regels per merk net anders liggen en je ze wilt kunnen bijstellen zonder de koppeling open te breken.
Voor voorraad loopt de sync de andere kant op: de administratie of het magazijnsysteem is vaak de bron van waarheid en die waarde stroomt terug naar de shop. Omdat twee systemen tegelijk hetzelfde veld kunnen willen aanpassen, leg ik per veld vast wie wint, zodat ze elkaar niet blindelings overschrijven. Ik kies deze richting bewust omdat een shop die te veel voorraad toont oververkoopt en een shop die te weinig toont omzet misloopt, en beide fouten voorkom je alleen met een heldere regel over welke kant leidend is.
Een sync die na een paar pogingen blijft falen verdwijnt niet in stilte, maar gaat naar een dead-letter-wachtrij met oplopende wachttijd tussen de pogingen en een melding naar de juiste persoon. Daarnaast toont een dashboard wat wel en niet is doorgekomen, zodat je niet hoeft te vertrouwen dat het goed gaat maar het kunt zien. Ik bouw dit omdat een gemiste order pas een echt probleem wordt op het moment dat je hem te laat ontdekt, en zichtbaarheid dat moment naar voren haalt.
Orders en klanten heen, voorraad terug, allebei automatisch.
Dezelfde order twee keer aangeboden wordt nog steeds één factuur.
Een mislukte sync probeert het opnieuw met oplopende wachttijd.
Productcodes, btw-tarieven en klantmatching netjes vertaald.
Zie in één oogopslag wat er doorkwam en wat vastloopt.
Een order die echt vastzit meldt zich in plaats van te verdwijnen.
Deze case koppelt aan bestaande systemen. Een paar van de integraties die hierbij passen, allemaal op maat te koppelen.
Elk onderdeel werkt op zichzelf, maar wordt sterker in combinatie. Een paar voorbeelden uit de praktijk:
Van bestelling tot geboekte factuur, zonder handwerk.
Overal dezelfde, actuele cijfers.
Gidsen die dieper op dit onderwerp ingaan.
Deze case is een referentie-build voor API-integraties & koppelingen. Bekijk hoe ik dat aanpak, of doe de gratis Automatiseringsscan en zie in twee minuten waar bij jou de winst zit.
Vertel me wat je voor ogen hebt of waar je tegenaan loopt, dan denk ik mee en zeg ik eerlijk wat er kan, vrijblijvend.
