TL;DR
- Semantic EDI turns purchase orders and other business documents that arrive as PDFs, spreadsheets, or emails into structured, EDI-grade transactions.
- A deterministic parser reads what it can and an AI model reads only what the parser cannot settle; deterministic software validates the record and decides what happens next, so the model never writes to the ERP itself.
- It complements EDI rather than replacing it, and it treats an order change as a change to an existing transaction, not as a new order.
EDI is one of the most successful standards in business software, and it has a hole in the middle.
The standards are old and good. ANSI chartered the X12 committee in 1979 to define how businesses exchange purchase orders, invoices, ship notices, and payments electronically. The UN/EDIFACT syntax rules became an ISO standard in 1987. Decades later, large trading partners still run on them, because a structured transaction with agreed meaning is exactly what an order desk, a warehouse, and an accounts team need.
The hole is everyone who never adopted it. EDI works when both sides implement it. Large retailers and distributors do. Much of the long tail does not. Their purchase orders arrive as PDFs, spreadsheets, email bodies, and the occasional scanned form, and a person at the receiving company types them into the ERP. Many suppliers run both at once: EDI for their biggest accounts, and a manual order desk for everyone else.
Semantic EDI is our name for closing that hole.
The definition
Semantic EDI turns business documents that arrive in any format into structured, EDI-grade transactions. A deterministic parser reads what it can, and an AI model reads only what the parser cannot settle. Deterministic software validates the result and decides what happens next. The trading partner keeps sending what it sends today.
The word "semantic" is not ours. The EDI world has long separated the meaning of a transaction from the format it travels in and the network that carries it. GS1, for example, publishes a semantic model methodology for its EDI standards, a dictionary of business terms that exists independently of any file syntax. That separation is the opening. If the meaning of a purchase order is defined independently of its format, then a PDF purchase order and an X12 purchase order carry the same business content. What was missing was a reader that could get the meaning out of the PDF.
Why this was not possible before
Reading arbitrary business documents was the part software always did badly. Template-based capture needs a template per sender and breaks when a sender changes its layout. Rules written against text positions fail on the first document that looks different.
This is an old pattern in computing. Expert systems in the 1980s did not struggle because rules are a bad idea. Their biggest obstacle was what Edward Feigenbaum called the knowledge acquisition bottleneck: every rule had to be extracted from an expert and written by hand, and the systems could not take in anything that had not been anticipated. The rigid half of the system was fine. The half that had to understand people did not exist.
Large language models are that missing half. They read a purchase order they have never seen before and extract the parties, items, quantities, prices, dates, and terms. What they are not is rigid enough to trust with the decision. So the design question is not "can AI replace EDI." It is where to put the model so that its flexibility is used and its unreliability is contained.
AI reads, rules decide
Our answer is to use the model the way a compiler uses its front end. A compiler does not execute source code directly. It parses the source into a precise intermediate form, checks that form, and only then runs anything. Semantic EDI has the same shape:
- Adaptive parse. A deterministic parser reads what it can, and the model reads only what the parser cannot settle, extracting the document's business meaning. It adapts to each sender instead of relying on a fixed template per sender.
- Typed record. The output is a structured transaction with a fixed shape, the same shape an EDI message would produce, not free text.
- Deterministic validation. Code checks the record against the customer, the items, the prices, and the business rules. An exact match in your own data outranks anything the model inferred.
- Exception routing. Anything that fails a check is flagged to a person with the source document and the reason attached.
- System of record. The transaction posts to the ERP with its flags, and a separate check compares what was entered against the source document.
The model never writes to the ERP itself. It produces a record that deterministic software checks before anything is posted, and that another check compares against the source afterward. That boundary is the whole point: the flexible part of the system is the part that is allowed to be wrong, and the part that is not allowed to be wrong is not flexible.
This is also why we check the model with something that fails differently from it. We have written about that principle separately in No learner without a decorrelated checker, and about what it looked like on a month of real order mail in We Ran the Cascade on a Month of Real Purchase-Order Mail.
The hard case is the second document
Most order automation handles the first document well. The second one is where it breaks.
A customer sends a purchase order. It becomes a sales order, a promise date, a confirmation email, maybe a proof or a production release. Then a revised quantity arrives by email, or a new ship date, or a cancelled line. If the system treats that change as a new order, you get a duplicate. If a person handles it by hand, the order lines get updated and the promise date, the confirmation, and the release quietly go stale.
EDI has transaction sets for changes because changes are normal business. Semantic EDI has to treat them the same way: a change is parsed as a change to an existing transaction, and everything that was built on the old values needs to be found and reviewed. We design for that case from the start, because it is where order errors are hardest to catch.
Where it applies
Semantic EDI is not specific to one industry. It applies anywhere a standard transaction exists but partners still send documents:
- Order to cash: purchase orders, order changes, acknowledgments, invoices.
- Procure to pay: supplier invoices, acknowledgments, and ship notices.
- Cash application: remittance advice matched to open invoices.
- Freight and logistics: load tenders, status updates, and freight invoices.
The first of these is where we have built in production. Our High Caliber Line case study describes emailed purchase orders becoming sales orders through this kind of chain.
What semantic EDI is not
It is not a replacement for EDI with partners who already use it. If a partner sends clean X12, use it. It is not "AI that runs your order desk." The parser and the model read, and the rules decide. And it is not a template library, because the long tail sends whatever its own systems happen to produce, and every sender is different.
The old standard was right about what a business transaction is. It just needed a reader for everyone who was never going to write in its format.
If your order desk runs EDI for your biggest accounts and keyboards for everyone else, that is the gap we work on.