Why EDI still dominates B2B trade — and why that isn't changing
Electronic Data Interchange — the structured, standardised exchange of business documents between computer systems — has been powering B2B commerce since the 1970s. Banks use it. Retailers use it. Logistics networks, healthcare systems, and government procurement rely on it. It is, by any measure, the most widely deployed B2B integration standard in the world.
And yet, every few years, someone declares it dead. APIs are the future. REST is cleaner. Modern platforms don't need EDI. The declaration is always premature. Walk into any major UK supermarket's supplier portal, any automotive parts distributor, any pharmaceutical supply chain — EDI is the entry ticket. You either support it or you don't trade.
For B2B e-commerce businesses, this creates a specific challenge. You're building on modern platforms — Shopify, WooCommerce, cloud ERPs — but your trading partners are operating on document-based workflows that haven't fundamentally changed in decades. EDI integration is the bridge between those two worlds, and getting it wrong has real commercial consequences: delayed payments, failed compliance tests, and in the worst cases, chargeback penalties that make the integration cost look trivial by comparison.
What EDI actually is — and what it isn't
Strip away the acronyms and EDI is a simple concept: instead of sending a PDF purchase order by email, your trading partner's system sends a structured data file in a machine-readable format directly to your system. Your system processes it automatically, creates the appropriate internal records, and sends back the required response documents — all without anyone manually rekeying a thing.
In practice, there are several layers to understand:
EDI syntax standards
The formatting rules that determine how the structured data is organised. The two most important for B2B e-commerce are EDIFACT — the international standard used across most of Europe, Asia, and global supply chains — and Tradacoms, an older UK-specific standard still used by the major British grocery retailers. In North America, ANSI X12 dominates. These are not interchangeable. A file formatted in Tradacoms cannot be read as EDIFACT without translation.
EDI document types
The specific transaction types each formatted according to the relevant standard. For most B2B e-commerce businesses, the core set is:
| Document | EDIFACT name | Tradacoms name | Purpose |
|---|---|---|---|
| Purchase order | ORDERS | ORDHDR | Buyer sends order to supplier |
| Order acknowledgement | ORDRSP | — | Supplier confirms receipt and acceptance |
| Advance ship notice | DESADV | DELHDR | Supplier notifies despatch before delivery |
| Invoice | INVOIC | INVFIL | Supplier charges buyer for goods |
| Remittance advice | REMADV | CREADV | Buyer confirms payment |
Transport mechanisms
How the files actually move between systems. Options include Value Added Networks (VANs) — third-party networks that route and store EDI messages — direct AS2 connections over HTTPS, and increasingly, API-based EDI where the message content follows EDI standards but travels over modern protocols. The choice of transport is often dictated by the trading partner, not the supplier.
The B2B e-commerce EDI compliance challenge
For B2B businesses built on modern e-commerce platforms, EDI integration creates a specific set of pressures that pure-play e-commerce or pure-play EDI businesses don't face in the same way.
"You're translating between two entirely different commercial worlds — one designed for human-readable transactions, one for machine-readable ones — and every translation point is an opportunity for something to break."
The pressure points fall into three categories:
Data mapping complexity
Your internal product codes are not your trading partner's product codes. Your warehouse locations are not their depot GLN references. Your customer account numbers don't match their supplier codes. Every EDI implementation requires cross-reference tables that map your internal data to your trading partner's expected data — and those tables need to be maintained every time either side changes their master data. A product range extension, a warehouse move, a rebrand: each one creates a mapping event that has to be managed.
Document timing and sequencing
EDI isn't just about content — it's about sequence. A DESADV must arrive before the physical delivery. An invoice can only reference a delivery that's been acknowledged. An order acknowledgement must go back within a specified window. Miss the timing, and you fail the compliance test. Fail enough compliance tests, and you face penalties. The document flow diagram below shows a typical retailer cycle:
Retailer-specific requirements
No two large retailers implement the same EDI standard identically. Tesco's ORDHDR implementation has different mandatory fields to Sainsbury's. Ocado's DESADV requires SSCC labels that must be electronically matched on arrival at their Customer Fulfilment Centres. Musgrave in Ireland operates on full EDIFACT while UK grocers use Tradacoms for orders. Each trading partner is, in practice, their own EDI dialect — and the documentation that describes their requirements is often incomplete, outdated, or both.
What modern EDI integration actually looks like
The traditional approach to EDI integration involved buying or building a translation layer, establishing VAN connectivity, mapping every document type manually, and hoping your trading partner's test scenarios matched the real-world messages you'd eventually receive. It was slow, expensive, and required specialist knowledge that most IT teams don't carry in-house.
The modern integration platform approach changes this in three important ways:
Pre-built trading partner patterns
Rather than starting from a blank EDI specification document every time, a mature integration platform brings existing knowledge of how specific retailers and trading partners actually implement their EDI requirements. The difference between a specification and a working implementation is significant — specifications describe the standard, implementations reveal the quirks, mandatory fields, and timing requirements that only emerge during testing or, worse, live operation.
Separation of transport, translation, and business logic
A well-architected EDI integration separates three concerns that legacy approaches often conflate. The transport layer (VAN, AS2, API) handles message delivery. The translation layer handles EDI syntax — reading Tradacoms, writing EDIFACT, generating valid message envelopes. The business logic layer handles your company's rules: which warehouse ships which orders, how your product codes map to trading partner codes, what happens when a partial shipment is needed. Keeping these layers distinct means changes in one don't break the others.
Integration with operational systems
EDI messages that arrive in a translation layer and stop there aren't useful. The purchase order needs to become a sales order in your ERP. The despatch advice needs to be generated from your warehouse management system's confirmation event — not manually entered. The invoice needs to reflect the actual quantities shipped and the agreed pricing in your finance system. Modern EDI integration connects the EDI layer to your operational systems so the document exchange is an automatic consequence of your normal operational workflow, not an additional manual process running in parallel.
EDI implementation: what to get right before go-live
Most EDI projects that go wrong do so in the same places. Here's where to focus attention before a single test message is sent.
Obtain and actually read the trading partner's implementation guide
Every serious EDI trading partner publishes an implementation guide — their interpretation of the standard, including mandatory fields, code lists, and timing requirements. These documents are often dense and occasionally contradictory. Read them before scoping the integration, not after. The surprises in an implementation guide are cheaper to handle at scoping than at testing.
Build and validate your cross-reference tables before writing code
Every mapping between your internal data and the trading partner's data — products, locations, units of measure, party identifiers — needs to be documented and validated before implementation starts. Gaps in cross-reference data are the most common cause of test failures. They're also the hardest to diagnose after the fact because the EDI message will be syntactically valid but operationally wrong.
Design for the exception, not just the standard flow
The standard flow — order in, acknowledgement out, despatch confirmed, invoice sent — is straightforward. The exceptions are where implementations break. Partial shipments. Quantity changes. Substitute products. Order cancellations mid-pick. Each trading partner has different rules for handling these scenarios, and those rules need to be built into the integration, not handled manually when they occur.
Test with real data, not synthetic samples
Trading partner test environments often don't surface the same issues as real production messages. Test with real products from your catalogue, real delivery addresses, real pricing structures. The edge cases that matter — a product with a non-standard unit of measure, a delivery to a depot with an unusual GLN format — won't appear in a synthetic test but will appear in your first live week.
Plan for ongoing change management, not just go-live
EDI integrations don't stay static. Retailers update their implementation guides. They add mandatory fields with six weeks' notice. They change depot structures. They introduce new document types. The integration that works perfectly on day one needs a process for handling changes — ideally one that doesn't require a full re-implementation every time the trading partner sends an updated spec.
Choosing between building, buying, and partnering
When it comes to EDI integration, B2B e-commerce businesses generally face three options, each with a different risk and cost profile.
Building in-house gives maximum control but requires sustained EDI expertise that most IT teams don't maintain. The initial build is achievable; the ongoing maintenance and trading partner change management is where in-house approaches typically fail.
Point-to-point EDI translators handle the syntax layer but leave the business logic, ERP integration, and operational orchestration to you. They're useful components but not complete solutions for businesses with operational complexity.
Managed integration platforms that combine EDI translation with ERP connectivity, operational workflow support, and ongoing trading partner maintenance represent the most practical route for most B2B e-commerce businesses. The question isn't whether this approach costs more than a point translator — it's whether the operational risk of the alternatives justifies the saving.
The right answer depends on the number of trading partners you need to support, the complexity of your internal systems, and how much EDI change management your operation will face over the next two to three years. For businesses onboarding their first one or two retail relationships, a managed approach almost always pays for itself in avoided compliance failures alone.
Onboarding a new retail trading partner?
Supply Lens handles EDI translation, ERP integration, cross-reference mapping, and trading partner change management — for 50+ retail and wholesale partners across the UK and Ireland.
Key takeaways for IT managers
- EDI isn't going away. Any B2B business supplying major retailers, distributors, or public sector organisations needs a credible, maintained EDI capability.
- Syntax is only the first layer. EDIFACT and Tradacoms compliance is necessary but not sufficient. Business logic, cross-references, and timing requirements are where implementations succeed or fail.
- Trading partner requirements are not the same as EDI standards. Every major retailer has a specific implementation that differs from the published standard in ways that only become visible at testing.
- Integration into operational systems is non-negotiable. EDI that doesn't connect to your ERP, WMS, and finance systems isn't automation — it's a more structured form of manual entry.
- Plan for change, not just go-live. The real cost of EDI is ongoing maintenance. Design your integration — and your vendor relationships — with that in mind.
- Chargeback risk is real. Non-compliance with trading partner EDI requirements, particularly around ASN timing and content, can result in financial penalties that dwarf the cost of getting the integration right.