De meeste groothandelsmerken maken op dezelfde manier kennis met EDI: een inkoper van een grote retailer mailt dat orders vanaf volgend seizoen via EDI binnenkomen en dat leveranciers daaraan moeten voldoen. Er hangt een deadline aan, er zit een pdf met technische specificaties bij en de naam van een provider waar je nog nooit van hebt gehoord.

Die mail moet je serieus nemen, maar je beantwoordt hem ook beter niet overhaast. Voor sommige handelsrelaties is EDI echt verplicht, voor andere is het volkomen overbodig, en dat verschil scheelt duizenden euro's per jaar plus maanden implementatie. Leveranciers gaan hier in beide richtingen de mist in: ze zien de eis van één retailer als reden om hun hele orderinstroom om te gooien, of ze negeren hem tot het account op de tocht staat.

In deze gids lees je wat EDI precies is, welke documenten je moet kunnen ondersteunen, wat onboarding echt inhoudt, hoe EDI verschilt van een API-integratie en hoe je bepaalt welke van de twee jouw bedrijf nodig heeft.

Wat is EDI?

EDI staat voor Electronic Data Interchange. Het is een gestandaardiseerde manier waarop twee bedrijven zakelijke documenten uitwisselen, zoals inkooporders, orderbevestigingen, verzendmeldingen en facturen. Dat gaat van computer naar computer, in een vast formaat, zonder dat iemand iets hoeft in te typen of te mailen.

Het idee is ouder dan het internet. Grote retailers en fabrikanten moesten miljoenen orders tussen mainframes uitwisselen, dus sprak de sector strikte documentformaten af: elk veld op een vaste positie, elk documenttype een eigen nummer. Het systeem van een leverancier maakt een bestand in precies dat formaat en verstuurt het via een beveiligd kanaal, waarna het systeem van de retailer het inleest zonder dat er een mens aan te pas komt.

Daarom is EDI nog altijd dominant in levensmiddelen, farmacie, doe-het-zelf, automotive en grootschalige retail. Modern is het niet, en niemand zou het vandaag nog zo ontwerpen. Maar het is betrouwbaar, het is geaudit en het zit al ingebakken in de systemen van elke grote winkelketen. Zegt een inkoper "we hebben je op EDI nodig", dan betekent dat: hun ERP accepteert alleen orders in dat formaat, en handmatige orderinvoer is aan hun kant geen optie.

De EDI-documenten waar je echt om gevraagd wordt

Er zijn twee gangbare standaarden. ANSI X12 wordt vooral in Noord-Amerika gebruikt en duidt documenten aan met een nummer. UN/EDIFACT is de internationale standaard, veelgebruikt in Europa, en duidt ze aan met een naam. Retailers geven aan welke ze gebruiken, en meestal heb je maar vier of vijf documenttypes nodig.

De EDI 850 is gewoon een inkooporder in machineleesbare vorm: dezelfde informatie, dezelfde commerciële betekenis, alleen een andere verpakking. Snap je al hoe een PO door je bedrijf loopt, dan snap je ook het grootste deel van wat EDI doet.

Het verzendbericht is meestal het document waar leveranciers over struikelen. Je moet precies beschrijven hoe de zending is verpakt: welke artikelen in welke doos zitten, op welke pallet, elk met een label met een serial shipping container code. Dat is een aanpassing van je magazijnproces, niet alleen een dataformaat, en het is de meest voorkomende reden dat EDI-projecten langer duren dan gepland.

Zo werkt EDI in de praktijk

Voordat er ook maar één order doorkomt, moeten drie dingen geregeld zijn.

Een verbinding. Documenten gaan via een beveiligd kanaal, meestal AS2, SFTP of een Value Added Network (VAN) dat werkt als een beheerd postkantoor tussen handelspartners. De meeste leveranciers regelen dit via een EDI-provider in plaats van het zelf te bouwen.

Een mapping. Wat jouw systeem onder een order verstaat en wat de retailer eronder verstaat, moet veld voor veld in elkaar worden vertaald. Dat is het echte werk, en dat doe je per handelspartner: elke retailer implementeert de standaard net iets anders, met eigen verplichte velden, eigen codes en eigen eigenaardigheden. "EDI-ready" zijn voor de ene retailer betekent niet dat je klaar bent voor de volgende.

Certificering. Voordat je live gaat, stuur je testdocumenten en controleert het team van de retailer die aan de hand van hun specificatie. Reken op een paar rondes. Grotere retailers hebben formele complianceprogramma's, en sommige leggen terugboekingen of boetes op als documenten te laat zijn, fouten in de opbouw bevatten of niet overeenkomen met de fysieke levering.

Doorlooptijden verschillen sterk per retailer en provider, maar een eerste EDI-koppeling duurt van kick-off tot livegang vaak zes tot twaalf weken. Volgende partners gaan sneller zodra jouw kant staat. De kosten bestaan meestal uit setupkosten per partner, een maandelijks platformabonnement en soms een tarief per document of per kilokarakter. Vraag een volledige offerte aan waarin ook de tweede en derde handelspartner zijn meegenomen: de eerste is zelden de dure.

EDI vs. API: wat is het verschil?

Allebei verplaatsen ze data tussen systemen zonder dat iemand iets hoeft in te typen. Het verschil zit in leeftijd, vorm en voor wie ze zijn gebouwd.

Het praktische verschil: met EDI legt een grote klant jou een formaat op, met een API koppel je je eigen systemen aan elkaar. Ze lossen verschillende problemen op, en voor de meeste groothandelsmerken is het eerlijke antwoord dat je uiteindelijk een beetje van allebei nodig hebt: EDI voor de twee of drie accounts die erom vragen, en API-integratie in de rest van je B2B-techstack.

Wanneer je EDI echt nodig hebt

EDI implementeren loont als minstens één van deze punten klopt:

• Een retailer stelt het als voorwaarde om met je te handelen, en het account is van wezenlijk belang voor je omzet

• Je verkoopt in levensmiddelen, farmacie, doe-het-zelf of een andere categorie waar complianceprogramma's en boetes standaard zijn

• Je levert aan een distributeur of inkoopcombinatie die orders van veel winkels bundelt

• Je ordervolume bij één partner is zo groot dat handmatige verwerking echt geld kost, en niet alleen irritant is

De toets is simpel: EDI is gerechtvaardigd door een specifieke handelsrelatie, niet door een algemene wens om meer te automatiseren. Kun je de handelspartner die het eist niet bij naam noemen, dan heb je het waarschijnlijk nog niet nodig.

Wanneer een API of B2B-portal de betere oplossing is

Veel leveranciers beginnen aan een EDI-project terwijl ze eigenlijk een probleem met hun orderinstroom hebben: orders die binnenkomen via e-mail, pdf, telefoon en spreadsheet, van een lange staart aan zelfstandige winkeliers die in hun hele leven nooit een EDI-document zullen versturen.

Daar doet EDI niets aan. Die inkopers hebben een plek nodig om te bestellen, geen documentstandaard. Een B2B-portal in je eigen huisstijl geeft elke retailer een login met eigen prijzen, assortiment en voorraad, en de order komt gestructureerd binnen omdat hij gestructureerd is geplaatst. Dat is hetzelfde resultaat als met EDI, alleen bereikt vanaf de andere kant. Voor orders die nog steeds als e-mail of bijlage binnenkomen, zet AI-orderconversie ze om in gestructureerde orders, zonder handmatig overtypen.

Zit de pijn bij jou in spreadsheets en knippen-en-plakken en niet in een verplichting van een retailer, dan kom je met een portal plus API sneller en goedkoper verder dan met EDI. Bovendien verbeter je daarmee de inkoopervaring, en niet alleen het dataformaat.

Het echte struikelblok: je productdata

EDI-projecten lopen zelden vast op technologie. Ze lopen vast op productdata, omdat EDI veel minder vergevingsgezind is over identificatiecodes dan e-mail ooit was.

Elk product heeft een vaste GTIN- of EAN-barcode nodig die overeenkomt met wat de retailer in zijn systeem heeft staan. Je SKU's moeten consistent zijn en uniek per variant. Verpakkingsgroottes, aantallen per omdoos en meeteenheden moeten kloppen en aan beide kanten identiek zijn. Locaties hebben GLN-codes nodig. Is daar iets van bij benadering, dan worden orders afgewezen en matchen facturen niet. En als de retailer met boetes werkt, kost dat geld.

Eigenlijk is dat goed nieuws. Je productdata opschonen loont, of je nu wel of niet met EDI verdergaat: het verbetert je catalogus, je orderbeheer en elk kanaal waarin je verkoopt. Het is het enige onderdeel van een EDI-project dat nooit voor niets is.

Hoe EDI, API's en een B2B-portal samenwerken

Deze drie zijn geen concurrenten van elkaar. In een gezonde groothandelsopzet bedient elk een ander klantsegment, en één onderliggend systeem beheert de producten, prijzen, voorraad en orders.

EDI regelt het handjevol grote accounts die het verplicht stellen. Je B2B-portal bedient de lange staart van zelfstandige winkeliers die zelf bestellen. Je salesteam verwerkt showroom- en beursorders via een sales-app. Orders per e-mail en pdf worden automatisch omgezet. Alle vier komen in dezelfde orderstroom terecht en synchroniseren via API-integratie met je ERP. Precies zo ziet een multichannel B2B-salesstrategie eruit als die goed is opgezet.

Waar het misgaat: elk kanaal draait als een eigen eiland, met een aparte productlijst en een aparte prijsspreadsheet per verkoopkanaal. Daar komt het handwerk terug, hoeveel er technisch ook is geautomatiseerd.

De rol van Orderchamp Cloud

Orderchamp Cloud is geen EDI-provider. Eist een retailer EDI, dan werk je voor die koppeling nog steeds met een EDI-specialist of je ERP-partner. Wat Orderchamp Cloud wel doet: ervoor zorgen dat EDI alleen de accounts hoeft te dekken die er echt om vragen.

De B2B Portal geeft elke andere retailer een selfserviceplek om te bestellen, met eigen prijzen en assortiment. De Sales App legt showroom- en beursorders digitaal vast. AI Order Convert zet orders per e-mail en pdf om in gestructureerde orders. En integraties met je ERP, PIM en WMS houden producten, voorraad en orders overal gesynchroniseerd, inclusief de productdata waar je EDI-koppeling op draait. Bekijk hoe acht merken hun orderinstroom opnieuw hebben ingericht, of lees meer over wat een complete B2B-e-commerceoplossing inhoudt.

Wil je dat minder van je orderinstroom überhaupt EDI nodig heeft? Ontdek Orderchamp Cloud of plan een demo.

Veelgestelde vragen

Waar staat EDI voor?

Wat is een EDI 850?

Wordt EDI in 2026 nog gebruikt?

Hebben kleine groothandelsmerken EDI nodig?

Wat is het verschil tussen EDI en een API?