EDI order processing exchanges orders as structured electronic documents between trading partners, removing manual entry for the customers set up on it. Our view at Lleverage is that EDI solves the structured half of the problem. It covers your largest accounts, while the long tail keeps arriving as email, PDF and spreadsheet.
Most wholesalers and manufacturers who invested in EDI describe the same outcome. The top ten customers flow in cleanly. Everyone else still lands in a shared inbox, and the order desk is the same size it was before. The technology worked exactly as promised. It just covered a smaller share of the orders than the business case assumed.
We build agents for the orders that fall outside EDI, mostly for wholesalers and consumer goods businesses, so our position here is plain. This article sets out where the EDI boundary actually falls, why it has not moved much, and how the remainder gets handled inside the quote and sell process. If you would rather see it than read about it, book a demo and we will run it against your own order flow.
What is EDI order processing?
EDI order processing is the exchange of purchase orders as standardised electronic documents. The common formats are EDIFACT ORDERS in Europe and ANSI X12 850 in North America, sent directly between a customer's system and a supplier's. The order arrives already structured, so it can post into the ERP without anyone reading it.
The value is real and worth stating plainly. A structured order needs no interpretation. It carries agreed field definitions and produces a clean audit trail. For a supermarket group sending thousands of lines a week to the same supplier, nothing beats it. That is why EDI has outlasted four decades of technology fashion.
The trouble is the entry cost, and who pays it. Getting a trading partner onto EDI means agreeing a message specification and mapping both catalogues. Then testing, then maintaining the connection when either side changes. That effort is justified for a customer sending 400 orders a month. It is not justified for one sending four.
Why does EDI still leave orders to be typed in by hand?
Because EDI coverage follows customer size, not order volume in aggregate. A supplier might have 15% of customers on EDI accounting for 60% of lines. That leaves 85% of customers, and a large share of the daily order count, arriving in formats somebody has to read.
The distribution is the whole story. Order desks are staffed for the orders that need a human, not the lines that flow through the business. So a supplier can automate most of their volume through EDI and see almost no reduction in headcount. The residual orders were always the labour.
There is a second effect people underestimate. The orders outside EDI are systematically the awkward ones. Small customers change their paperwork more often and use their own article codes. They send corrections by email and skip fields the large accounts always complete. The remainder is not just uncovered. It is harder per order than the covered part.
Onboarding also runs slower than anyone plans for. Each new trading partner is a project. A supplier adding a handful of connections a year will never catch a customer base that churns faster than that.
Which orders does EDI not cover?
Everything sent by a customer who is not on your EDI connection, plus the exceptions from customers who are. In practice that means the long tail of smaller accounts and urgent changes. It also means anything a person sent outside the normal channel because it was faster.
| Order type | Why it sits outside EDI |
|---|---|
| Small and mid-sized accounts | Volume never justifies the onboarding project on either side |
| New customers | Trading first, integration later, if ever |
| Urgent changes and corrections | Sent by email or phone because EDI round-trips too slowly |
| Trade counter and field sales | Written or photographed at the point of order |
| Customers on their own portal | Structured for them, manual export for you |
| One-off and project orders | No repeat volume to amortise the setup |
| Spot purchases in peak season | Seasonal senders never get onboarded |
Two of those deserve a closer look. Urgent changes hurt most. They are time-critical and they interrupt a person mid-task. Customer portals are quietly the worst of both worlds. The data is structured, and a human still has to log in, export it and re-key it.
How does AI process the orders EDI cannot?
An agent reads the incoming order whatever its shape and extracts the lines. It resolves each against your catalogue using your own rules, then posts it into the ERP alongside the EDI traffic. Clean orders go straight through. Ambiguous ones go to a person with the specific problem highlighted and the source document attached. From there the confirmed order feeds delivery and support like any other.
The important design point is that this sits beside EDI rather than replacing it. Structured orders keep their structured path. There is no reason to interpret a document that is already unambiguous. The agent takes the remainder. The two approaches divide the work by whether an order needs reading, not by which customer sent it.
Topa Bathroom Products, a Dutch importer and wholesaler serving around 700 customers, is the published example closest to this pattern. Orders arrived as plain emails, PDFs and spreadsheets, each customer in their own format. Four and a half people did nothing else. Today more than 90% of Topa's incoming orders post straight into Microsoft Dynamics 365 Business Central. Customers receive confirmation within 30 seconds.
"We had four and a half people, about 3.8 full-time equivalents, sitting there all day long, manually entering every single order into our Business Central ERP." Bryan van Ingen, Operations Director, Topa Bathroom Products
The pattern repeats where the documents are worse. At the flower wholesaler Xpol, roughly 20 minutes is saved on each large order across about 150 orders a week. The agent holds 25 customer rulesets that used to live in one specialist's head. At Koninklijke Dekker, a timber business of more than 140 years, the same approach reads PDFs, spreadsheets and emails straight into the ERP.
Should you extend EDI or replace it?
Extend it. Replacing a working EDI connection with document reading would be a downgrade. You would be interpreting orders that arrive unambiguous. The question is not which technology wins. It is which orders each one should carry.
A practical way to decide is to count rather than assume. Take a month of orders and split them three ways. Arrived via EDI, arrived unstructured and processed without incident, arrived unstructured and needed chasing. The third bucket is where the cost concentrates. It is almost never the bucket anyone expected.
Then look at what onboarding another EDI partner would actually buy you. If the candidate sends 30 orders a month, an integration project is a poor return. An agent covers every non-EDI sender at once, including the ones you have not signed yet. This is where we land after enough of these projects: EDI is worth keeping for the accounts that earn it, and worth stopping at that boundary.
The connected version is the one that pays. The same layer that reads unstructured orders also handles ERP integration for the rest of the back office. Order intake then stops being an isolated project. Our piece on B2B order management covers the wider format problem this sits inside.
Frequently Asked Questions
Is EDI still relevant in 2026?
Yes, for the accounts that justify it. Structured exchange remains the cleanest way to move high-volume repeat orders between two systems. Nothing has displaced it. What has changed is the alternative for everything else. Unstructured orders can now be read reliably, so EDI is no longer the only route to a hands-off order.
What is the difference between EDI and AI order processing?
EDI moves orders that are already structured, agreed field by field between two partners in advance. AI order processing reads orders that were never structured. It interprets an email, PDF or spreadsheet against your own catalogue and rules. They solve different halves of the same problem and work best running side by side.
Can AI replace our EDI setup?
It can, but it usually should not. An order that arrives unambiguous does not benefit from being interpreted. The EDI connection you already maintain is a sunk cost that keeps working. The stronger move is to leave EDI carrying your largest accounts and put everything else on a reading layer.
How do you handle EDI errors and exceptions?
The same way as any other exception. Route the specific failure to a person with the context attached, rather than dropping it into a queue for somebody to reconstruct. Failed messages, mapping mismatches and rejected lines are all order-desk work. They benefit from the same handling as an unreadable PDF.
How long does it take to cover non-EDI orders?
For a single well-defined order flow, SMEs typically see production results in weeks rather than quarters, provided the pilot writes into the live ERP from the start. That is materially faster than onboarding EDI partners one at a time. It is the honest comparison when both options are on the table.
See it run on the orders EDI misses
The test that matters is not your EDI traffic. It is the pile beside it. The small account with their own codes, the urgent change sent by email, the spreadsheet from the customer never worth an integration project. Book a demo and we will run an agent against a sample of those, in your own ERP, before you commit.