"The reports of my death are greatly exaggerated" - EDI

Every year someone publishes a "death of EDI" article. And every year, X12 and EDIFACT transaction volumes keep climbing. The protocol that was supposedly "dying" in 2015 is processing more transactions than ever.

So why does the narrative persist? Because EDI has a branding problem. It's not sexy. It doesn't have a developer conference. Nobody's writing threads about ISA segments. Meanwhile, REST APIs and webhooks get the spotlight because they demo better in a pitch deck.

But here's what I've learned across 13 years at UPS, Flexport, and Amazon: the companies that actually move freight, fulfill orders, and settle invoices at scale are running EDI under the hood. The question isn't whether EDI survives. It's whether your implementation is keeping up with where the industry is headed.

Let's talk about where that is.

The convergence: EDI and APIs are merging

The old "EDI vs. API" framing is increasingly irrelevant. What's actually happening is convergence, and the hybrid connectivity of the two is what enables real-time decisioning and intelligent automation. The best B2B integration architectures today treat EDI and API as transport mechanisms beneath a unified data model.

Here's what that looks like in practice. A retailer sends you an 850 Purchase Order over AS2. Your integration layer receives it, transforms it into a canonical JSON object, and routes it to your OMS via REST. When your WMS ships the order, it fires a webhook your integration layer catches, builds into a canonical object, transforms into an 856 ASN, and transmits back over AS2. The business logic in the middle never touches raw EDI. It works with clean, normalized objects.

This pattern, often called "API-led connectivity," isn't new in concept. What changed is the tooling. Modern iPaaS platforms like Boomi, MuleSoft, and Celigo now handle EDI parsing and API orchestration in the same workflow. You don't need separate teams for EDI and API anymore. You need integration engineers who understand both.

Standards bodies are adapting too. X12 has been publishing JSON Schema representations of common transaction sets, and EDIFACT is seeing similar efforts in Europe, where new e-invoicing legislation is creating compliance requirements that further entrench EDI infrastructure. We're not abandoning the standards. We're making them accessible through modern interfaces.

For logistics and eCommerce companies, this is a real opportunity. Instead of maintaining two parallel integration stacks (one for your EDI trading partners and one for your API-native SaaS tools), you build one abstraction layer that speaks both. Your OMS, WMS, TMS, and ERP don't care how the data arrives. They consume the canonical model.

AI is changing the EDI game

This is where it gets genuinely interesting. Large language models are starting to solve problems that have plagued EDI implementations for decades, though it's worth being precise about where the technology actually is versus where the hype says it is.

Mapping is the biggest one. Traditional EDI mapping is painstaking: you get a partner's implementation guide (sometimes a 200-page PDF), cross-reference it against your internal schema, and build transformations field by field. A single 850-to-order mapping can take days. Multiply that by 50 partners with slightly different specs and it's a full-time job. AI-assisted tools are starting to change this, using LLMs to read implementation guides, suggest field mappings, and flag discrepancies. We're not at fully autonomous mapping, but the time from new partner to live transactions is compressing from weeks to days. AWS B2B Data Interchange offers generative AI-assisted mapping powered by Anthropic's Claude on Amazon Bedrock: you upload a sample EDI document and a sample JSON or XML data file, and it generates the mapping code with an accuracy score to evaluate before you put it into production.

The second area is exception handling. EDI errors are notoriously cryptic. When a trading partner rejects your 856 with a 997 carrying an AK9 group-level reject and an AK5 transaction reject, your ops team gets a status of "R" and a reason code, and very little human-readable context about which segment or element actually failed. AI agents can now parse the 997, correlate it back against the original outbound transaction, identify the likely root cause, and either auto-correct or surface a specific, actionable recommendation instead of a status code.

The third area is document extraction. A large share of B2B logistics still runs on semi-structured documents: bills of lading, commercial invoices, packing lists, and customs declarations that arrive as PDFs or email attachments. LLMs with vision can extract structured data from these and feed it directly into your EDI/API pipeline. That bridges the gap for trading partners who aren't EDI-capable: you get structured data regardless of how they send it.

The point isn't that AI replaces EDI expertise. It's that the EDI layer is where much of your operational data originates, so modernizing it isn't just an IT project. It's a prerequisite for capturing AI-driven value across the rest of your operation.

Who should care about this

If you're a logistics or eCommerce company doing $10M to $500M in revenue, this is your sweet spot. You have meaningful EDI volume and enough complexity to feel a fragmented integration stack, but not so much that you've got a 20-person integration team. You probably have 1 to 3 people who "do EDI" alongside other responsibilities, and they're drowning in partner onboarding, error resolution, and manual workarounds.

The modernization path isn't a rip-and-replace. It's incremental. Start by auditing what you have: every trading partner, every transaction set, every protocol. From there, centralize on a modern iPaaS, build a canonical data model, and layer in observability and AI-driven exception handling. Each phase delivers standalone value on its own.

The bottom line

EDI isn't going anywhere. But the way we implement, manage, and extend it is changing fast. The convergence of EDI and API into unified integration layers, combined with AI-assisted mapping, exception handling, and document extraction, is making B2B integration dramatically more efficient.

The companies that treat EDI as a strategic asset (investing in modern tooling, canonical data models, and observability) are onboarding new partners faster, resolving exceptions cheaper, and scaling without proportionally scaling headcount.

The companies that treat EDI as legacy debt (ignoring it until something breaks, staffing it with the most junior person available, and running on infrastructure from 2015) are leaving money and speed on the table.

Which one are you?

If you want help figuring out where your EDI stack stands and what the modernization path looks like, reach out. We do free 30-minute assessments: no slides, just a real conversation about your integration architecture.