EDI standards are the shared rulebooks that let two computers exchange a purchase order, invoice, or shipment notice without a human in the middle. Pick the wrong one and every new trading partner becomes a custom build. Pick the right combination and you onboard retailers in days, not quarters.

This guide covers the standards that matter in 2026: ANSI X12, UN/EDIFACT, HIPAA (now in version 008060), VDA, ODETTE, TRADACOMS, EANCOM, UBL, PEPPOL, RosettaNet, VICS, and SWIFT. Plus the part most articles skip: every retailer interprets the same standard differently, so the standard alone never gets you to production.

Quick take: Most North American CPG, food & beverage, and apparel brands need X12 first. If you sell into Europe, layer in EDIFACT subsets (EANCOM) and PEPPOL for e-invoicing. Healthcare in the US is X12 005010 today and migrating to 008060. Automotive in Europe is VDA and ODETTE. Banking is SWIFT. Most other industries land somewhere in this list.

→ Browse all EDI document types

What are EDI standards?

EDI (Electronic Data Interchange) standards define how electronic business documents are structured, labeled, and transmitted between systems. They specify the syntax (where each piece of data goes), the segments and elements (how a purchase order is split into header, line items, totals), the code lists (currency, country, unit of measure), and the envelope (sender, receiver, control numbers).

When two trading partners follow the same standard, a 5,000-line purchase order can move from a buyer's ERP to a supplier's ERP in seconds, validated automatically, with no rekeying.

Standards exist because without them every pair of trading partners would invent its own format. With them, one supplier mapping can serve many retailers, at least in theory. In practice, retailers customize the standard with their own rules and qualifier values, which is why EDI feels like the only standard that isn't a standard.

The four building blocks of any EDI standard

Every standard, whether it's X12 or EDIFACT or UBL, gives you the same four ingredients:

1. Codes. Standardized values for currencies, countries, dates, units of measure, and document types.

2. Identifiers. Unique IDs for trading partners, transactions, and interchanges. In X12, these live in the ISA and GS segments. See our ISA ID setup guide for how this works in practice.

3. Message structure. Segments, elements, loops, and hierarchies that describe a business document.

4. Syntax. The delimiters, terminators, and character rules that make the file machine-readable.

If any of those four is off, the receiver rejects the file.

The major EDI standards, by region and industry

ANSI ASC X12 (North America)

X12 is the dominant standard across the United States and Canada. The Accredited Standards Committee X12, accredited by ANSI, maintains it. More than 300,000 organizations worldwide rely on X12, and it covers retail, healthcare, logistics, finance, government, and insurance.

X12 uses a three-digit numeric code for each transaction set. The retail supply chain runs on a handful:

• EDI 850 Purchase Order

• EDI 855 Purchase Order Acknowledgement

• EDI 856 Advanced Ship Notice (ASN)

• EDI 810 Invoice

• EDI 846 Inventory Inquiry/Advice

• EDI 997 Functional Acknowledgement

• EDI 753/754 Routing Request and Response

• EDI 820 Payment Order / Remittance Advice

X12 versions. X12 isn't one standard, it's a family of versions: 4010, 5010, 6020, 6040, 7030, and now 008060. Retailers can require any of them, and they migrate on their own timeline. A single supplier can carry multiple X12 versions at once.

→ See the full EDI document library

UN/EDIFACT (International)

UN/EDIFACT (Electronic Data Interchange For Administration, Commerce, and Transport) is the only ISO-recognized international EDI standard. It's developed under the United Nations Economic Commission for Europe and used heavily across Europe and Asia, plus parts of South America and Africa.

EDIFACT uses six-letter alphanumeric message names instead of numeric codes:

• ORDERS Purchase Order

• ORDRSP Order Response

• DESADV Despatch Advice (equivalent to ASN)

• INVOIC Invoice

• CONTRL Acknowledgement

EDIFACT segments use plus (+), colon (:), and apostrophe (') as delimiters. The interchange envelope is UNB/UNZ instead of X12's ISA/IEA. Same job, different syntax.

HIPAA EDI (US Healthcare)

HIPAA mandates X12 transactions for protected health information in the United States. The current production version is X12 005010, but X12 published the 008060 versions of all HIPAA-mandated implementation guides in late 2025, and CMS adoption is in motion. Healthcare payers, providers, and clearinghouses need to plan migration.

Key HIPAA transactions:

• EDI 837 Healthcare Claim

• EDI 835 Payment / Remittance Advice

• EDI 270/271 Eligibility Inquiry and Response

• EDI 276/277 Claim Status Inquiry and Response

• EDI 834 Benefit Enrollment

• EDI 820 Premium Payment

VDA (German Automotive)

VDA (Verband der Automobilindustrie) was created in the late 1970s by German automakers, including Volkswagen, Audi, BMW, and Daimler, to standardize communication with suppliers. Unlike X12 and EDIFACT, VDA uses fixed-length record formats rather than delimited segments. If you supply parts to a German OEM, VDA is non-negotiable.

ODETTE (European Automotive)

ODETTE serves the broader European automotive sector with formats focused on just-in-time delivery, sequenced shipments, and production scheduling. It overlaps with VDA in places and with EDIFACT subsets like OFTP2 for transmission.

TRADACOMS (UK Retail)

TRADACOMS was the UK retail EDI standard from the 1980s onward, originally maintained by the UK Article Numbering Association and now under GS1. Development stopped in 1995, but a large share of UK retail EDI traffic still uses it. New deployments lean toward EANCOM.

EANCOM (Global Retail and Beyond)

EANCOM is a GS1-managed subset of EDIFACT. It started in retail and now spans publishing, healthcare, construction, and utilities. The "subset" part matters: EANCOM picks specific EDIFACT segments and tightens the rules, which makes implementations more consistent across partners.

UBL and PEPPOL (Europe-wide e-Invoicing)

Universal Business Language (UBL) is an XML-based, OASIS-managed document library. PEPPOL (Pan-European Public Procurement OnLine) defines a network and a profile of UBL for cross-border e-invoicing.

This is the area to watch in 2026 and beyond. Belgium requires structured B2B e-invoices via the PEPPOL network starting January 1, 2026. France's mandate begins in September 2026: all businesses must be able to receive e-invoices electronically, and large and mid-sized enterprises must issue them. Poland, Germany, Romania, Spain, and others are phasing in similar requirements, with the EU's ViDA directive making digital invoicing the default by mid-2030.

If you sell into Europe, plan e-invoicing as part of the same compliance roadmap as your core EDI program.

RosettaNet (High-Tech and Electronics)

RosettaNet is an XML-based set of Partner Interface Processes (PIPs) used in semiconductors, electronics, and telecommunications. It excels at component-level traceability across complex global supply chains.

VICS (North American Retail)

VICS (Voluntary Interindustry Commerce Standards) was the retail-specific overlay on X12, originally driven by the Voluntary Interindustry Commerce Solutions association. Many of the supply chain transaction sets you use today (EDI 852 product activity, 816 organizational relationships) trace back to VICS work.

SWIFT (Banking and Finance)

SWIFT is the global standard for interbank messaging, used for payment instructions, securities settlement, and FX confirmations. It's separate from supply chain EDI but worth knowing because EDI 820 remittances often map to corresponding SWIFT messages on the bank side.

→ Look up any term in our EDI glossary

EDI standards comparison table

ANSI X12 vs EDIFACT: the practical difference

If you're choosing between X12 and EDIFACT, here's what actually matters day to day.

A purchase order in X12 (850) and EDIFACT (ORDERS) carries the same business intent. The mapping work is real, but most modern EDI platforms translate one to the other so trading partners on either side keep their preferred format. The hard part is rarely the standard itself; it's the trading-partner-specific spec on top of it.

→ Read more on EDI integration into your ERP

Why "EDI is the only standard that isn't a standard"

You can read the X12 specification cover to cover and still fail your first 850 test with Walmart. That's because every retailer publishes its own implementation guide on top of the standard. Same transaction code, different mandatory segments, different qualifier values, different acceptable code lists, different validation rules.

A few things make EDI harder than it looks on paper:

1. Flat-file fragility. Most EDI is positional or delimited. A stray space or a wrong line ending can invalidate the file.

2. Trading-partner variation. Two retailers using X12 850 will have different segments, sub-elements, and code requirements. Each one is a separate mapping.

3. Spec drift. Retailers update their guides, sometimes annually. Every change ripples through your mappings.

4. Mixed transport. AS2, AS4, SFTP, REST APIs, and Value-Added Networks (VANs) all coexist. Some retailers still bill by kilo-character on a VAN.

5. Version sprawl. A single retailer can sit on X12 4010 for one transaction and 5010 for another. Healthcare is moving from 005010 to 008060. You don't get to consolidate.

This is the core reason most growing brands outsource EDI rather than build it. The standard gets you 60% of the way; the last 40% is tribal knowledge.

→ Why EDI persists in modern B2B

How to choose the right EDI standard

Most companies don't choose a single standard. They choose a combination dictated by where they sell, what they sell, and to whom.

1. Start with your largest trading partners. Walmart, Target, Costco, Amazon, Home Depot, Loblaw, Sobeys, and the major US distributors all use X12. If they're 80% of your revenue, X12 is your starting point.

2. Layer in regions next. Selling into Europe? You'll see EDIFACT, EANCOM, and PEPPOL e-invoicing. Selling into Germany for auto parts? VDA is required.

3. Match the document to the standard. A retailer that uses X12 850 for orders may still want PEPPOL UBL for invoices in Europe. Different documents, different rails.

4. Confirm your ERP can keep up. Some systems handle multiple standards out of the box; others require middleware. NetSuite, SAP, Microsoft Dynamics, Acumatica, Cin7, and QuickBooks all integrate, but the depth varies.

5. Plan for versions. Today you may run X12 4010. Tomorrow a retailer migrates to 5010 or 7030. Healthcare partners will move from 005010 to 008060. 

6. Decide build vs buy. In-house EDI works at scale with dedicated staff. For most CPG, food & beverage, and apparel brands under $500M, a managed EDI provider is the lower-cost, lower-risk path.

→ Pre-built integrations for your ERP
→ See the retailers we already support

EDI transmission methods: how the file actually moves

The standard defines the file format. Transmission protocols move it between you and your trading partner.

• AS2. HTTP/S-based, encrypted, MDN receipts. The most common protocol for X12 in North American retail. Walmart, Amazon, Target. See our AS2 deep dive.

• AS4. Web-services successor to AS2. Used in European e-invoicing and energy sectors.

• SFTP. Encrypted file transfer. Common with mid-market retailers and 3PLs.

• VAN. Value-Added Networks act as mailboxes between partners. Still common in healthcare and older retail relationships. Often billed per kilo-character.

• REST API. Increasingly common for modern integrations, especially when EDI is wrapped in a JSON payload behind the scenes.

• PEPPOL. Not a single protocol, but a four-corner network with Access Points exchanging UBL documents over AS4.

EDI versioning: why "X12" alone isn't a specification

When a retailer says "we use X12 850," the next question is always "which version?" X12 publishes major releases that retailers adopt unevenly:

• 4010 Long-running default; still widely used in retail.

• 5010 Mandatory baseline for HIPAA healthcare transactions through 2025.

• 6020 / 6040 Modern retail versions some chains require for newer transaction sets.

• 7030 Used in some logistics and rail contexts.

• 008060 New HIPAA target. Healthcare payers and providers need a migration plan.

Migrating a single mapping from 4010 to 5010 means revisiting every qualifier, every code list, and every retailer-specific rule. Multiply that across 30 trading partners and you see why version management eats EDI budgets.

EDI and the move to APIs, JSON, and AI

EDI is getting wrapped in modern interfaces.

Modern platforms accept JSON or REST API calls from your ERP, translate them into X12 or EDIFACT, and deliver them over AS2, SFTP, or PEPPOL. The trading partner sees the same EDI file they always have. Your team sees clean JSON and webhooks.

A few real shifts to watch:

• AI-assisted mapping. Spec changes and trading-partner onboarding are starting to use LLMs to suggest mappings and catch outliers.

• Exception handling. Rather than reading 997 acknowledgements by hand, modern systems classify, summarize, and triage exceptions automatically.

• Hybrid topologies. Large enterprises run EDI, API, and PEPPOL in parallel. The work is matching the right rail to the right partner.

• Mandated e-invoicing. Belgium 2026, France 2026, Germany 2027, the rest of the EU by 2030. If you have European revenue, treat it as a board-level program with real budget.

How Surpass approaches EDI standards

We're a managed EDI provider for mid-market CPG, food & beverage, apparel, and B2B SaaS clients. We translate between X12, EDIFACT, UBL, and JSON, run trading-partner mappings, and monitor exceptions so your team focuses on growth instead of segment validation. We work in Consumer Goods, Food & Beverage, Apparel, and B2B SaaS.

If you're sizing the cost and risk of doing EDI yourself versus outsourcing it, start with a free assessment. We'll give you a written 3-5 year ROI and TCO projection for your specific trading-partner mix.

Frequently asked questions

What are EDI standards?

EDI standards are agreed-upon rules for structuring electronic business documents so that one company's system can send a purchase order, invoice, or shipment notice and another company's system can interpret it without manual rekeying. The major standards include ANSI X12, UN/EDIFACT, HIPAA (a profile of X12), VDA, ODETTE, TRADACOMS, EANCOM, UBL/PEPPOL, RosettaNet, VICS, and SWIFT.

What is the most common EDI standard?

ANSI X12 is the most widely used EDI standard in North America, with over 300,000 organizations relying on it. UN/EDIFACT is the dominant international standard, especially in Europe and Asia.

What is the difference between ANSI X12 and EDIFACT?

X12 uses three-digit numeric codes (like 850 for a purchase order) and is most common in North America. EDIFACT uses six-letter alphabetic names (like ORDERS) and is the international ISO-recognized standard. Their envelopes, delimiters, and code lists differ, but they describe the same business documents. Most EDI platforms translate between them.

Which EDI standard is best for global trade?

UN/EDIFACT is the default for cross-border trade outside North America. Many multinationals run X12 internally for North American trading partners and EDIFACT or EANCOM for European and Asian partners, with PEPPOL UBL layered in for European e-invoicing.

Are HIPAA EDI standards required?

Yes. US healthcare providers, payers, and clearinghouses must use X12 005010 for HIPAA-mandated transactions today. X12 published the 008060 versions of all HIPAA implementation guides in late 2025, and a migration to 008060 is in motion.

What is the difference between X12 versions like 4010, 5010, and 7030?

Each version is a new release of the X12 standard with updated transaction sets, segments, and code lists. Retailers and healthcare partners adopt versions on their own schedules, so a single supplier can run multiple versions in production simultaneously.

Is EDI being replaced by APIs?

No. APIs are increasingly used to move data between your ERP and an EDI platform, but the trading partner on the other end almost always still receives EDI. The future is hybrid: APIs in the front end, EDI on the wire, with PEPPOL UBL handling regulated e-invoicing.

What is PEPPOL and how does it relate to EDI?

PEPPOL is a four-corner network that exchanges UBL-formatted e-invoices and procurement documents across Europe. It's becoming mandatory in Belgium (January 2026), France (September 2026), and other EU countries. If you sell into Europe, treat PEPPOL as part of your EDI compliance roadmap.

Do I need different EDI standards for different trading partners?

Often, yes. A North American retailer uses X12, a European customer uses EDIFACT or EANCOM, a German automaker uses VDA, a European public-sector buyer requires PEPPOL UBL. A managed EDI provider or modern platform handles the translations so your ERP exchanges one consistent format internally.

How do I get started with EDI?

Start by listing your top 10 trading partners, the documents they require, the standards and versions they use, and the transport (AS2, SFTP, VAN, PEPPOL) they support. That document is the foundation for any build-vs-buy decision. Talk to a Surpass EDI expert and we'll build it with you.

Related reading

• How AS2 secures EDI transmissions

• EDI 846 inventory advice for CPG brands: how to prevent out-of-stocks

• Complete guide to EDI 846 inventory management

• EDI transaction setup: ISA ID

• EDI integration into your ERP: readiness guide

• Why EDI persists in modern B2B

• EDI documents library

• EDI glossary

• Trading partner directory