Een ERP-koppeling is allang geen technisch bijzaakje meer, maar de ruggengraat van je e-commerce operatie. Toch zien we nog steeds trajecten waarin het koppelen van ERP, WMS of PIM aan de webshop een half jaar duurt, terwijl het echte werk in die maanden niet het programmeren was. Het was het uitzoeken van veldnamen, het heen en weer mailen over wie welke waarde beheert, en het uitschrijven van mappings die niemand na oplevering nog durft aan te raken. Precies dat deel hebben wij geautomatiseerd met een eigen AI-systeem. Hieronder lees je hoe een koppeling technisch in elkaar zit, waar integraties in de praktijk stuklopen, en waarom de doorlooptijd tegenwoordig veel meer wordt bepaald door beslissingen dan door code.
Wat is een ERP-koppeling precies?
Een ERP-koppeling is een geautomatiseerde verbinding tussen je ERP-systeem en je webshop, waarin beide kanten continu dezelfde gegevens delen: artikelen, prijzen, voorraad, orders, klanten en facturen. In plaats van dat iemand ordergegevens overtypt of dagelijks een CSV importeert, gaat de uitwisseling via de API van beide systemen, meestal binnen enkele seconden na een gebeurtenis.
Dat klinkt eenvoudiger dan het is, omdat een koppeling in de praktijk uit drie lagen bestaat. De eerste laag is de verbinding: authenticatie, transport, foutafhandeling en het respecteren van limieten. De tweede laag is de vertaling, waarin het datamodel van het ERP wordt omgezet naar dat van je webshop. De derde laag zijn de afspraken: welk systeem is eigenaar van welk veld, en wat gebeurt er als twee kanten tegelijk iets wijzigen.
De eerste laag is standaardwerk dat bij elke integratie hetzelfde is. De tweede laag is waar een AI-systeem het verschil maakt. De derde laag is mensenwerk en blijft dat, hoe goed de modellen ook worden.
ERP, WMS, PIM en OMS: wie is eigenaar van welk veld?
De meeste mislukte integraties zijn niet stukgelopen op techniek, maar op eigenaarschap. Voordat er één regel code geschreven wordt, moet vastliggen welk systeem de waarheid bezit over welk gegeven. Vier systemen strijden daarom om dezelfde velden.
- ERP (Exact Online, AFAS, Microsoft Dynamics 365 Business Central, Odoo, SAP): financiën, inkoop, artikelstam, kostprijzen en facturatie. Meestal de bron van waarheid voor artikelnummer, basisprijs en btw-code.
- WMS, het warehouse management systeem: fysieke voorraad, locaties, batches, pick- en verzendprocessen. De enige plek die weet wat er daadwerkelijk op de plank ligt.
- PIM, het pim systeem: productteksten, vertalingen, specificaties, beeldmateriaal en assortiment per markt. De bron van waarheid voor alles wat de klant leest en ziet.
- OMS: orderorchestratie zodra je meerdere verkoopkanalen en magazijnen hebt, en iets moet bepalen waar een order vandaan geleverd wordt.
De gouden regel: elk veld heeft precies één eigenaar. Zodra twee systemen hetzelfde veld mogen schrijven, is het geen kwestie van of het misgaat, maar wanneer. Shopify beschrijft in zijn eigen architectuurdocumentatie voor enterprise-orderbeheer drie patronen die je kunt kiezen: een extern OMS dat leidend is en Shopify alleen voedt met één beschikbaar-om-te-verkopen aantal per SKU, een hybride model, of Shopify zelf als orchestrator. Alle drie werken. Wat niet werkt, is er geen kiezen.
Waarom een webshop koppeling in 2026 anders werkt dan in 2020
Wie de laatste jaren niet in de Shopify-documentatie heeft gekeken, bouwt nu koppelingen op fundamenten die aan het verdwijnen zijn. Drie dingen zijn wezenlijk veranderd.
Om te beginnen is REST verleden tijd. De REST Admin API is sinds 1 oktober 2024 een legacy-API, en sinds 1 april 2025 moeten alle nieuwe publieke apps op de GraphQL Admin API gebouwd worden. Een koppeling die vandaag nog op REST-endpoints leunt, is technische schuld met een houdbaarheidsdatum.
Daarnaast rekenen de limieten in kosten in plaats van in requests. De GraphQL Admin API werkt met berekende querykosten: 100 punten per seconde op standaardplannen, 200 op Advanced, 1.000 op Shopify Plus en 2.000 op Commerce Components. Eén losse query mag nooit meer dan 1.000 punten kosten, en een input-array is gemaximeerd op 250 elementen. Dat klinkt abstract tot je een catalogus van 40.000 SKU's moet verversen: een naïeve koppeling die per artikel één mutatie afvuurt, loopt op een standaardplan binnen een minuut vast. Wie op Shopify Plus zit, heeft tien keer zoveel ruimte, maar ook daar wint een slim gebouwde koppeling het van een snelle.
Tot slot is er inmiddels een mutatie die precies voor jouw situatie is gemaakt. Shopify ontwierp productSet voor het geval dat een extern systeem de bron van waarheid is, en noemt daarbij letterlijk het ERP, het PIM, een spreadsheet of een eigen database. Je stuurt de volledige gewenste staat van een product en Shopify maakt zijn eigen data daaraan gelijk. Let op de keerzijde: lijstvelden die je niet meestuurt, zoals varianten, metafields en collecties, worden verwijderd. Je moet die mutatie dus altijd volledig vullen, nooit half. Voor de initiële lading en grote periodieke updates gebruik je bulk-operaties: je levert een JSONL-bestand van maximaal 100 MB aan, Shopify verwerkt het asynchroon en zet het resultaat klaar als bestand. Sinds API-versie 2026-01 mag een app vijf van die bulk-mutaties tegelijk draaien per winkel, daarvoor was dat er één.
Voor voorraad geldt hetzelfde principe in het klein: schrijf absolute standen met inventorySetQuantities vanuit het systeem dat de waarheid kent, gebruik inventoryAdjustQuantities alleen voor mutaties waarvan je zeker weet dat je er nooit één mist, en draai daarnaast een periodieke reconciliatie.
Onze aanpak: systemen koppelen met een eigen AI-systeem
De reden dat integraties traditioneel maanden duren, is zelden de complexiteit van de code. Het is het volume aan saai, precies werk: honderden velden begrijpen, ze naast elkaar leggen, per veld een transformatie bedenken, dat documenteren, en dan pas bouwen. Dat is exact het soort werk waar taalmodellen goed in zijn, mits je ze de juiste input geeft en de uitkomst laat controleren door iemand die het snapt. Wij hebben daar een eigen systeem voor gebouwd dat we bij elk koppelingstraject inzetten.
Stap 1: alles wat over het andere systeem bekend is, gaat erin
We voeren het systeem alles wat er over de andere kant bestaat: de API-documentatie, een OpenAPI- of WSDL-bestand, een handvol echte payloads, een CSV-export uit het ERP en de veldenlijst uit het PIM. Ook een verouderd systeem zonder nette documentatie is bruikbaar, zolang we voorbeelden van echte data hebben. Daaruit bouwt het systeem een veldinventaris: welke velden bestaan er, welk type hebben ze, hoe vaak zijn ze gevuld en welke waarden komen er in de praktijk in voor. Die laatste twee zijn cruciaal, want documentatie beschrijft de bedoeling en echte payloads beschrijven de werkelijkheid. Het verschil daartussen is waar integraties sneuvelen.
Stap 2: de mapping komt als voorstel, niet als opdracht
Vervolgens legt het systeem die inventaris naast het datamodel van Shopify: producten, varianten, metafields, inventory levels, orders, en voor B2B ook companies en company locations. Per veld doet het een concreet voorstel inclusief de benodigde transformatie: prijzen van exclusief naar inclusief btw, gewichten van gram naar kilo, taal- en valutacodes, media-URL's, en de vraag of iets een metafield hoort te worden of juist een variant-optie. Wat eruit komt is een mappingdocument dat wij en jullie team regel voor regel nalopen. Die fase kostte vroeger weken aan workshops en ligt nu meestal binnen een dag op tafel.
Stap 3: code, tests en foutafhandeling in één beweging
Zodra de mapping akkoord is, genereert het systeem de transformatielaag: getypeerde code met validatie per veld, plus de infrastructuur eromheen. Die infrastructuur is bij vrijwel elke koppeling hetzelfde en daarom perfect te automatiseren: een wachtrij, herhaalpogingen met oplopende wachttijd, idempotentie op basis van de webhook-id, logging per record, en een overzicht van welke artikelen niet door de validatie kwamen. Tegelijk maakt het een testset uit de echte payloads van stap 1, zodat we kunnen draaien tegen data die we al kennen voordat er ooit een order doorheen gaat.
Stap 4: het laatste stuk is mensenwerk, en dat is precies het punt
Wat ons systeem niet oplost: welke prijsafspraak geldt voor welke B2B-klant, wat er moet gebeuren bij een deellevering, of het ERP of het WMS de baas is over voorraad, en of productteksten uit het PIM ongefilterd op de storefront mogen. Dat zijn geen technische vragen maar bedrijfsvragen, en die kun je niet uitbesteden aan een model. Het verschil met vroeger is dat onze developers hun tijd nu bijna volledig aan die vragen besteden in plaats van aan de tweehonderdste veldmapping. De eerste werkende sync staat daardoor meestal binnen een week in een testomgeving. De weken erna gaan op aan randgevallen, en dat is precies waar ze horen te gaan.
Een koppeling die in dagen staat, is niet sneller omdat er minder wordt nagedacht. Hij is sneller omdat het denkwerk eindelijk over de juiste dingen gaat.
Vijf plekken waar een ERP-koppeling in de praktijk stukloopt
Dit zijn de scenario's die we het vaakst tegenkomen wanneer we een bestaande integratie overnemen.
1. Twee systemen die allebei voorraad schrijven
Het ERP stuurt 's nachts een volledige stand, het WMS stuurt overdag mutaties, en niemand heeft vastgelegd wie wint. Overdag klopt het, de volgende ochtend niet meer. De oplossing is niet slimmer programmeren maar kiezen: één systeem schrijft absolute standen, de rest kijkt mee. Daarnaast draait er dagelijks een reconciliatie die standen vergelijkt en afwijkingen corrigeert. Shopify beveelt die reconciliatie zelf aan in zijn enterprise-documentatie, en terecht: drift is geen uitzondering maar een zekerheid.
2. Webhooks die te langzaam antwoorden
Shopify verwacht binnen vijf seconden een 200 OK en hanteert een connectietimeout van één seconde. Wie in diezelfde request de order naar het ERP probeert weg te schrijven, haalt dat op een drukke dag niet. Shopify probeert het dan opnieuw met steeds langere tussenpozen, en bij aanhoudende fouten wordt de subscriptie uiteindelijk verwijderd. Zo krijg je eerst dubbele orders en daarna stille gaten. Geef dus direct 200 terug, zet het bericht in een wachtrij en verwerk het daarna. Dedupliceer op de X-Shopify-Webhook-Id header en gebruik X-Shopify-Event-Id om deliveries van dezelfde handeling te herkennen. Een faalpercentage boven 0,5 procent is volgens Shopify al reden voor onderzoek.
3. Het ERP kent artikelnummers, Shopify kent varianten
Een ERP denkt in losse artikelen met een eigen nummer, Shopify denkt in producten met opties en varianten. Welke ERP-artikelen samen één product vormen, en welk veld de optiewaarde wordt, is de belangrijkste inhoudelijke beslissing van het hele traject. Neem die verkeerd en je bouwt hem later opnieuw, inclusief alle URL's en SEO-waarde die je onderweg verliest. Houd ook rekening met de standaardlimiet van 2.048 varianten per product.
4. Een eerste sync die niemand op volume heeft getest
Veertigduizend artikelen door een synchrone API duwen is geen kwestie van geduld maar van rekenwerk. Test de initiële lading op productievolume voordat je een livedatum afspreekt, en gebruik bulk-operaties in plaats van losse mutaties. Een bulk-mutatie moet bovendien binnen 24 uur klaar zijn, anders wordt hij afgebroken en begin je opnieuw.
5. Niemand kijkt ernaar totdat het misgaat
De meeste koppelingen hebben geen monitoring, alleen een mailbox waar foutmeldingen heen gaan die niemand leest. Wat er minimaal moet staan: een teller op verwerkte en gefaalde berichten per uur, een leeftijdsalarm op de wachtrij, en een dagelijks reconciliatierapport met het aantal verschillen. Een koppeling die stilvalt hoort binnen minuten bekend te zijn, niet pas als de klantenservice belt.
Standaard connector of maatwerk koppeling?
Niet elke situatie vraagt om maatwerk, en we verkopen het liever niet als het niet nodig is. Een kant-en-klare connector is de juiste keuze als je een standaard ERP gebruikt zoals Exact Online of AFAS, met standaardvelden, één markt, één magazijn en geen afwijkende prijslogica. Voor Exact hebben we die route apart uitgewerkt op onze pagina over de Shopify Exact koppeling.
Maatwerk wordt interessant zodra minstens één van deze dingen speelt:
- Je werkt met een eigen of verouderd ERP zonder moderne API.
- Je hebt klantspecifieke prijsafspraken of staffels in B2B.
- Je verkoopt in meerdere markten met eigen assortiment en vertalingen.
- Je PIM is leidend voor content en moet per markt uitrollen.
- Je WMS werkt met deelleveringen, batches of dropshipping.
- De connector dwingt je om je proces aan te passen aan de software.
De vuistregel die wij hanteren: een connector die 90 procent dekt en 10 procent handwerk overlaat, is duurder dan maatwerk zodra dat handwerk dagelijks terugkomt. Reken één keer uit wat dat handwerk per jaar kost aan uren en fouten, en de rekensom maakt zichzelf. Zit je nog op een ander platform, dan is het moment om te koppelen vaak hetzelfde moment als de migratie van Magento naar Shopify, omdat je dan toch al door je volledige datamodel heen loopt.
Zo ziet een koppelingstraject eruit
- 1Inventarisatie. Welke systemen doen mee, welke velden bestaan er, en wie is eigenaar van welk gegeven. Dagen, geen weken, omdat de veldinventaris automatisch wordt opgebouwd.
- 2Mapping en akkoord. Het voorstel per veld gaat regel voor regel langs jullie team. Hier vallen de beslissingen die later duur zijn om terug te draaien.
- 3Bouw en testsync. De koppeling draait op een ontwikkelomgeving tegen echte, geanonimiseerde data uit jullie eigen systemen.
- 4Schaduwdraaien. De koppeling draait mee op productie zonder te schrijven, en we vergelijken wat hij zou doen met wat er daadwerkelijk gebeurt. Deze fase wordt vaak overgeslagen en is precies de fase die dubbele orders voorkomt.
- 5Live met monitoring. Inclusief dagelijkse reconciliatie, alarmen en een dashboard waarop je zelf ziet wat er doorheen gaat.
Veelgestelde vragen over ERP-koppelingen
Wat is een ERP-koppeling?
Een ERP-koppeling is een geautomatiseerde verbinding tussen je ERP-systeem en je webshop, waarin artikelen, prijzen, voorraad, orders en klantgegevens automatisch worden uitgewisseld via de API van beide systemen. Het doel is één bron van waarheid per gegeven, zodat niemand nog gegevens hoeft over te typen.
Hoe lang duurt het bouwen van een ERP-koppeling?
Bij ons staat de eerste werkende sync meestal binnen een week in een testomgeving, omdat de veldinventaris en de mapping automatisch worden opgebouwd. De totale doorlooptijd tot live wordt daarna vooral bepaald door het aantal uitzonderingen in je proces, de datakwaliteit in het ERP en de snelheid waarmee beslissingen genomen worden. Reken op weken, niet op maanden, tenzij je datamodel zelf eerst opgeschoond moet worden.
Wat is het verschil tussen een ERP-, WMS- en PIM-koppeling?
Ze koppelen verschillende soorten waarheid. Een ERP-koppeling gaat over artikelen, prijzen, orders en facturen. Een WMS-koppeling gaat over fysieke voorraad, locaties en verzending. Een PIM-koppeling gaat over productcontent: teksten, vertalingen, specificaties en beeld. In grotere organisaties draaien alle drie tegelijk, waarbij elk systeem eigenaar is van zijn eigen velden.
Kan elk ERP-systeem gekoppeld worden aan Shopify?
In de praktijk vrijwel altijd, zolang er een API, een database of een geautomatiseerde export beschikbaar is. Moderne systemen bieden een REST- of GraphQL-API. Oudere systemen ontsluiten we via SFTP-bestandsuitwisseling of een directe databasekoppeling. Wat wel verschilt is de hoeveelheid werk: hoe minder het bronsysteem prijsgeeft, hoe meer logica er aan onze kant nodig is.
Wat kost een ERP-koppeling?
De prijs wordt bepaald door het aantal velden, het aantal richtingen waarin gesynchroniseerd wordt, de hoeveelheid uitzonderingen in je proces en de kwaliteit van je brondata. Een eenrichtingskoppeling voor voorraad is een fractie van een tweerichtingskoppeling die orders, facturen, klantspecifieke prijzen en retouren afhandelt. We geven een vaste prijs na de inventarisatiefase, zodat je geen open eind hebt. Een indicatie van wat een Shopify-traject kost vind je bij onze Shopify-trajecten.
Wat gebeurt er als de koppeling uitvalt?
Bij een goed gebouwde koppeling gebeurt er niets onherstelbaars. Berichten blijven in de wachtrij staan, worden na herstel alsnog verwerkt, en de idempotentie zorgt dat een dubbel binnengekomen bericht geen tweede order aanmaakt. De dagelijkse reconciliatie vangt op wat er tijdens de storing toch is misgelopen. Wat je wilt voorkomen is een koppeling zonder wachtrij, want daar zijn de berichten die tijdens de storing binnenkwamen definitief weg.
Klaar om je systemen te koppelen?
Werk je met een ERP, WMS of PIM dat nog niet praat met je webshop, of met een bestaande koppeling die te vaak stukloopt? Vertel ons welke systemen je gebruikt, dan laten we in de inventarisatiefase precies zien welke velden gekoppeld kunnen worden en wat dat oplevert. Wil je het hele traject in één keer goed doen, kijk dan ook naar wat er komt kijken bij een Shopify webshop laten maken of neem direct contact op.