Most wholesale brands meet EDI the same way: a buyer at a large retailer sends an email saying that from next season, orders will be sent via EDI and suppliers need to be compliant. There's a deadline, a PDF of technical specifications, and the name of a provider you've never heard of.

That email is worth taking seriously, but it's also worth answering carefully. EDI is genuinely mandatory for some relationships and completely unnecessary for others, and the difference is worth thousands of euros a year plus months of implementation. Suppliers get this wrong in both directions — either treating a single retailer's requirement as a reason to rebuild their whole order intake, or ignoring it until the account is at risk.

This guide covers what EDI actually is, which documents you'll be asked to support, what onboarding really involves, how EDI differs from an API integration, and how to decide which of the two your business needs.

What is EDI?

EDI stands for Electronic Data Interchange. It's a standardised way for two companies to exchange business documents — purchase orders, order confirmations, shipping notices, invoices — computer to computer, in a fixed format, without anyone typing or emailing anything.

The idea predates the internet. Large retailers and manufacturers needed to move millions of orders between mainframes, so the industry agreed on strict document formats: every field in a defined position, every document type given a number. A supplier's system produces a file in that exact format, sends it over a secure channel, and the retailer's system reads it without human involvement.

That's why EDI still dominates in grocery, pharmacy, DIY, automotive, and large-format retail. It's not modern, and nobody would design it this way today — but it's reliable, it's audited, and it's already wired into the systems of every major retail chain. When a buyer says "we need you on EDI", they're saying their ERP will only accept orders in that format, and manual order entry on their side isn't an option.

The EDI documents you will actually be asked for

There are two standards in common use. ANSI X12 is used mainly in North America and refers to documents by number. UN/EDIFACT is the international standard, common across Europe, and refers to them by name. Retailers will specify which one they use, and you'll typically only need four or five document types.

The EDI 850 is simply a purchase order in machine-readable form — same information, same commercial meaning, different packaging. If you already understand how a PO flows through your business, you already understand most of what EDI is doing.

The despatch advice is usually the one that catches suppliers out. It requires you to describe exactly how the shipment is packed — which items are in which carton, on which pallet, each labelled with a serial shipping container code. That's a warehouse process change, not just a data format, and it's the most common reason EDI projects take longer than planned.

How EDI works in practice

Three things have to be in place before a single order flows.

A connection. Documents move over a secure channel — usually AS2, SFTP, or a Value Added Network (VAN) that acts as a managed post office between trading partners. Most suppliers reach this through an EDI provider rather than building it themselves.

A mapping. Your system's idea of an order and the retailer's idea of an order have to be translated into each other, field by field. This is the real work, and it is per trading partner: every retailer implements the standard slightly differently, with their own required fields, their own codes, their own quirks. Being "EDI-ready" for one retailer does not make you ready for the next.

Certification. Before going live you send test documents and the retailer's team checks them against their specification. Expect a few rounds. Larger retailers run formal compliance programmes, and some apply chargebacks when documents are late, malformed, or don't match the physical delivery.

Timelines vary widely by retailer and provider, but a first EDI connection commonly runs six to twelve weeks from kickoff to live, with subsequent partners faster once your side is built. Costs typically combine a per-partner setup fee, a monthly platform subscription, and sometimes a per-document or per-kilocharacter charge. Get a full quote that includes the second and third trading partner — the first one is rarely the expensive one.

EDI vs API: what is the difference?

Both move data between systems without human typing. The difference is age, shape, and who they're built for.

The practical distinction: EDI is how a large customer imposes a format on you, while an API is how you connect your own systems to each other. They solve different problems, and for most wholesale brands the honest answer is that you'll end up needing a bit of both — EDI for the two or three accounts that demand it, and API integration across the rest of your B2B tech stack.

When you actually need EDI

EDI is worth implementing when at least one of these is true:

• A retailer has made it a condition of trading, and the account is material to your revenue

• You sell into grocery, pharmacy, DIY, or another category where compliance programmes and chargebacks are standard

• You're supplying a distributor or buying group that consolidates orders from many stores

• Your order volume with one partner is high enough that manual handling is a genuine cost, not an annoyance

The test is simple: EDI is justified by a specific relationship, not by a general wish to be more automated. If you can't name the trading partner that requires it, you probably don't need it yet.

When an API or a B2B portal is the better answer

Plenty of suppliers start an EDI project when what they actually have is an order intake problem — orders arriving by email, PDF, phone, and spreadsheet from a long tail of independent retailers who will never send an EDI document in their lives.

EDI does nothing for that. Those buyers need somewhere to order, not a document standard. A branded B2B portal gives each retailer a login with their own pricing, assortment, and stock, and the order arrives structured because it was placed structured — which is the same outcome EDI delivers, reached from the other end. For the orders that still come in as email or attachments, AI order conversion turns them into structured orders without manual re-entry.

If the pain you're feeling is spreadsheets and copy-paste rather than a retailer mandate, portal plus API will get you there faster and cheaper than EDI, and it improves the buying experience instead of just the data format.

The real blocker is your product data

EDI projects rarely stall on technology. They stall on product data, because EDI is unforgiving about identifiers in a way that email never was.

Every product needs a stable GTIN or EAN barcode that matches what the retailer has in their system. Your SKUs need to be consistent and unique per variant. Pack sizes, case quantities, and units of measure need to be correct and identical on both sides. Locations need GLN codes. If any of that is approximate, orders will reject and invoices will fail matching — and in a chargeback regime, that costs money.

This is worth hearing as good news. Cleaning product data pays off whether or not you go ahead with EDI: it improves your catalog, your order management, and every channel you sell through. It's the one part of an EDI project that is never wasted.

How EDI, APIs and a B2B portal fit together

These three aren't competitors. In a healthy wholesale setup each covers a different segment of customers, and one system underneath holds the products, prices, stock, and orders.

EDI handles the handful of large accounts that mandate it. Your B2B portal handles the long tail of independents ordering for themselves. Your sales team handles showroom and trade-fair orders through a sales app. Email and PDF orders get converted automatically. All four land in the same order flow and sync to your ERP through API integration — which is exactly what a multi-channel B2B sales strategy looks like when it's built properly.

The failure mode is running each channel as its own island, with a separate product list and a separate pricing spreadsheet per route to market. That's where the manual work comes back, regardless of how much of it is technically automated.

Where Orderchamp Cloud fits

Orderchamp Cloud is not an EDI provider, and if a retailer requires EDI you'll still work with an EDI specialist or your ERP partner for that connection. What Orderchamp Cloud does is make sure EDI only has to cover the accounts that genuinely require it.

The B2B Portal gives every other retailer a self-service place to order with their own pricing and assortment. The Sales App captures showroom and trade-fair orders digitally. AI Order Convert turns email and PDF orders into structured orders. And integrations with your ERP, PIM, and WMS keep products, stock, and orders synchronised across all of it — including the product data your EDI connection depends on. You can see how eight brands restructured their order intake, or read more about what a full B2B e-commerce solution covers.

Want to reduce how much of your order intake needs EDI at all? Explore Orderchamp Cloud or book a demo.

Frequently asked questions

What does EDI stand for?

What is an EDI 850?

Is EDI still used in 2026?

Do small wholesale brands need EDI?

What is the difference between EDI and an API?