5 Things AI Can’t Do in EDI

There are a lot of posts about AI and EDI right now. Most of them focus on what AI can do, like building maps faster, reading implementation guides, or answering support tickets. Some of that is real. But after a lot of years building, fixing, and supporting EDI integrations, I think the more interesting question is what it can't do.

1. There's a lot more to an EDI map than the code

AI can help with the mechanical part, like lining up segments to fields or pulling a first pass out of a 90-page implementation guide. That part can save time.

But a map is really a record of decisions. Why does this partner use a qualifier in a non-standard way? What happens when a ship-to on an 850 isn't set up in your system - do you reject the order, hold it, or default it? A partner might even send the same qualifier to mean two different things depending on which of their warehouses placed the order. The guide won't mention it. You find out because someone asked.

None of those answers are in the spec. They come from conversations with the trading partner and the business.

2. Most EDI problems aren't EDI problems

They're master data, pricing, or process problems that show up in EDI. EDI is just where they become visible.

Take a rejected 810. AI can tell you quickly that it failed on a price mismatch, and likely even which line. But was the price wrong in the ERP? Did the customer change their price and not tell anyone? Did the map pull the wrong pricing condition? Fixing it usually means talking to your billing or customer service team to figure out where the fix belongs: pricing, the map, or the process.

Fix the symptom without that conversation, and you'll likely see the same rejection again next month.

3. AI is good at finding patterns. People decide which ones matter

This is the part I'm interested in exploring more. EDI generates a lot of data, and most of it never gets looked at unless something breaks. Letting AI sift through transactions and errors to spot trends early could be a real win, like a partner whose 856 rejections are slowly creeping up before they turn into chargebacks, or the same document type failing every month-end and getting fixed by hand each time.

But a pattern isn't a decision. If a customer's order volume drops by half, that could be a mapping problem, a lost account, or a planned change your sales team already knows about. Deciding what to do about it still takes someone who knows the business.

4. A map nobody understands is a liability

We've all inherited EDI built by an expert who has since left. I've probably left a few behind myself for others to decipher. The map works, mostly, but nobody can tell you why a field is hard-coded or why one partner's orders skip a step.

AI-generated maps that no one on the team can explain create the same problem, except the expert never existed. That's fine until a partner updates their spec, or orders stop flowing at 4:00 on a Friday. If AI helps build a map, someone on your team still needs to understand it, document why it works the way it does, and own it.

5. A chatbot shouldn't own a problem

When something breaks in EDI, it's rarely a simple question with a simple answer. Orders are stuck, a truck is leaving tomorrow, and a retailer is waiting on an ASN. Customers don't want an AI decision tree in that situation. They want someone accountable who knows their partners and their history.

That knowledge builds over time. Your support team knows which partners are particular, which maps have workarounds, and what changed last quarter. They often know the people on the trading partner's EDI team too, which can turn a week of back-and-forth into a single phone call. Support is where trust gets built, and that's not something I want to hand off to a bot.

AI belongs behind your support team, not in front of it.

If you'd like to talk about how AI fits into your EDI support, please reach out at info@contax.com.

Photo Credit: Gregory Bradley, CONTAX Inc.