EDI Explained: How Electronic Data Interchange Works
A major retailer's supplier requirements manual runs to dozens of pages, and buried in it is a clause that can cost a non-compliant supplier real money: shipments that arrive without a properly formatted Advance Ship Notice transmitted in advance can trigger a chargeback, sometimes hundreds of dollars per incident, regardless of whether the product itself arrived correctly and on time. That's EDI in practice — not a technology choice a business makes for itself, but a compliance requirement imposed by a trading partner big enough to set the terms.
What EDI actually is
Electronic Data Interchange is a standardized format for exchanging business documents — purchase orders, invoices, shipping notices — between two companies' computer systems without manual re-entry on either end. It predates the modern internet; the core ANSI X12 standard used in North America dates to the 1970s-80s, and despite decades of newer integration technology, it remains the dominant method for B2B transactions with large retailers, distributors, and healthcare payers, mostly because those large trading partners already have EDI infrastructure built and have no incentive to rebuild it around a newer standard for every supplier.
The document types that actually matter
| EDI transaction code | What it is | Who sends it |
|---|---|---|
| 850 | Purchase order | Buyer to supplier |
| 810 | Invoice | Supplier to buyer |
| 856 | Advance Ship Notice (ASN) — details of a shipment before it arrives | Supplier to buyer |
| 855 | Purchase order acknowledgment | Supplier to buyer |
| 997 | Functional acknowledgment — confirms a document was received and technically valid | Either direction, automated |
The 856 is worth singling out because it's the one that most often triggers compliance penalties: it has to be transmitted before the physical shipment arrives, with accurate carton and item-level detail, so the receiving warehouse can plan labor and cross-reference the shipment automatically instead of manually checking in each pallet.
How EDI actually connects to an ERP system
Three components typically sit between a trading partner and your ERP's internal data:
- A translator converts EDI's rigid segment-and-element format into something your ERP can actually use (and back again for outbound documents). This can be a standalone software package or a module built into the ERP itself.
- A transmission method — either a VAN (Value-Added Network, a long-established third-party mailbox service many large retailers still require) or AS2 (a more modern, direct point-to-point encrypted transmission protocol increasingly preferred by trading partners that support it).
- Mapping logic that connects each EDI document's fields to the correct fields in your ERP — which item code maps to which SKU, which "ship to" location maps to which internal warehouse — and this mapping needs updating whenever either side changes its data structure, which is a real, recurring maintenance task, not a one-time setup.
What EDI compliance actually costs
Budget for three components: the initial setup (translator software or ERP module, VAN or AS2 connection, and mapping for each trading partner, commonly $5,000-$15,000 per new major trading partner for the first setup); ongoing VAN fees if using that transmission method (typically a few hundred dollars a month plus per-transaction fees that add up at volume); and — the cost most businesses underestimate — the maintenance burden every time a trading partner updates its EDI specification, which happens more often than most suppliers expect and can silently break a working integration if nobody's monitoring for it.
The chargeback problem
Large retailers enforce EDI compliance through chargebacks — deductions from a supplier's payment for violations like a missing or inaccurate ASN, incorrect labeling that doesn't match the transmitted data, or late transmission. These aren't nominal; a supplier shipping regularly to a handful of big-box accounts can lose real margin to chargebacks if EDI accuracy isn't actively monitored, not just set up once and left alone. This is the actual business case for investing in a properly integrated EDI-to-ERP connection rather than a manual workaround (some smaller suppliers try to handle EDI through a web portal and manual re-entry, which works at low volume but gets error-prone fast as order volume grows).
EDI versus modern API integration
It's fair to ask why EDI persists when REST APIs are generally easier to build and more flexible. The honest answer: EDI isn't chosen for its technical merits by most companies using it, it's mandated by the trading partner on the other end, and large retailers have no reason to migrate infrastructure that already works for thousands of existing suppliers. Where a business has a genuine choice — a smaller trading partner, a newer marketplace, an internal integration between owned systems — a modern API is almost always the better technical choice: easier to build, easier to debug, and generally lower ongoing maintenance cost. EDI is worth treating as a specific compliance requirement to satisfy well, not a general integration pattern to adopt where it isn't required.
Build, buy, or outsource EDI capability
Three realistic paths: build/maintain EDI capability using a translator module built into the ERP itself (works well if the ERP has mature EDI support and the business has more than a couple of trading partners); use a dedicated third-party EDI service or VAN with managed mapping support (better for businesses without in-house EDI expertise, trading off a recurring service fee for reduced internal maintenance burden); or use a web-based EDI portal for manual entry (workable only at very low order volume with one or two trading partners, and a real bottleneck once volume grows). Most mid-market suppliers with more than three or four large trading partners end up better served by a dedicated EDI service or a strong ERP-native module than trying to hand-build and maintain mapping logic internally, because the trading-partner-specific requirements and their periodic updates are genuinely specialized, ongoing work.
Onboarding a new trading partner: what to expect
Every large trading partner runs its own EDI onboarding process, and it's rarely fast — expect a testing cycle where you exchange sample documents back and forth, get flagged for formatting errors, correct them, and resubmit, often over several weeks before the partner certifies you as compliant and turns on live transactions. Budget this timeline explicitly into any new retail account launch; a supplier who commits to a shelf date before completing EDI certification risks either missing the launch or scrambling to process the first orders manually while certification finishes, which is exactly the kind of manual workaround that tends to generate the compliance errors and chargebacks EDI was meant to prevent in the first place.
Questions to ask before signing an EDI compliance requirement
- Which specific transaction sets does this trading partner require, and does our ERP or EDI provider already support them, or is custom mapping needed?
- What's the chargeback schedule for non-compliance, in writing, not verbally described by the account rep?
- Who monitors for failed or rejected EDI transmissions daily — a name, not "the system will alert someone"?
- What's the process when the trading partner updates their EDI specification, and who's responsible for testing against it before it goes live?
EDI has a reputation as old, clunky technology, and technically it is. It's also not going anywhere for B2B trade with large retailers and distributors, and treating it as a compliance and operations discipline rather than a one-time IT setup task is what actually keeps chargebacks off the P&L.