Webshop koppelen met ERP: complete gids voor Belgische bedrijven

Uw webshop koppelen met uw ERP — of "linken" of "synchroniseren", hoe u het ook noemt — bepaalt of orders, voorraad, prijzen en klantdata zonder dubbel werk tussen beide systemen doorstromen. Als uw webshop, ERP en marketplaces elk een ander cijfer tonen voor dezelfde voorraad, vraagt dat telkens manuele controle en correctie.

Deze gids helpt u de belangrijkste keuzes vóór de bouw vast te leggen: eigenaarschap per veld, synchronisatiepatronen, foutafhandeling, testen, monitoring en livegang.

TL;DR voor wie weinig tijd heeft#

Een goede webshop ↔ ERP koppeling is geen technisch project — het is een operationeel project met technische uitvoering. De top 5 zaken die het succes bepalen:

1. Eigenaarschap per veld — wie is de bron van waarheid voor prijs, voorraad, klantdata? Zonder dit antwoord wordt elke integratie chaotisch.
2. Synchronisatiepatroon per datatype — voorraad realtime, productdata in batch, klantdata bij wijziging. Niet alles hoeft direct.
3. Foutafhandeling vanaf dag 1 — retrylogica, dead-letter queues, alerting. Een koppeling zonder dit is een tijdbom.
4. Monitoring vóór livegang — als u pas ziet dat het mis is wanneer een klant belt, dan loopt u maanden achter de feiten aan.
5. Gefaseerde go-live — eerst één categorie, dan opschalen. Big-bang livegangen mislukken vaak en zijn moeilijk terug te draaien.

Wilt u een bestaande koppeling stabiliseren of een nieuwe laten bouwen? Bekijk dan eerst hoe ZenDev webshop en ERP koppelt. Wilt u nog bepalen waar het grootste knelpunt zit, doe dan de gratis Operations Check (3 minuten).

---

Wat verstaan we onder een webshop ↔ ERP koppeling?#

Een koppeling tussen webshop en ERP is in essentie een systeem dat data automatisch laat stromen tussen twee (of meer) softwarepakketten zodat uw team het niet meer handmatig hoeft over te zetten. In de praktijk gaat het meestal om vier datadomeinen:

• Productdata — titels, beschrijvingen, prijzen, varianten, afbeeldingen. Hoort meestal thuis in een PIM of ERP en moet naar de webshop.
• Voorraad — beschikbaarheid per locatie, gereserveerde stock, ingaande bestellingen. Cruciaal omdat oversells direct klanten kosten.
• Klantdata — accounts, adresboeken, klantgroepen, kredietlimieten. Vooral belangrijk voor B2B-webshops.
• Orders — orderlijnen, betaalstatus, verzendstatus, retours. Stroom van webshop naar ERP en terug.

Voorbeeld: één order door de volledige koppeling#

Een bestelling voor twee stuks van SKU B-104 maakt concreet welke afspraken nodig zijn:

De tabel maakt ook het eigenaarschap zichtbaar: de webshop bezit de checkout, maar mag niet zelf bepalen hoeveel fysieke voorraad nog verkoopbaar is. Dat blijft bij ERP of WMS.

Het lijkt alsof er één standaardoplossing voor moet bestaan, maar in de praktijk verschilt elke koppeling significant afhankelijk van uw ERP, uw webshop, uw productcomplexiteit en uw operationele realiteit. Zelfs binnen één ERP-familie (bijvoorbeeld Odoo of Exact) zijn er per bedrijf verschillen in customisations, velden en workflows die de integratie raken.

Wilt u meer concrete signalen dat het tijd is om Excel achter te laten? Lees Excel vervangen door software: wanneer is het tijd?.

Wanneer is uw bedrijf eraan toe?#

Niet elk bedrijf heeft een ERP-webshop koppeling nodig. Soms is goed Excel-werk plus een eenvoudige API voldoende. De juiste vraag is niet "kunnen we het bouwen?" maar "wat kost het ons om het niet te bouwen?"

Signalen dat u rijp bent voor een koppeling:

• U verkoopt via minstens twee kanalen (webshop + marketplace, of webshop + B2B-portaal) en voorraad klopt regelmatig niet.
• Eén of meer medewerkers besteden structureel tijd aan data overzetten of corrigeren tussen systemen.
• U heeft al eens verkocht wat u niet kon leveren (oversells), of klanten geleverd op verouderde prijzen.
• Uw boekhouding krijgt orderdata dagen of weken na verkoop, waardoor cashflow- en btw-rapportering vertraagd is.
• U overweegt uitbreiding naar Bol.com, Amazon of een nieuw B2B-segment, en uw huidige setup zou daaronder bezwijken.

Als u deze gids leest met een glimlach van herkenning, dan ligt het ROI-pad waarschijnlijk dichter dan u denkt. Een Operations Audit van ZenDev geeft u een concreet beeld van wat uw grootste bottlenecks zijn.

---

1. Datamodellen en eigenaarschap definiëren#

De meest fundamentele vraag bij elke integratie is: wie is de bron van waarheid voor welk veld? Klinkt eenvoudig, maar in de praktijk leidt onduidelijkheid hierover tot conflicten, overschrijvingen en data-inconsistentie.

Wat u moet vastleggen:

• Per datadomein (productdata, prijzen, voorraad, klanten, orders) bepaalt u welk systeem de master is — ERP, webshop of middleware.
• Wie mag een veld wijzigen? Een prijs die in het ERP wordt bijgewerkt mag niet door de webshop worden overschreven, en vice versa.
• Documenteer expliciete field-mappings: hoe vertaalt een ERP-artikel naar een webshop-product? Wat gebeurt er met BTW-codes, eenheden, varianten en afbeeldingen?
• Identificeer velden die in beide systemen bestaan maar anders heten of anders zijn geformatteerd — dit zijn de meest voorkomende bronnen van synchronisatiefouten.

Speciaal voor groothandels: klantgroepen, staffelprijzen en contractprijzen zijn vrijwel altijd master in het ERP. De webshop ontvangt deze data, maar de logica zit elders. Zie ook onze pagina Voor groothandels voor wat we specifiek voor deze sector bouwen.

Resultaat: een data-ownershiptabel die voor elk systeem en elk veld aangeeft wie schrijft, wie leest en wie valideert.

2. Synchronisatiepatronen kiezen#

Niet alle data heeft dezelfde tijdsgevoeligheid. Realtime synchronisatie voor alles is technisch mogelijk maar operationeel riskant en duur. Een goede integratiearchitectuur differentieert op basis van urgentie en volume.

Realtime of near-realtime (event-driven):

• Voorraadwijzigingen na orderplaatsing — klanten mogen niet bestellen wat er niet is.
• Orderbevestigingen richting ERP — verwerking moet direct starten.
• Prijswijzigingen bij tijdgevoelige acties of contractprijzen.

Geplande synchronisatie (batch/polling):

• Productcatalogus updates — dagelijks of uurlijks is voor de meeste webshops voldoende.
• Klantdata en accountwijzigingen — minder tijdskritisch.
• Historische orderdata voor rapportering.

Wat u technisch moet voorzien:

• Wachtrijen (queues) — gebruik een message queue (RabbitMQ, SQS, of een eenvoudiger alternatief) voor alle asynchrone communicatie. Dit isoleert systemen van elkaar en biedt retrycapaciteit bij storingen.
• Idempotentie — zorg dat elke operatie meerdere keren uitgevoerd kan worden zonder ongewenste bijwerkingen. Een order twee keer aanmaken in het ERP is een kritische fout.
• Backpressure — wat gebeurt er als het ERP trager is dan de webshop events genereert? Ontwerp voor piekmomenten, niet voor gemiddeld gebruik.

Bij multichannel-verkoop wordt deze keuze nog kritischer. Voor wie ook op marketplaces verkoopt, raden we onze gids Multichannel sync tussen webshop, Bol.com en marketplaces aan.

3. Foutafhandeling en retrylogica#

Een integratie zonder expliciete foutafhandeling is een integratie die vroeg of laat stilzal vallen — en het dan niet vanzelf opnieuw zal proberen. Fouten zijn geen uitzonderingen; ze zijn een normaal onderdeel van gedistribueerde systemen.

Categoriseer uw fouten:

• Tijdelijke fouten (netwerktimeout, service tijdelijk down): automatisch retrybaar met exponentiële backoff.
• Validatiefouten (ongeldige data, ontbrekende velden): niet retrybaar zonder menselijke interventie. Stuur naar een dead-letter queue of foutlog.
• Businesslogicafouten (prijs buiten acceptabel bereik, onbekende klantcode): vereisen eigenaarsdefinitie — wie lost dit op?

Retrybeleid:

• Eerste retry na 30 seconden, daarna 5 minuten, 30 minuten, 2 uur. Niet oneindig herhalen — na een maximumaantal pogingen markeren als failed en alerteren.
• Zorg dat retries niet leiden tot dubbele verwerking. Dit is waar idempotentie cruciaal is.

Dead-letter queue:

• Berichten die na het maximumaantal retries nog altijd falen, komen in een dead-letter queue. Hier kunnen operators ze inspecteren, corrigeren en manueel herstarten.

Operationeel inzicht voorzien: een dead-letter queue zonder iemand die er dagelijks naar kijkt, is een zwart gat. Definieer expliciet wie deze opvolgt en wat de SLA is voor het oplossen van geblokkeerde berichten.

4. Teststrategie uitwerken#

Integraties zijn notoir moeilijk te testen omdat ze afhankelijk zijn van externe systemen. Maar een gebrek aan testdekking is de snelste weg naar een verborgen bug die weken later in productie opduikt.

Unit tests:

• Test transformatie- en mappinglogica geïsoleerd. Geef een ERP-object als input, verwacht een webshop-object als output. Geen externe calls.

Integratietests:

• Test de volledige flow end-to-end met echte (test)systemen. Gebruik een staging-omgeving van zowel ERP als webshop.
• Test specifiek de randgevallen: lege velden, maximale waarden, speciale karakters in productnamen, negatieve voorraad.

Scenario-tests:

• Simuleer een volledige orderflow: product aanmaken in ERP → zichtbaar in webshop → order geplaatst → order verwerkt in ERP → voorraad bijgewerkt.
• Test herstelscenario's: wat als de ERP-connectie wegvalt tijdens een ordersync? Herstelt het systeem automatisch?

Speciaal voor groothandels en multichannel: voeg een testscenario toe voor leveranciersfeeds die plots wijzigen of vertragen. Zie ook Leveranciersdata normaliseren voor publicatie naar webshop.

5. Monitoring en observability#

Een integratie die werkt zonder monitoring is een integratie die u pas ziet falen als klanten het u melden. Zet monitoring op vóór livegang, niet erna.

Wat u wil meten:

• Doorvoersnelheid (throughput): hoeveel berichten worden per minuut verwerkt? Een plotse daling signaleert een probleem.
• Foutpercentage: het percentage berichten dat mislukt. Zelfs 1% kan bij hoge volumes betekenen dat honderden orders niet verwerkt worden.
• Latency: hoe lang duurt het gemiddeld voordat een event verwerkt is? Stijgende latency wijst op overbelasting of bottlenecks.
• Queue diepte: hoe groot is de backlog? Een groeiende queue zonder afname is een alarmsignaal.

Alerting:

• Stel drempelwaarden in voor elk van bovenstaande metrics.
• Werk met prioriteitslagen: kritieke alerts (orderverwerking gestopt) gaan direct naar een on-call persoon; waarschuwingen (latency stijgt) mogen naar een dashboard of e-mail.
• Definieer expliciete verantwoordelijkheden: wie krijgt welk alert? Wie is responsible voor triagering?

Operationeel dashboard: geef uw team toegang tot een eenvoudig dashboard dat de gezondheid van de integratie toont. Niet alle alerts hoeven naar techniek — operations en sales hebben vaak het beste zicht op of cijfers kloppen.

6. Go-live strategie#

De go-live van een integratie is niet het eindpunt — het is het begin van de productieomgeving. Een zorgvuldige go-live beschermt u tegen een kettingreactie van fouten die moeilijk terug te draaien zijn.

Gefaseerde uitrol:

• Begin met een subset van data: één productcategorie, één klantgroep, één magazijnlocatie. Valideer, corrigeer en schaal dan op.
• Run parallelle systemen tijdelijk naast elkaar — het oude manuele proces blijft beschikbaar als vangnet.

Rollbackplan:

• Definieer vóór de go-live wat de drempel is om terug te draaien. Hoeveel fouten per uur? Welke kritieke flows moeten werken?
• Test het rollbackscenario. Een rollbackplan dat niet getest is, is geen plan.

Hypercare-periode:

• Plan de eerste twee weken na go-live als hypercare: hogere alerting-gevoeligheid, dagelijkse statusreviews, directe beschikbaarheid van het ontwikkelteam.
• Communiceer proactief naar interne teams: wat wordt gemonitord, wat zijn de escalatiepaden?

7. Documentatie en kennisoverdracht#

Integraties die niet gedocumenteerd zijn, worden black boxes. Wanneer een engineer vertrekt of een systeem geüpdatet wordt, is documentatie het verschil tussen een gecontroleerde wijziging en een nachtmerrie.

Wat u documenteert:

• Dataflow-diagram: welk systeem stuurt wat naar welk systeem, via welk mechanisme.
• Field-mapping tabel: ERP-veld → webshop-veld, inclusief transformatieregels.
• Foutcodes en hun betekenis, met bijbehorende acties.
• Escalatieprocedure bij incidenten.

Onboarding van nieuwe medewerkers: een integratie waarvan alleen de oorspronkelijke bouwer de werking kent, is een operationeel risico. Zorg dat nieuwe medewerkers binnen 2 weken een redelijk beeld kunnen krijgen van het systeem.

---

Waar de meeste Belgische bedrijven vastlopen#

In onze audits en overnames zien we een aantal patronen terugkeren bij koppelingen die niet werken zoals ze zouden moeten:

Patroon 1: De koppeling werd gebouwd zonder eigenaarschapsdefinitie. Twee systemen schrijven naar hetzelfde veld, conflicten worden "opgelost" door de laatste-schrijver-wint, en niemand begrijpt waarom prijzen of voorraad af en toe ineens veranderen.

Patroon 2: De boekhouding is een eiland. Webshop en ERP zijn gekoppeld, maar de boekhouding (Winbooks, Exact, Yuki, Octopus) krijgt orderdata pas weken later. Voor wie hier in zit: lees Boekhoudsoftware koppelen aan uw webshop of ERP.

Patroon 3: Peppol is technisch aangesloten, maar niet operationeel opgevolgd. De Belgische B2B-verplichting geldt sinds 1 januari 2026. Afleverfouten, inkomende documenten en goedkeuring moeten daarom deel zijn van de dagelijkse werking. Zie Peppol en e-facturatie in België sinds 2026.

Patroon 4: Voorraad over meerdere magazijnen wordt niet correct geconsolideerd. Beschikbaarheid, gereserveerd en in-transit zitten in verschillende systemen zonder coherent overzicht. Lees Voorraadbeheer over meerdere magazijnen synchroniseren.

Patroon 5: Manuele processen werden gewoon gedigitaliseerd, niet heroverwogen. Een PDF werd een PDF in een API call. De winst is minimaal. Lees Manuele processen digitaliseren: stappenplan.

---

Conclusie en concrete eerste stap#

Een ERP-webshop integratie die crasht tijdens Black Friday of piekseizoen is niet alleen een technisch incident — het is een commercieel risico. Of de investering rendeert, hangt af van uw volumes, huidige manuele kost en de impact van fouten. Leg die uitgangspunten vooraf vast en bouw van daaruit verder.

Als u twijfelt of uw huidige koppeling deze fundamenten heeft, of als u een nieuwe integratie overweegt, kies dan het startpunt dat bij uw vraag past:

• Bekijk ERP-webshop koppelingen door ZenDev — voor een koppeling die u wilt laten bouwen, uitbreiden of stabiliseren.
• Doe de gratis Operations Check (3 minuten) — om eerst zelf te bepalen waar de operationele bottlenecks zitten.
• Bekijk de Operations Audit — voor een bredere analyse van uw operatie, systemen en automatiseringskansen.

Wij zijn ZenDev, een Belgisch team dat zich specifiek richt op retail-, groothandels- en logistieke bedrijven die voorbij Excel willen groeien. Geen template-projecten, geen PowerPoint-consultancy — werkende systemen die uw operatie volgen, niet andersom.