·14 min read

EDI in 2026: Standards, Protocols, and the Full Process Chain Explained

EDIEDIFACTIntegrationSupply ChainMiddlewareAI
EDI in 2026: Standards, Protocols, and the Full Process Chain Explained

If you're an IT manager or CTO at a mid-market manufacturer or distributor, you already know what EDI is. You've dealt with it. You've probably cursed at it at some point. A CONTRL came back with an error code, a partner demanded ORDERS.D96A when your system outputs D93A, or an onboarding project took four months instead of four weeks.

This post isn't an introduction to EDI. It's a structured look at the full picture — standards, protocols, the onboarding reality, the process chain, and where modern tooling (including AI) can actually make a difference versus where it's still hype.

What EDI Actually Is (And What It Isn't)

Electronic Data Interchange is the structured, machine-readable exchange of business documents between companies. Orders, order acknowledgements, delivery notes, invoices, inventory reports — all formalized into a defined format that two systems can process without human intervention.

The key word is structured. EDI is not file transfer. It's not an API. And it's not "we send PDFs by email." It's a contract between two parties that a specific document, formatted a specific way, will be interpreted the same way by both systems.

That sounds simple. The operational reality is not.

EDI sits at the intersection of three hard problems:

  1. Standards — What format is the data in?
  2. Transport — How does it get from A to B?
  3. Mapping — How does the received format map onto the internal data model of each party's ERP?

Every EDI project that takes longer than expected (which is most of them) gets stuck on one of these three layers.

Standards: Who Uses What, and Why

EDIFACT — The European Baseline

EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) is an ISO standard (ISO 9735) managed by the UN. In Europe, particularly in manufacturing, automotive, retail, and logistics, it's the dominant format.

Most real-world EDIFACT implementations aren't pure EDIFACT — they're EANCOM, ODETTE, EDIFICE, or other subsets that define stricter rules for which segments are mandatory, which are optional, and what values are acceptable in specific fields.

The challenge: "We use EDIFACT ORDERS D96A" tells you maybe 30% of what you need to know. The actual interpretation varies by industry, by company, and sometimes by trading partner. EANCOM retail orders are not the same as an ODETTE ORDERS in automotive. The segment is the same. The business logic isn't.

Who uses EDIFACT: Predominantly European companies. Automotive (via ODETTE), retail/FMCG (via EANCOM/GS1), chemicals, manufacturing. Cross-border EU trade is heavily EDIFACT.

ANSI X12 — The North American Standard

X12 is to North America what EDIFACT is to Europe — the dominant standard for structured document exchange. Governed by ASC X12, it covers similar transaction sets: purchase orders (850), invoices (810), advance ship notices (856), and dozens more.

X12 is heavily used in US retail (Walmart, Target, Amazon Vendor), healthcare (HIPAA mandates X12 837/835 for claims), and logistics. If you're dealing with US supply chain partners, you'll encounter X12.

The interoperability problem: EDIFACT and X12 are not compatible. If you're a German manufacturer with US subsidiaries or US trading partners, you need to support both — which means separate mapping configurations.

XML/cXML — The Middle Ground

XML-based standards occupy an interesting position. cXML (Commerce XML) was developed by Ariba (now SAP Ariba) and is widely used for procurement — particularly in e-procurement platforms. If you're connected to a large buyer through SAP Ariba, you're probably sending and receiving cXML.

Other XML standards include xCBL (Commerce Business Library), RosettaNet PIPs (used in electronics/semiconductor supply chains), and UBL (Universal Business Language) which underlies most EU e-invoicing formats today.

Who uses XML: Companies in SAP Ariba ecosystems, electronics manufacturers using RosettaNet, and increasingly everyone dealing with e-invoicing (more below).

JSON-Based Standards — The Emerging Layer

There's no single dominant JSON standard for supply chain EDI (yet). What exists:

  • Peppol BIS (via OpenPeppol): Uses XML/UBL underneath but accessed increasingly via REST APIs. Peppol is the access point network for EU e-invoicing.
  • GS1 JSON: GS1 is pushing JSON representations of their XML schemas for modern API-based integrations.
  • Proprietary REST/JSON: Many platforms (Amazon, Zalando, Shopify) expose their own REST APIs that effectively replace EDI for their specific ecosystem. These aren't "standards" — they're platform-specific APIs.

The honest assessment: JSON hasn't replaced EDIFACT or X12 in traditional EDI contexts. It's becoming the format for new integrations and platform-specific connections. Companies with legacy ERP integrations will run EDIFACT for years. The two coexist.

E-Invoicing — The Regulatory Wildcard

Germany's Wachstumschancengesetz (2025) introduced mandatory e-invoicing for B2B transactions. Since January 2025, all German companies must be able to receive structured e-invoices (XRechnung, ZUGFeRD). Mandatory sending comes in phases — 2027 for most, 2028 for small companies.

This affects the EDI landscape because it forces companies that previously had no structured document exchange infrastructure to implement it. For companies already running EDI, it adds an additional format requirement. ZUGFeRD (hybrid PDF/XML) and XRechnung (pure XML, EN16931-compliant) need to be handled alongside EDIFACT INVOIC.

Transmission Protocols: How Documents Actually Move

Standards define the format. Protocols define the transport. They're separate concerns, but often conflated in conversations with vendors.

AS2 (Applicability Statement 2)

AS2 is the most widely used EDI transmission protocol for direct B2B connections. It's an HTTP/S-based protocol that provides:

  • Encryption (via PKCS#7)
  • Digital signatures (non-repudiation)
  • Message Disposition Notifications (MDN) — technically a receipt, not an acknowledgement of content

AS2 is defined in RFC 4130 and widely supported by EDI middleware (Seeburger, Cleo, Gentran, etc.). It's required by major retailers (Walmart, Marks & Spencer) and common across European manufacturing supply chains.

Operational consideration: AS2 requires managing certificates (typically X.509) that expire and need renewal. Certificate-related AS2 failures are a common source of outages — calendaring certificate renewals is non-optional operational hygiene.

SFTP (Secure FTP)

SFTP is operationally simpler than AS2 — no certificates, no MDN, just authenticated file transfer to/from a directory. It's widely used where AS2 is overkill or where partners don't support AS2.

Limitation: No built-in delivery acknowledgement. You dropped a file in a directory — whether the other party picked it up and processed it is a separate concern. This is why SFTP-based EDI tends to have more manual monitoring overhead.

OFTP2 (ODETTE File Transfer Protocol 2)

OFTP2 is common in European automotive. It's the successor to OFTP (used since the 1980s in automotive supply chains) and provides security features comparable to AS2 — encryption, signing, end-to-end delivery acknowledgements (EERPs in OFTP2 terminology).

If you're in automotive and supply to Tier 1 suppliers or OEMs, you'll encounter OFTP2. The protocol is managed by ODETTE International and widely supported by automotive EDI platforms.

REST APIs

REST isn't traditionally classified as an "EDI protocol," but in practice, many modern integrations that carry structured business documents use REST + JSON or REST + XML. Amazon Vendor Central, Zalando, REWE Digital — they use REST APIs, not AS2.

The boundary between "EDI" and "API integration" is blurring. Some EDI middleware platforms now include API management capabilities. Whether you call it EDI or not is largely semantic — the operational challenge (mapping, error handling, partner management) is similar.

VAN (Value Added Network)

A VAN is a third-party network that acts as an intermediary — you send your EDI messages to the VAN, which routes them to your trading partners. VANs predate the internet and were the original infrastructure for EDI in the 1980s and 1990s.

Why VANs still exist: Indirect connections to hundreds of trading partners without managing individual AS2 connections. VAN providers maintain connections to thousands of companies, so you connect to the VAN once and reach all of them.

The cost: VANs typically charge per-document or per-character fees. For high-volume senders, VAN costs can be significant. Direct AS2 connections are cheaper per document but require managing the connection individually.

Major VANs in Europe: GXS (now OpenText), Sterling Commerce (now IBM), Inovis. Many EDI platforms offer VAN-like managed networks (ecosio, Seeburger's network, etc.).

Partner Onboarding: Why It Takes Weeks

This is the part that surprises people who haven't done it. "We just need to connect Partner X" — and then it takes six weeks. Here's why.

The Typical Timeline

Week 1-2: Scoping and Information Exchange

  • Which message types need to be exchanged? (ORDERS, ORDRSP, DESADV, INVOIC?)
  • Which standard/subset? (EANCOM GS1? EDIFACT D96A? X12 850?)
  • Which transport protocol? (AS2? SFTP?)
  • Partner's EDI coordinator provides their EDI specification document (often a 30-100 page PDF describing their exact requirements)

Week 2-4: Mapping Development

  • Your EDI team builds the mapping between the partner's specification and your internal data format
  • This is not trivial: their ORDERS.D96A interpretation will differ from the last partner's in at least a dozen fields
  • Mapping is done in the EDI middleware's proprietary mapping language (XSLT, SAP message mapping, Seeburger BIS scripts, etc.)
  • Internal testing against your own ERP

Week 3-5: Certificate and Connection Setup

  • If AS2: exchange certificates, configure endpoints, test connectivity
  • If SFTP: provision accounts, share keys, agree on directory structure and file naming
  • Firewalls, IP allowlisting, port configurations — all of this takes coordination between IT teams on both sides

Week 4-6: Testing

  • Send test messages, wait for acknowledgement
  • Partner flags issues with your test messages (wrong qualifier, mandatory segment missing, code list violation)
  • Iterate, resend
  • Acceptance testing: partner confirms test messages are processable in their system
  • Your ERP integration team confirms inbound messages create the right business documents

Week 6+: Go-Live and Stabilization

  • First production messages often surface edge cases not covered in testing
  • First invoices in a new INVOIC format routinely trigger VAT calculation questions
  • A 2-4 week stabilization period before the connection is considered stable

The honest number: For a typical EDIFACT ORDERS/ORDRSP/DESADV/INVOIC setup with an established partner using AS2, six to eight weeks is not slow — it's normal. Lobster's testimonial of reducing projects "from 5-6 months to 2 months" is for complex integrations. The simple ones still take 4-8 weeks.

Why It Can't Go Faster (Usually)

The bottleneck is rarely technical capability — it's coordination overhead. Your team can only move as fast as the partner's EDI coordinator responds. Multinational partners with centralized EDI teams may have their own queue of onboarding projects. Testing windows need to be scheduled. ERP integration requires cooperation from functional teams who own the master data.

This isn't a tooling problem that better software will fully solve. It's a coordination problem.

The Full EDI Process Chain

Let's put it all together. A functioning EDI setup in production has five operational phases:

1. Mapping

The translation layer between external EDI formats and internal ERP data structures. A purchase order arrives as EDIFACT ORDERS — it needs to be converted into an SAP purchase order (ME21N equivalent), a Navision sales order, or whatever your ERP calls it.

Mapping covers:

  • Structural transformation (EDIFACT segment → ERP field)
  • Code list translation (partner uses their own article numbers — cross-reference to yours)
  • Business logic (pricing conditions, tax determination, delivery address resolution)
  • Validation (reject messages that violate agreed specs before they reach the ERP)

Mapping is maintained per partner, per message type. You accumulate mapping configurations over time. A company with 50 active EDI partners typically has 200-400 individual mapping rules in play.

2. Onboarding

As described above: the process of bringing a new trading partner into your EDI infrastructure. Includes spec analysis, mapping development, connection setup, certificate exchange, testing, and go-live.

Onboarding doesn't end at go-live. The first 30-90 days of a new partner connection produce the most support tickets.

3. Communication (Transmission Layer)

The operational infrastructure that sends and receives EDI messages: AS2 servers, SFTP drop zones, VAN connections, API gateways. This layer needs to be monitored — messages can fail at transmission (connection error, certificate expired, server down) independently of content issues.

Transmission layer reliability is table stakes. MDNs confirm receipt but not processing. Knowing that a message was received and knowing it was processed correctly are different things.

4. Maintenance

The ongoing care of a production EDI landscape:

  • Spec changes: Partners update their EDI guidelines (new mandatory fields, changed code lists, new message versions). Someone needs to update your mappings.
  • Certificate renewals: AS2 certificates typically expire after 1-2 years. Missing a renewal takes a connection down.
  • ERP changes: Your SAP upgrade changed field names or added a new document type. Mappings may break.
  • Business process changes: You open a new warehouse, add a product category, change your article number format. Downstream effects on EDI configurations.

Maintenance is the hidden operational cost that grows linearly with the number of active partner connections.

5. Monitoring

Real-time visibility into what's happening: messages sent, messages received, errors flagged, acknowledgements received, processing status in ERP.

Without monitoring, you find out about EDI failures when a supplier calls asking where their order went, or when a customer calls because their delivery confirmation never arrived. That's a reactive model that creates business damage.

Good monitoring means: failed messages surface in a dashboard within minutes. Someone is responsible for resolving them. SLA breaches (no ORDRSP within 24h) trigger alerts.

Where AI Can Concretely Help (And Where It Can't)

This is where the marketing gets ahead of reality. Here's a grounded assessment by phase.

Mapping — High Potential, With Limits

AI (specifically LLMs) can analyze EDIFACT specifications and suggest field mappings. Given a partner's EDI guideline and your ERP data model, a model can propose which EDIFACT segment maps to which ERP field — covering perhaps 60-80% of the straightforward structural mappings automatically.

The remaining 20-40% is business logic: "When the order contains article numbers starting with X, route to warehouse 3." "When the partner sends a ZUGFeRD invoice, apply reverse charge VAT." This logic requires human input because it encodes business decisions, not just data structure knowledge.

Realistic AI contribution to mapping: Accelerated first draft. Human review and business logic still required. Reduces mapping effort by an estimated 50-70% for straightforward cases — not to zero.

Vendors who claim AI will automate EDI mapping entirely are either describing a very narrow problem set or overpromising. Both Seeburger ("Intelligentes Daten-Mapping") and Orderful ("AI-powered automated mappings") have launched features here — worth evaluating against your actual use cases.

Onboarding — Coordination Can't Be AI'd, But Parsing Can

AI can accelerate the spec analysis phase. A 60-page EDIFACT guideline PDF can be parsed and summarized into "here are the mandatory fields, here are the code lists, here are the deviations from standard" in minutes instead of hours.

What AI can't accelerate: partner responsiveness, certificate provisioning, firewall rules, ERP integration testing. These are human and organizational, not informational.

Realistic AI contribution to onboarding: Spec analysis and initial mapping proposal. Estimated reduction in onboarding lead time: 20-30% for the prep/mapping phases. The coordination phases don't compress.

Communication Layer — Limited AI Role

Transport-level operations (AS2, SFTP) are deterministic infrastructure. AI doesn't add much here. Certificate management can be automated with standard tooling (not AI). Retry logic and failover are standard middleware features.

The one area where AI could contribute: classifying and routing transport errors. "Is this a transient network failure or a certificate problem?" — this pattern recognition is solvable with simpler ML models, not necessarily LLMs.

Maintenance — Anomaly Detection Is a Real Use Case

EDI maintenance generates patterns: spec updates come at certain frequencies, certain partners have certain failure rates, certain message types produce certain error distributions. ML-based anomaly detection on message flows is a legitimate application.

"Partner X normally sends 50 ORDRSP per day. Today they sent 3. Flag for investigation." This kind of operational intelligence is currently done manually (if at all) and is a real problem worth solving.

Realistic AI contribution to maintenance: Anomaly detection and change impact analysis. When a partner announces a spec change, AI can analyze the new guideline and identify which of your mapping rules will break. This is genuinely useful.

Monitoring — The Most Mature AI Application

Log analysis, error pattern recognition, predictive failure detection — these are established ML applications. "This type of error at this time of day in this partner's messages typically precedes a mapping failure by 24 hours" is the kind of pattern that human operators miss.

Monitoring is where AI tooling has the clearest value proposition and the most mature implementations. Several EDI platforms offer ML-based monitoring features. This is the one area where "AI improves EDI operations" is least controversial.

FAQ

Q: We're already running EDIFACT. Do we need to worry about JSON/REST standards?

It depends on your partner portfolio. If you're dealing primarily with EU-based manufacturers and retailers, EDIFACT will remain the dominant format for the foreseeable future. If you're adding e-commerce, marketplace, or US-based partners, you'll encounter REST/JSON. Most companies will run both — a phased approach where EDIFACT stays for existing partners and new integrations use APIs is common and defensible.

Q: When does it make sense to move from a VAN to direct AS2 connections?

VANs make sense when you have many partners, low technical EDI capacity, or need indirect reach to partners who only connect to specific VANs. Direct AS2 becomes economical when you have a small number of high-volume partners and the per-document VAN fees exceed the operational cost of managing direct connections. The crossover point varies — a rough estimate is 10,000+ documents/month per partner justifying direct connection overhead, but your specific VAN pricing matters more than this heuristic.

Q: Why does partner onboarding still take 6-8 weeks even with modern EDI platforms?

Because most of the time isn't spent on the technical work — it's spent waiting. Waiting for the partner to send their spec document. Waiting for their test system to be available. Waiting for their IT team to open firewall ports. Waiting for functional sign-off. The technical EDI work might represent 2-3 weeks of actual effort in an 8-week project. Better tooling compresses the technical part; it doesn't compress the organizational part.

Q: Our EDI platform is being acquired/changed. How do we evaluate alternatives without a six-month RFP?

Start with the exit criteria: what does your current landscape look like (how many partners, which message types, which protocols, how much volume)? Any replacement needs to support all of that on day one. Then evaluate three things: can you migrate existing mappings (or do you rebuild from scratch)? What's the parallel operation period (you can't switch all partners at once)? And what does the vendor's track record look like for mid-market companies your size — not the case studies they publish, but customer conversations. The migration is the hard part, not the evaluation.

Sources and Further Reading

Market size estimates sourced from Grand View Research EDI Market Report (2024) and MarketsandMarkets analysis. Onboarding timelines based on practitioner accounts and vendor documentation; individual results vary.