There's a lot of AI theatre in the EDI space right now: vendors promising 'AI-powered EDI' that turns out to be a fuzzy-matching algorithm from 2013 with a chat interface bolted on. Meanwhile, the actual wins from LLMs and modern ML in EDI are unglamorous, boring and enormously valuable. Here's what we've seen work in production.
Win #1 — Trading-partner mapping in minutes
Historically the single most expensive activity in an EDI shop is onboarding a new trading partner. Every partner has quirks: they call the ship-to code SHIP-TO in one segment and SHIPTO in another; their PO reference lives in a non-standard element; their date format is MMDDYY while yours is YYYYMMDD.
An LLM handed a sample of the partner's raw file plus your target schema will produce a mapping proposal in one prompt. It won't be perfect. It doesn't need to be — a senior integration engineer reviews it, fixes the 20% that's wrong, and ships. The 6-week onboarding drops to 2 days.
What matters here is the review workflow, not the mapping. LLMs get 80% right and 20% subtly wrong, so the discipline is: every mapping goes through a diff review, every diff gets tested against a corpus of that partner's real historical documents, and every deployed mapping ships with an eval that runs on every message.
Win #2 — Rejection triage in plain English
When a trading partner sends back an X12 999 (Implementation Acknowledgment) with a rejection, the raw error looks like: 'AK4*3*81*7*Y'. A human being can technically read that. Nobody wants to.
Feed the same rejection to a small LLM (Claude Haiku, GPT-5 Mini) with the trading partner's implementation guide as context, and you get: 'Segment N4, element 04 (State) is missing for a US destination. Add the state code and retransmit.' That's the message that goes to the ops team. The 15-minute triage becomes 15 seconds.
The cost is minuscule — a few thousand tokens per rejection, cached because rejections repeat. The impact is measured in operator-hours saved per week.
Win #3 — Anomaly detection that actually catches things
Legacy EDI observability is a nightly summary email. It tells you what happened yesterday. Modern anomaly detection uses simple time-series models (Prophet, or lightweight LLM classification with structured outputs) to spot patterns as they emerge:
'Invoices from partner X are down 40% in the last 4 hours. Historical median at this hour is 320. Current: 190. Root cause suggestions: partner X had a routine batch job schedule change last week; check if a new schedule window applies.'
That's the alert that goes to Slack at 10am on Monday, not the report that hits the CFO's inbox at 8am on Wednesday.
Win #4 — Structured extraction from unstructured docs
Not everything a trading partner sends is EDI. Many still send PDF purchase orders, faxed invoices, and emailed shipping instructions. Historically these got manually keyed into an ERP.
Modern VLMs (GPT-5, Claude Sonnet 4.5, Gemini 3) extract structured data from these documents with accuracy in the high-90s. Layered with human-in-the-loop review for low-confidence extractions, this eliminates a category of data-entry work that used to consume a full FTE per hundred partners.
Win #5 — Explainable compliance for auditors
In regulated verticals (healthcare, financial services), every EDI transaction has to be auditable. When a claim is denied, why? When a payment was withheld, why? Traditionally that meant a compliance officer digging through logs and stitching together the story from three systems.
A grounded LLM Q&A layer on top of the transaction store answers these questions with page-level citations back to the underlying documents — the same architecture as our Document Intelligence product, applied to EDI transactions instead of contracts. Auditors get plain-English answers with proof; compliance teams get their time back.
What NOT to do with AI in EDI
**Don't let an LLM produce EDI documents autonomously.** The failure modes are catastrophic: hallucinated PO numbers, invented SKUs, wrong amounts. Deterministic templates + validated data go on the wire; LLMs go in the tooling around it.
**Don't skip evals.** An LLM-based mapping that works 95% of the time still corrupts 5 out of every 100 transactions — potentially thousands of dollars of downstream reconciliation. Evals aren't optional.
**Don't chase real-time.** LLM inference latency is fine for tooling and diagnostics, not for the hot path of transaction acceptance. Keep the LLMs in the offline and near-real-time layers.
How Origami does it
We build the modernisation layer, not another EDI platform. Concretely: LLM-assisted mapping tools inside the developer workflow, plain-English rejection triage in the ops dashboard, anomaly detection in the observability layer, and RAG-grounded compliance Q&A for auditors. All of it sits on top of whatever EDI stack you already have — Boomi, MuleSoft, Cleo, SPS Commerce, Sterling, or a bespoke build.
The economics are usually obvious. A single senior integration engineer onboarding 40 partners a year at 6 weeks each costs about $250k in loaded time. Cut that to 2 days per partner and the ROI on the tooling is measured in weeks, not quarters.