Webshop en ERP koppelen: complete gids voor Belgische bedrijven

Als uw webshop, ERP en marketplaces elk een ander cijfer tonen voor dezelfde voorraad, dan zit u in goed gezelschap. Het is veruit het meest voorkomende operationele knelpunt bij Belgische retailers, groothandels en logistieke bedrijven die voorbij Excel willen groeien — en het is ook een van de slechtst geadviseerde projecten op de Belgische markt.

Deze gids is geen marketingmateriaal. Het is een werkdocument, opgebouwd uit tientallen integratieprojecten, audits en overnames van koppelingen die initieel door een andere leverancier of intern werden gebouwd. Gebruik hem vóór de bouw begint — niet erna.

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:

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

Als u twijfelt of uw huidige setup deze fundamenten heeft, doe dan eerst de gratis [Operations Check](/operations-check) (3 minuten) of plan een [Operations Audit](/services/operations-audit) — dan weet u in 2 weken precies waar de gaten zitten.

---

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.

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?](/blog/when-to-move-from-excel-to-integrations).

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.
• U heeft één of meer medewerkers die meer dan 30% van hun tijd besteden 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 in 2 weken een concreet beeld van wat de top 3 bottlenecks zijn, met een ROI-inschatting per actie.

---

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-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](/blog/multichannel-sync-webshop-bol-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](/blog/leveranciersdata-normaliseren-voor-publicatie-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](/blog/boekhoudsoftware-koppeling-winbooks-exact-yuki-octopus).

Patroon 3: Peppol staat op de roadmap maar is nog niet aangesloten. Met de verplichting in 2026 wordt dit snel een probleem. Zie [Peppol e-facturatie in België: wat u moet weten](/blog/peppol-verplichte-e-facturatie-belgie-wat-u-moet-weten).

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](/blog/voorraadbeheer-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](/blog/manueel-proces-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. De investering in een solide architectuur, goede testdekking en proactieve monitoring verdient zichzelf altijd terug. Begin met de juiste fundering, en bouw van daaruit verder.

Als u twijfelt of uw huidige koppeling deze fundamenten heeft, of als u overweegt een nieuwe integratie te starten en niet zeker bent waar te beginnen, zijn er twee laagdrempelige eerste stappen:

• Doe de [gratis Operations Check (3 minuten)](/operations-check) — 20 vragen die u helpen zelf te zien waar de operationele bottlenecks zitten.
• Plan een [Operations Audit](/services/operations-audit) — in 2 weken brengen we uw operatie, systemen en automatiseringskansen in kaart. Schriftelijk rapport, 90-dagen actieplan, geld-terug garantie als we minder dan 2 verbeterpunten vinden.

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.