Every year, more than 20 billion Electronic Data Interchange (EDI) transactions move between businesses worldwide — purchase orders, invoices, shipping notices, healthcare claims, insurance eligibility checks, banking remittances. It is the single largest, most invisible layer of B2B software in the global economy, and unless you work in retail, healthcare, banking or logistics, you have probably never seen a line of it.
That is a problem. Because in 2026, EDI is at the same inflection point that on-premise software was in 2010: fundamentally sound, wildly entrenched, and quietly under-served by the current generation of tools. This guide is the plain-language starting point — what EDI is, how it actually works, and why it is worth understanding even if you never touch a raw X12 file.
The one-sentence definition
Electronic Data Interchange is the computer-to-computer exchange of business documents in a standardised, machine-readable format — no humans, no PDFs, no email, no re-typing. When Walmart tells one of its suppliers exactly which SKUs to ship to which distribution centre by which date, that instruction is an EDI document.
Why EDI exists at all
Imagine you are a retailer with 5,000 suppliers. Each supplier has its own way of representing a purchase order: different fields, different formats, different units, different order of information. Doing business with all of them requires either (a) accepting whatever each of them sends and reconciling manually, or (b) forcing every one of them to use the same standard. Retailers picked (b), and EDI is the resulting standard.
The core value proposition has not changed in 50 years: agree on the format once, then never re-type a purchase order again. What has changed is how the transport, transformation and business logic around EDI is built — that layer is now ripe for modernisation with APIs and AI.
The two major EDI standards you'll see
There are two dominant EDI standards in 2026: ANSI ASC X12 (dominant in North America) and UN/EDIFACT (dominant in Europe and used globally). Both are text-based, both use segment/element structures, and both are absolutely nobody's idea of a modern data format. Neither is going away.
There are also industry-specific dialects: HL7 for healthcare (arguably its own thing, but often lumped in), TRADACOMS for UK retail (largely deprecated), VDA for German automotive, and NCPDP for US pharmacy. Everything else typically maps into or out of X12 or EDIFACT at some point.
The transaction sets you'll actually see
In X12, business documents are called transaction sets and are numbered. A handful of these run the majority of B2B commerce:
**EDI 810** — Invoice. The bill.
**EDI 850** — Purchase Order. What the buyer wants.
**EDI 855** — PO Acknowledgment. The supplier saying yes/no/partial.
**EDI 856** — Advance Ship Notice. What's in the box before it arrives.
**EDI 820** — Payment / Remittance Advice.
**EDI 837** — Healthcare claim. How every US insurance claim gets submitted.
**EDI 835** — Healthcare claim payment / remittance.
**EDI 270 / 271** — Healthcare eligibility inquiry / response.
There are hundreds more, but if you master those eight, you've covered maybe 80% of B2B EDI traffic.
How EDI actually moves
EDI documents move over a handful of transport protocols. In order of prevalence in 2026:
**AS2** (Applicability Statement 2) — HTTPS-based, encrypted, receipt-acknowledged. The de-facto standard for direct trading-partner exchange in retail and healthcare.
**SFTP** — Secure FTP. Simpler, still widely used, less enterprise-grade audit trail.
**Value-Added Networks (VANs)** — Third-party clearing houses (SPS Commerce, TrueCommerce, OpenText, IBM Sterling) that broker EDI between partners. Reliable, expensive, and dominant in verticals where trading partners can't be trusted to run AS2.
**AS4** — Newer, SOAP-based, mandated by e-invoicing regulations in some EU countries. Growing.
**API + EDI hybrids** — REST APIs that emit or ingest EDI on the wire. Increasingly the way modern SaaS companies bridge to legacy EDI partners.
The four things every EDI implementation actually needs
Every EDI integration, whether custom or SaaS, boils down to four responsibilities:
1. **Transport** — get the file to and from the trading partner (AS2, SFTP, VAN, API). 2. **Translation** — parse raw X12/EDIFACT into your internal schema, and produce it back on the wire. 3. **Validation** — reject malformed documents fast; catch the ones that will silently break downstream. 4. **Business logic** — the actual rules of your business applied to the parsed document (does this PO match a contract? does this claim have the right modifiers?).
Most legacy EDI systems bundle all four in a proprietary monolith. Modern architectures split them: transport handled by a managed AS2/SFTP layer, translation handled by an open-source parser (or an LLM, more on that below), validation as pure functions, business logic as regular application code.
Where EDI is failing in 2026
EDI itself is not failing — the tooling around it is. The three most common pain points we see when clients bring us into EDI-adjacent projects:
**Onboarding a new trading partner takes 6–12 weeks.** Not because the standard is unknown, but because every partner has quirks and every existing EDI stack requires specialist skills to modify.
**Nobody knows what breaks when.** A trading partner changes a field by one character, and 40,000 shipments get rejected at the receiver, and nobody notices for three days because the observability layer is a nightly report.
**Cost per transaction stays high.** VANs charge per KC (kilocharacter), meaning a business paying $50k/year in EDI fees to move data that AWS would ferry for $12/month.
How AI changes EDI in 2026
LLMs turn out to be surprisingly good at three things EDI teams have always paid consultants to do:
**Mapping a new trading partner's schema.** Feed the LLM a sample of the partner's raw file plus your target schema, and it produces a mapping proposal in minutes rather than weeks. A senior engineer still reviews it, but the 80% is done in one prompt.
**Explaining why a document was rejected.** An X12 999 rejection code is human-readable in the same way a stack trace is human-readable: yes, technically. An LLM turns it into a plain-English 'the tax jurisdiction code in segment N4 element 04 is required for California destinations' — which is what the operations team actually needed.
**Anomaly detection on transaction flows.** Feed a week of transaction volumes into a lightweight model, and it flags 'invoices from partner X are down 40% today, and the ones we did get are missing PO references' — before the accounts team notices in Monday's report.
We wrote a follow-up guide on this exact pattern: EDI modernisation with AI and APIs. The short version is: keep the standard, replace the tooling.
What Origami builds around EDI
We build the modern layer on top of EDI: AS2/SFTP transport as a managed service, LLM-assisted trading-partner onboarding, observability that treats every transaction as a first-class event, and business-logic services that expose EDI-backed workflows as clean internal APIs. If you have an EDI stack that costs too much, breaks too often and takes too long to change, that's the engagement.
For an example of how we've applied a similar 'grounded, cited, cost-aware' architecture to unstructured document Q&A, see our Document Intelligence product.
The takeaway
EDI is not going anywhere in 2026. Neither is the industry that runs on it. The opportunity is in the layer above — the modern tooling, the AI-assisted mapping, the observability, the cost-per-transaction — where the incumbents have been quietly complacent for a decade. That is the corner Origami has been building in.