Wat is EDI precies?
Kort antwoord
EDI (Electronic Data Interchange) is het uitwisselen van gestandaardiseerde zakelijke berichten — orders, pakbonnen, facturen — rechtstreeks tussen de systemen van twee handelspartners. De inhoud ligt vast in een standaard zoals UN/EDIFACT, het transport in een protocol zoals AS2 of SFTP. Je kiest EDI zelden zelf: je grootste afnemer schrijft het voor.
Als je levert aan een supermarktketen, een bouwmarkt, een ziekenhuisinkooporganisatie of een grote verlader, komt er een moment waarop de inkoopafdeling vraagt of je "EDI doet". Dat is geen vrijblijvende vraag — het is vaak een voorwaarde om leverancier te blijven.
EDI bestaat al sinds de jaren tachtig en dat is te merken: de berichten zien eruit als een reeks kryptische segmenten, en de terminologie komt uit een tijd waarin bestanden nog over een gehuurde lijn gingen. Toch verwerken de grootste handelsketens van Nederland er dagelijks hun orders mee. Wie in de groothandel, logistiek of retail bouwt, ontkomt er niet aan.
De kern is simpel. Twee bedrijven spreken af: dit is een order, dit is een pakbon, dit is een factuur, en dit is precies hoe de velden heten en in welke volgorde ze staan. Omdat beide partijen dezelfde afspraak volgen, kan het systeem van de ontvanger het bericht zonder mensenhanden inlezen en verwerken.
De standaarden: EDIFACT, EANCOM en GS1
De belangrijkste internationale berichtenstandaard is UN/EDIFACT, ontwikkeld en gepubliceerd door de VN-economische commissie voor Europa. De syntaxregels zijn in 1987 vastgelegd als ISO 9735; de berichtdefinities, datavelden en codelijsten staan in de UNTDID-directory die UNECE onderhoudt en periodiek in nieuwe versies publiceert.
EDIFACT is bewust breed opgezet — te breed voor dagelijks gebruik. Daarom werkt de handel met subsets: een beperkte selectie van velden die voor één sector zinvol is. De bekendste subset is EANCOM, beheerd door GS1. GS1 Nederland publiceert daarbovenop sectorhandleidingen voor onder meer levensmiddelen, doe-het-zelf, tuin en dier, en de gezondheidszorg. Die handleidingen bepalen in de praktijk hoe jouw bericht eruit moet zien — niet de UNECE-directory.
Waarom GS1-nummers erbij horen
EDI leunt op eenduidige identificatie. Een artikelregel verwijst niet naar "doosje pennen blauw", maar naar een GTIN — het nummer onder de streepjescode. Een afleveradres verwijst niet naar een straatnaam, maar naar een GLN, het locatienummer van die specifieke vestiging of dat specifieke laaddock.
Dat klinkt als administratie, maar het is de reden dat EDI werkt. Zonder gedeelde nummers verschuift het matchen naar de ontvanger, en dan ben je terug bij handwerk. In vrijwel elk EDI-traject dat ik heb begeleid, zat de meeste tijd niet in de techniek maar in het op orde krijgen van de artikel- en locatiestamdata.
EDI faalt zelden op het protocol. Het faalt op stamdata die aan beide kanten net niet hetzelfde zeggen.
De berichten die je in de praktijk tegenkomt
De EDIFACT-directory bevat honderden berichttypen. In een normale groothandel of logistieke keten heb je er een handvol nodig:
- ORDERS — de inkooporder van je afnemer: welke artikelen, hoeveel, wanneer en waarheen.
- ORDRSP — jouw orderbevestiging: wat je wel, niet of gedeeltelijk kunt leveren, en tegen welke condities.
- DESADV — de vooraanmelding van de zending (despatch advice, in de wandelgangen de elektronische pakbon): wat er in welke colli zit en wanneer het aankomt. Voor de ontvangende magazijnen is dit het belangrijkste bericht, omdat het de inslag stuurt.
- RECADV — de ontvangstmelding: wat er daadwerkelijk is aangekomen, inclusief afwijkingen.
- INVOIC — de factuur, idealiter zo opgebouwd dat de ontvanger hem automatisch tegen de ontvangstmelding kan afletteren.
- PRICAT — je prijs- en artikelcatalogus, waarmee je nieuwe artikelen en prijswijzigingen vooraf aankondigt.
Daarnaast zie je in de logistiek vaak IFTMIN (transportopdracht) en INVRPT (voorraadrapportage). Begin niet met alles tegelijk. In vrijwel elk traject is de volgorde: eerst ORDERS inlezen, dan DESADV versturen, dan INVOIC, en pas daarna de rest.
Hoe het bericht bij je handelspartner komt
De berichtstandaard zegt niets over transport. Dat is een aparte keuze, en daar zit meer variatie in dan mensen verwachten:
- AS2 — het meest gebruikte protocol in retail en handel. Berichten gaan over HTTPS, verpakt als MIME en ondertekend en versleuteld met S/MIME; de ontvanger stuurt een getekende ontvangstbevestiging terug. Vastgelegd in RFC 4130.
- OFTP2 — de standaard in de automotive-keten, met versleuteling, compressie en getekende bevestigingen over TLS. Vastgelegd in RFC 5024.
- SFTP of FTPS — de eenvoudigste vorm: bestanden in een map, op vaste tijden opgehaald. Werkt prima, maar je regelt bevestigingen en foutmeldingen zelf.
- VAN — een value added network: een dienstverlener die als postkantoor tussen alle handelspartners zit en de protocollen, conversies en routering voor je afhandelt.
- Peppol — het Europese netwerk voor e-facturering en inkoopberichten, in XML in plaats van EDIFACT. Wie aan de Nederlandse overheid levert, factureert al via deze route; ook gemeenten, provincies en waterschappen vragen er geregeld om (Ondernemersplein).
Peppol verdient extra aandacht, want daar komt de wetgeving samen met de techniek. De Europese btw-hervorming ViDA duwt e-facturering richting een verplichte standaard voor grensoverschrijdende B2B-transacties; wat dat concreet betekent voor je factuurstroom staat in het artikel over ViDA en e-facturering. Voor veel groothandels betekent dat op termijn twee kanalen naast elkaar: EDIFACT richting de retailketen, Peppol richting overheid en EU-partners.
EDI of een API-koppeling?
De vraag wordt vaak gesteld alsof het een keuze is. Meestal is het dat niet: je grootste afnemer schrijft EDI voor en dan is de zaak beslist. Maar bouw je zelf een portaal, een ordersysteem of een koppeling met een leverancier die beide kan, dan is de afweging reëel.
| Kenmerk | EDI | API-koppeling |
|---|---|---|
| Ritme | Batches op vaste momenten | Realtime, per gebeurtenis |
| Formaat | EDIFACT-segmenten of XML | Meestal JSON |
| Wie bepaalt het | De sector en je grootste afnemer | De partij die de API aanbiedt |
| Nieuwe partner aansluiten | Nieuwe mapping en testronde per partner | Doorgaans dezelfde koppeling hergebruiken |
| Foutafhandeling | Bevestigingsberichten en afkeurbestanden | HTTP-status, retries, webhooks |
| Sterk in | Hoog volume, vaste partners, retail en logistiek | Wisselende partners, directe terugkoppeling, SaaS |
Het praktische verschil zit in wat er ná verzending gebeurt. Bij een API krijg je direct antwoord: de order is aangenomen, of hij is afgekeurd met een reden. Bij EDI stuur je een bestand en hoor je later — soms uren later — of het is verwerkt. Je software moet dus kunnen omgaan met berichten die nog "onderweg" zijn, en met bevestigingen die pas na de volgende batch binnenkomen.
Dat is precies de reden dat idempotentie in EDI-verwerking net zo belangrijk is als bij API's. Bestanden worden opnieuw aangeleverd, batches worden per ongeluk twee keer ingelezen, en een verwerking die dan een tweede order aanmaakt, kost echt geld.
Wat EDI betekent voor je eigen software
Een EDI-traject bestaat uit vier lagen, en het loont om ze bewust te scheiden:
- Transport: het ophalen en afleveren van bestanden via AS2, OFTP2, SFTP of een VAN. Dit is generiek werk dat je zelden zelf hoeft te bouwen.
- Parsing en validatie: het EDIFACT-bericht omzetten naar een gestructureerd object en controleren of het aan de sectorhandleiding voldoet. Ook hier zijn bibliotheken en dienstverleners voor.
- Mapping: de vertaalslag tussen het bericht en jouw datamodel. Welk EDIFACT-veld is jouw ordernummer, welke code betekent "gedeeltelijk geleverd", hoe ga je om met een GTIN die je niet kent. Dit is het werk dat echt van jou is.
- Verwerking: wat er daarna in je ERP, WMS of ordersysteem gebeurt — inclusief wat er moet gebeuren als er iets niet klopt.
Mijn advies is consequent: besteed laag 1 en 2 uit, houd laag 3 en 4 in eigen huis. De transportlaag en de berichtversies zijn onderhoud dat nooit ophoudt — de directories worden periodiek herzien en elke afnemer hanteert net een andere subset. Daar wil je geen eigenaar van zijn. De mapping en de verwerking bepalen daarentegen hoe jouw bedrijf werkt, en die logica hoort in je eigen systeem te staan, waar je hem kunt lezen, testen en aanpassen.
Wat je in die eigen laag hoe dan ook nodig hebt: een audit trail van elk binnengekomen en verzonden bericht, een duidelijke wachtrij voor berichten die niet konden worden verwerkt, en een mens die daar dagelijks naar kijkt. Een EDI-koppeling zonder zichtbare foutwachtrij is een koppeling die stilletjes orders laat vallen.
Valkuilen die telkens terugkomen
- Stamdata te laat op orde: GTIN's en GLN's regel je vóór de technische bouw, niet erna. Anders test je een koppeling met artikelen die de ontvanger niet herkent.
- Elke afnemer als uitzondering behandelen: bouw één intern ordermodel en zet de partnerspecifieke afwijkingen in configuratie, niet in code. Bij de derde afnemer betaalt dat zich al terug.
- De testfase onderschatten: grote afnemers hebben een certificeringstraject met testberichten en acceptatierondes. Reken op weken doorlooptijd waarin jij vooral wacht.
- Bevestigingsberichten negeren: een CONTRL- of afkeurbericht dat niemand leest, betekent dat je denkt geleverd te hebben terwijl de order nooit is aangekomen.
- Tijdzones en datumformaten: een leverdatum die er een dag naast zit, leidt in de logistiek direct tot een gemiste tijdslot bij het laaddock.
Mijn kijk op EDI in 2026
EDI heeft een slechte reputatie bij ontwikkelaars, en ik snap waarom. De berichten zijn onleesbaar, de documentatie zit achter een lidmaatschap, en de standaard is ouder dan de meeste mensen die ermee werken. Het voelt als een stap terug naar bestandsuitwisseling terwijl de rest van de wereld met JSON en webhooks werkt.
Toch verdedig ik EDI in gesprekken met klanten vaker dan ik afraad. De reden is dat EDI iets doet wat de API-wereld nog steeds niet heeft opgelost: het is een sectorbrede afspraak. Als jij een DESADV bouwt volgens de GS1-handleiding, werkt die bij tientallen afnemers. Bouw je een API-koppeling, dan bouw je hem per partner opnieuw, want elke leverancier heeft zijn eigen velden en zijn eigen ideeën over wat een order is.
Waar ik wél kritisch op ben, is de neiging om EDI als een aparte wereld te behandelen — met een eigen tool, een eigen beheerder en een eigen set Excel-bestanden ernaast. Dan krijg je twee administraties die uit elkaar lopen. Een EDI-bericht is gewoon een invoerkanaal, net als je bestelportaal of een API. Het hoort in dezelfde orderstroom te landen, met dezelfde validatie en dezelfde foutafhandeling.
En eerlijk: de interessantste beweging zit niet in EDIFACT maar in Peppol. Dat netwerk is XML-gebaseerd, open gedocumenteerd en wordt door wetgeving vooruitgeduwd. Voor nieuwe ketens zou ik daar eerder naar kijken dan naar een klassieke EDIFACT-implementatie — al blijft de retail nog jaren op EDIFACT draaien.
— Jasper
Zo helpt Coding Agency hierbij
Wij bouwen de laag die van jou is: de vertaalslag tussen EDI-berichten en je eigen order-, voorraad- en factuurstroom, met een zichtbare foutwachtrij en een audit trail per bericht. Het transport en het berichtonderhoud beleggen we bij een EDI-dienstverlener of Peppol Access Point, zodat een nieuwe berichtversie geen ontwikkeltraject wordt. Werk je in de groothandel, dan combineren we dat meestal met een koppeling naar je boekhoudpakket, zodat facturen uit alle kanalen op dezelfde plek landen.
Twijfel je of EDI of een API-koppeling in jouw situatie de betere route is? Dat is precies het soort vraag waar een uur samen naar de keten kijken meer oplevert dan een offerte. Neem contact op voor een vrijblijvend gesprek.
Bronnen: UNECE — Introducing UN/EDIFACT, GS1 Nederland — GS1 EDI en Ondernemersplein — een e-factuur versturen naar de overheid.
