If you've ever sat in a trading partner onboarding call and nodded along while someone asked whether you support "X12 4010 or 4030 over AS2 with MDN," you are not alone. The EDI world has accumulated four decades of terminology, standards bodies, and competing protocols — most of it undocumented outside specialist circles.
This guide cuts through it. Whether you're an operations manager trying to understand what your IT team is actually doing, or a business owner evaluating integration options, here is everything you need to know — in plain English.
What EDI Actually Is
Electronic Data Interchange (EDI) is the automated, computer-to-computer exchange of business documents in a structured format. That's the official definition. In practice, it means: instead of emailing a PDF purchase order and waiting for someone to type it into another system, the systems talk to each other directly.
A purchase order leaves your customer's ERP as a structured data file, travels to your system, and arrives as a readable order — without a human in the middle. The same journey happens in reverse for invoices, shipping notices, and acknowledgements.
EDI standards define what those structured files look like: which fields go where, in what format, in what order. Different industries, regions, and trading partners use different standards — which is most of why EDI is complicated.
The Two Major Standards
X12 (ANSI X12)
X12 is the dominant standard in North America, maintained by the Accredited Standards Committee X12. If you're trading with US or Canadian retailers — Walmart, Target, Amazon, Costco, Home Depot — you will encounter X12.
X12 documents are called "transaction sets," each identified by a three-digit number. The format is dense and machine-oriented: a string of data elements separated by delimiters, with no whitespace. To a human eye, an X12 850 Purchase Order looks like line noise. To a properly configured integration system, it's a complete, structured document.
X12 also has versions: 4010, 4030, 4050, 5010, 6020. Different trading partners have standardized on different versions, and the version determines which fields are available and how they're structured. This is why mapping between trading partners is rarely a copy-paste exercise even within the same standard.
EDIFACT (UN/EDIFACT)
EDIFACT is the international standard, developed by the United Nations and dominant across Europe, Asia, and international trade. If you're working with European retailers, automotive manufacturers, or any company doing significant cross-border trade, you'll encounter EDIFACT.
Like X12, EDIFACT has message types (equivalent to transaction sets): ORDERS for purchase orders, DESADV for despatch advice, INVOIC for invoices, APERAK for acknowledgements. The structure is similar to X12 but uses different delimiters and field naming conventions.
EDIFACT also has subsets — TRADACOMS (UK retail), EANCOM (global retail), and various industry-specific variants — each with their own field requirements layered on top of the base standard.
Common Transaction Types
Regardless of which standard your trading partner uses, the underlying business documents are the same. Here's what you'll encounter most often:
| Document | X12 Code | EDIFACT Code | What It Is |
|---|---|---|---|
| Purchase Order | 850 | ORDERS | Customer sending you an order |
| PO Acknowledgement | 855 | ORDRSP | You confirming receipt and acceptance |
| Advance Ship Notice | 856 | DESADV | You telling them a shipment is on its way |
| Invoice | 810 | INVOIC | You billing the customer |
| Functional Acknowledgement | 997 | CONTRL | Technical confirmation that a file was received |
| Inventory Inquiry/Advice | 846 | INVRPT | Stock level reporting |
| Remittance Advice | 820 | REMADV | Payment details |
The 997 (or CONTRL in EDIFACT) is worth special attention. Trading partners often require a functional acknowledgement within a specific timeframe — typically 24 or 48 hours — as proof that their file was received and syntactically valid. Failing to send 997s on time is a common source of compliance chargebacks.
Transport Protocols: How Files Actually Move
EDI standards define what data looks like. Transport protocols define how it travels. These are separate concerns, though they're often conflated.
AS2 (Applicability Statement 2)
AS2 is the most common transport for B2B EDI today. It's an HTTP-based protocol that wraps the EDI file in a signed, encrypted envelope and sends it directly between trading partners over the internet. AS2 provides:
- Encryption (the file contents are private)
- Digital signatures (the sender is authenticated)
- Message Disposition Notifications (MDN) — a receipt that proves delivery
The MDN is important for compliance. When a retailer requires AS2, they typically also require a signed MDN, which creates a non-reputable proof that the file was delivered and received.
AS2 requires both parties to exchange SSL certificates and configure endpoints. This setup work is why new trading partner onboarding takes time — there's certificate exchange, connectivity testing, and MDN configuration before any actual business documents can flow.
SFTP
Secure File Transfer Protocol is simpler than AS2: you drop files in a folder, your trading partner picks them up, and vice versa. It's still widely used, particularly by smaller trading partners and for non-time-sensitive document exchanges.
SFTP lacks the MDN mechanism of AS2 — there's no built-in delivery receipt. Many SFTP integrations compensate by polling for response files on a schedule. This introduces latency: if you're polling hourly, there's potentially a 59-minute window where you don't know if a file was received.
VAN (Value-Added Network)
Before the internet was ubiquitous, trading partners exchanged EDI through centralized networks operated by companies like GXS (now OpenText), Sterling Commerce (now IBM), and Kleinschmidt. These VANs provide a mailbox model: you send to the VAN, the VAN routes to your trading partner's mailbox.
VANs are still used today, particularly by large retailers with established EDI programs. They charge per-kilobyte transmission fees (typically $0.03–0.10 per KB) which add up significantly at volume. The appeal is simplicity: you connect once to the VAN and the VAN handles connectivity to each trading partner.
Peppol: The E-Invoicing Standard
Peppol (Pan-European Public Procurement On-Line) is a European-origin network and document standard originally designed for public sector procurement, now expanding rapidly into commercial B2B as governments mandate e-invoicing.
Peppol is relevant for any business trading with:
- European public sector organizations
- Companies in countries with e-invoicing mandates (Italy, France, Germany, Spain, and others phasing in)
- Nordic businesses (Peppol originated in Scandinavia and has deep adoption there)
Unlike EDI which is bilateral (you connect to each partner), Peppol is a network: you connect once through a certified Peppol Access Point and can exchange documents with any other Peppol participant. The document format is UBL XML (Universal Business Language), which is more human-readable than X12 or EDIFACT.
Format Comparison at a Glance
| Standard | Region | Primary Use | Human-Readable | Setup Complexity |
|---|---|---|---|---|
| X12 | North America | Retail, grocery, automotive | No | Medium |
| EDIFACT | International | Cross-border trade, European retail | No | Medium |
| TRADACOMS | UK | UK grocery retail | No | Medium |
| Peppol/UBL | Europe/Global | E-invoicing, public sector | Yes (XML) | Low (network) |
| JSON/REST | Global | Modern platforms, APIs | Yes | Low |
| CSV/flat file | Global | Legacy systems, small partners | Yes | Low |
When You Need Which Standard
The short answer: your trading partner tells you. You don't choose your EDI standard — it's determined by the requirements of the retailer, 3PL, or marketplace you're connecting to. If Walmart says X12 850/856/810 over AS2, that's what you implement.
The longer answer: most established retailers in North America require X12 via AS2. Most European retailers require EDIFACT (or a national variant). Smaller trading partners often accept SFTP with CSV or flat files because they don't have the infrastructure for AS2. Modern platforms and marketplaces increasingly offer REST APIs in JSON.
The practical challenge for a growing business is that you're often connecting to trading partners who use different standards simultaneously. You need X12 for your US retail accounts, EDIFACT for your European distributor, SFTP with CSV for your 3PL, and a REST API for your e-commerce platform — all at once.
How Modern AI Makes the Standard Irrelevant
Here's the thing: for most businesses, the standard that matters is the one your trading partner requires. Your job isn't to understand EDI standards deeply — it's to ensure data flows accurately between systems regardless of which standard is in play.
Modern AI-native integration platforms are format-agnostic by design. You drop in a sample file — X12 850, EDIFACT ORDERS, a CSV, a JSON payload — and the AI identifies the structure, maps the fields to your ERP's data model, and generates the integration. You don't need to know whether the date field uses YYYYMMDD or CCYYMMDD format. The AI reads it and handles it.
This shift has real operational consequences:
- New trading partner onboarding goes from weeks to hours
- Format changes from trading partners don't require manual remapping
- Your team doesn't need EDI expertise to operate the integration
The standards still exist. They still matter for compliance. But they stop being a barrier to operating your business efficiently — which is what they always should have been.
Sources
- ANSI (American National Standards Institute) — Official X12 standards body
- UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) — EDIFACT standards authority
- Peppol.eu — Official Peppol network information