← Insights Monday, October 19, 2026

What Should an EDI AI Agent Be Allowed to Fix Without a Human?

Agentic AI has reached EDI operations, and the first wave of products agrees on something worth noticing: a human approves the fix.

On October 15, 2026, Orderful announced AI agents for EDI that work inside Oracle NetSuite, which it plans to demo at SuiteWorld on October 27. According to the announcement, when a document fails, the agent finds the cause, explains it in plain language, and proposes a fix. Every change waits for the customer's approval, and once the user approves, the document is re-sent. A month earlier, on September 15, SPS Commerce made MAX, its agentic AI offering, generally available across its fulfillment customer base. SPS also described a Validation Agent in onboarding testing that recommends fixes, with consultants reviewing and approving every recommendation before it's applied.

Two different vendors arrived at the same design: the agent diagnoses and proposes, and a person approves. That's a sensible starting point. But "a human approves everything" doesn't scale forever, and "the agent fixes everything" is how a supplier ends up with a quietly wrong invoice at a big-box retailer. The useful question is narrower. Which fixes can an agent make by itself, which need a human to approve, and which need someone who actually knows the trading partner?

Here's a vendor-neutral way to sort them.

Why "can the AI fix it?" is the wrong question

Technically, an agent can change almost anything in an EDI document. It can rewrite a date format, change a quantity, swap a qualifier, or cancel a line. The question is never whether it can. It's what happens if it's wrong.

That turns the decision into a risk question with three parts:

1. Does the fix change what the business agreed to? A date format doesn't. A quantity, a price, or a cancellation does.
2. Can you undo it cleanly? A resend can be resent again. An invoice that's already been paid, or an ASN the DC has received against, can't be quietly corrected.
3. Is the right answer written down? Some fixes have one correct answer in the spec. Others depend on how a particular retailer actually behaves, which is often not what the PDF says.

Score a fix against those three questions and it lands in one of three tiers.

Tier 1: Safe to automate

These fixes are mechanical, reversible, and leave the commercial meaning of the document unchanged. When the rule is clear and the fix is logged, an agent can act without waiting.

• Retransmissions. A connection timed out, an AS2 or SFTP send failed, or a 997 never came back within the expected window. Resending the same document, unchanged, is low risk, as long as the agent checks for duplicates first so the partner doesn't receive the same PO acknowledgment twice.
• Format and syntax corrections. Wrong date or time format, a value too long for the element, an invalid character, a segment count mismatch, or an envelope control number problem. These are rules about how the document is written, not what it says.
• Deterministic reference lookups. Filling a missing GLN, store number, or partner ID from a maintained cross-reference table, when the table has exactly one answer.
• Triage and summarization. Grouping a night's exceptions by root cause, explaining a cryptic 824 in plain language, and flagging the five that actually threaten a ship window. This changes nothing, and it's often where agents save the most time.

Guardrails still apply. Every automated fix should be logged with a before-and-after, limited to a known rule, and paused automatically if the same fix starts firing far more often than usual. A spike in "routine" corrections usually means something upstream broke.

Tier 2: Agent proposes, a human approves

These fixes change the commercial content of the document: what's shipping, what it costs, or whether the order exists. The agent can do the detective work and draft the change. A person who can answer for the business outcome should approve it.

• Quantity changes. Adjusting an 855 or 856 quantity to match a pick, or reconciling an ASN against what the PO acknowledged. The agent can see the mismatch. It can't know whether the warehouse short-shipped, mis-scanned, or is about to send a second carton.
• Price and allowance changes. A unit price on an 810 that doesn't match the PO, or an allowance that didn't apply. Changing either one changes what you get paid, and it may conflict with a promotion or deal the agent doesn't know about.
• Cancellations and line status changes. Choosing between "accepted, quantity changed" and "rejected" on a partial, or cancelling a drop-ship line. These codes tell the retailer what to expect, and picking the wrong one causes trouble downstream.
• Item and UOM substitutions. Swapping an item ID, a pack size, or a unit of measure, even when the agent is confident the new value is right.

The approval step should be quick, not ceremonial. A good proposal shows the failed document, the cause, the exact change, and the business impact in one view, so the approver can decide in seconds and the decision lands in an audit trail. Both product announcements above describe this pattern: explain the cause, propose the fix, and apply it only after approval.

Tier 3: Needs someone who knows the trading partner

Some problems don't have one right answer in any document. They depend on how a specific retailer behaves this season, what its EDI team said on the last call, and what will and won't trigger a chargeback. An agent can gather the evidence. A person who knows the partner should make the call.

• Spec ambiguity. The implementation guide says one thing, the retailer's validator enforces another, and the retailer hasn't published an update. Suppliers run into this all the time, for example when a retailer starts rejecting a code it used to accept without changing its guide. An agent trained on the PDF will keep "fixing" toward the old rule.
• Disputed chargebacks and deductions. Deciding whether to dispute, what evidence to attach, and how to frame it depends on the relationship, the retailer's dispute process, and your history with them. Getting the documents ready for a dispute is a good job for an agent. Deciding to file one isn't.
• Partner-requested changes outside the spec. A buyer asks for a workaround over email or a portal message. Someone has to judge whether it's a one-time exception or a new rule, and write it down.
• Patterns that point to a broken process. If the same "fix" is needed on every document for one partner, the right move is changing the map or the upstream data, not approving the same correction over and over.

A simple policy you can write down

Turn the tiers into a short policy before you turn on any agent, whoever built it:

Two rules sit on top of the table. First, every tier logs: who or what changed what, when, and why. Second, fixes can move between tiers based on evidence. A Tier 2 fix that's been approved without changes many times, under a stable rule, can become a candidate for automation. A Tier 1 fix that starts misbehaving moves back up a tier.

The point of the human in the loop

Approval steps aren't a sign that the AI isn't ready. They're how accountability stays with someone. When a fix goes wrong, the retailer doesn't charge the model. It charges the supplier of record. Whoever approves a change should be someone who can stand behind it.

That's also why the most useful agent capability may turn out to be the least flashy: telling a person, clearly and early, that something needs their judgment. For more on where AI helps on the build side, see our earlier piece on AI-assisted EDI mapping and why maps aren't the same as trading-partner ownership.

How IDXE pairs automation with people who own the outcome

IDXE is EDI Partners' proprietary, Azure-native managed EDI platform, and it follows the same split. Automation handles the mechanical work: retransmissions, format corrections, reference lookups, exception triage, and plain-language summaries. AI helps spot anomalies and recommend fixes. Changes that touch quantity, price, or order status go through governed review. Partner-specific judgment, such as reading a quiet spec change or deciding whether to dispute a deduction, stays with EDI Partners' team, who know your trading partners.

The difference from a self-serve tool is who's on the other end of the approval request. With IDXE, the people approving and escalating are managed-service operators accountable for the outcome, so your team isn't left holding an approval queue on top of its day job.

Takeaways

• The first agentic EDI products from Orderful and SPS Commerce both keep a human approval step on fixes.
• Sort every fix by three questions: does it change commercial meaning, is it reversible, and is the right answer documented?
• Automate retransmissions, format and syntax corrections, deterministic lookups, and triage, with logging and rate limits.
• Have a human approve changes to quantity, price, cancellations, and substitutions.
• Send spec ambiguity, disputed chargebacks, and partner-specific exceptions to someone who knows the trading partner.
• Move fixes between tiers based on evidence, and make sure every change is auditable.

If you're weighing agentic EDI tools, start by deciding where each fix belongs and who signs off on it. Talk to EDI Partners about governed automation with IDXE →