EDI (Electronic Data Interchange)
EDI (Electronic Data Interchange) is the structured, computer-to-computer exchange of business documents — purchase orders, invoices, shipment notices — between trading partners in a standardized format, replacing manual entry from email, fax, or a portal. In North America the dominant standard is ANSI X12, organized into numbered transaction sets like the 850 (purchase order) and 810 (invoice); most of the rest of the world uses EDIFACT. EDI moves transactions, not catalog content — that's a separate job handled by formats like BMEcat or a PunchOut session.
What EDI actually moves
EDI documents are numbered "transaction sets" under ANSI X12 (the EDIFACT equivalents differ in name but cover the same ground internationally). Each one is a fixed-format template for a specific business document, agreed on by both trading partners before anything is sent.
| X12 set | EDIFACT equivalent | Document | Who sends it |
|---|---|---|---|
| 850 | ORDERS | Purchase order | Buyer |
| 855 | ORDRSP | PO acknowledgment | Seller |
| 856 | DESADV | Advance ship notice (ASN) | Seller |
| 810 | INVOIC | Invoice | Seller |
| 832 | PRICAT | Price/sales catalog | Seller |
| 852 | — | Product activity/inventory data | Buyer |
The 832 is the one product-data teams touch most directly: it's a catalog-style transaction carrying item numbers, descriptions, UOM, and pricing, sent ahead of ordering so the buyer's system can validate 850s against it.
How an exchange actually works
Two trading partners agree on which transaction sets they'll exchange and how the fields inside them map to each side's internal item numbers, then move documents over AS2, SFTP, or a value-added network (VAN) rather than email. Each document is wrapped in an envelope structure — interchange (ISA/IEA), functional group (GS/GE), transaction set (ST/SE) — that lets the receiving system route it automatically without a human opening a file. Once that mapping and connection are set up, an 850 lands, gets validated against known item numbers and prices, and can trigger fulfillment without anyone re-keying it.
EDI vs. BMEcat vs. PunchOut vs. GDSN
These get lumped together because they all move product or transaction data between trading partners, but each solves a different problem.
| Standard | What it moves | Model |
|---|---|---|
| EDI | Transactions — orders, invoices, ship notices | Batch documents between two named partners |
| BMEcat | A catalog file | Batch, imported into the buyer's system |
| PunchOut (cXML/OCI) | A live catalog session | Real time, one session per shopping trip |
| GDSN | Item master data | Publish-subscribe registry, many-to-many |
A supplier commonly runs more than one at once: EDI for order-to-cash with an existing account, PunchOut for a procurement-platform buyer, and GDSN to register item data with retailers that pull from the network rather than accepting a file directly.
Where EDI breaks on bad product data
EDI failures are rarely about the connection once it's live — they're about the data behind it. An 832 catalog transaction with a stale price or the wrong UOM causes every 850 validated against it to reject or, worse, pass at the wrong price. A unit mismatch between the 856 ASN and the 810 invoice (cases sent, eaches invoiced) triggers a deduction from the buyer's AP system before anyone notices. And a renumbered SKU that isn't remapped on both sides breaks the link between a PO line and the item it's actually ordering. The 832 in particular is only as good as the item master feeding it — if the description, UOM, or price is wrong there, EDI faithfully transmits the error to every order that follows.
Frequently asked questions
What's the difference between EDI and cXML PunchOut?
EDI exchanges discrete transaction documents — a purchase order, an invoice, a ship notice — between two systems that already know each other. PunchOut opens a live, authenticated shopping session inside the supplier's own catalog for each order. Many suppliers run both: EDI for the order-to-cash cycle with an established account, PunchOut for buyers on a procurement platform who want to browse the live catalog first.
What is an EDI 832?
The 832 is the ANSI X12 price/sales catalog transaction set — a supplier sends item numbers, descriptions, unit of measure, and pricing to a buyer ahead of ordering. The buyer's system typically validates incoming 850 purchase orders against the 832 on file, so an outdated 832 causes valid orders to fail validation or price incorrectly.
Do I need EDI to sell to large distributors or retailers?
Most large retailers, distributors, and GPOs require EDI for order-to-cash — at minimum the 850, 810, and 856 — as a condition of doing business, independent of any web storefront or PunchOut integration. Smaller and mid-market buyers are more likely to accept a portal order or email PO instead.
Is EDI the same standard worldwide?
No. ANSI X12 is the dominant standard in North America. Most of the rest of the world uses EDIFACT (UN/EDIFACT), which covers the same document types under different names — ORDERS instead of an 850, INVOIC instead of an 810. A supplier trading internationally often has to support both.