An EDI order failed in Sellercloud. Now what?

Most EDI days are boring, which is the point. The purchase order arrives, the order appears in Sellercloud, it ships, the ship notice and invoice go back out, and nobody thinks about it.

Then one morning an order isn't there. Or it is there, but the retailer says they never got the 856. Or there's a red warning on a file and nobody is sure whether it matters.

This post is the routine we use for that morning. It is deliberately short, because the mistake people make with a failed EDI order is to start guessing — re-keying the order by hand, resending a file from a different system, emailing the retailer before anyone has actually looked at what went wrong. Guessing is how one failed order turns into a duplicate order and a chargeback.

1. Find the order, not the symptom#

Start from the order itself, not from the alarm. Search by the retailer's PO number (it is on the 850 and on every document that follows it), by the Sellercloud order id if it got that far, or by the interSend order id.

What you want to see first is where in the chain it stopped. Every order in interSend has a status that tells you which step it last finished — received, created in Sellercloud, acknowledged, shipped, invoiced — and, if it failed, the error from the step that didn't finish. That one line usually tells you which of the three parties the problem belongs to: the partner, the connector, or Sellercloud.

2. Line up what everyone saw#

The single most useful thing you can do with a failed order is reconcile it: put what the partner sent, what interSend received, and what Sellercloud has, side by side.

The failures almost always live in the gaps between those three:

• The partner sent a SKU or UPC Sellercloud doesn't know. The 850 is fine; the order can't be created because the line doesn't map to a product.
• The partner sent a ship-to or ship method Sellercloud can't use. A new store location, a carrier service code nobody has mapped yet.
• Sellercloud has the order, but it's not in the state interSend expects. Someone shipped it from a different workstation, split it, or cancelled a line, and the 856 or 810 that interSend would build no longer matches.
• The partner rejected a document you sent. The 997 came back with an error, or the 856 was accepted and then rejected in their system for a data reason — a bad carton weight, a missing tracking number, a pack structure they don't accept.

Reconciling tells you which of these you're in. Nine times out of ten the fix is one field.

3. Read the raw file when the summary isn't enough#

Sometimes the plain-English error is "line 3 rejected" and you need to know why. That is when you open the actual X12 (or the JSON exchange, for API partners like Secret Sales or Wayfair) and look at the segment the error points at.

You do not need to be fluent in X12 to do this. You need to find the segment, see the value the partner sent, and compare it with the value you expected. An N1 with a store code you've never seen, a PO1 with a quantity of 0, an SDQ spread across locations — these are visible to anyone once they know what they're looking for.

Every activity entry in interSend also has a debug report that bundles the file, the request made to Sellercloud, and the response. If you're going to send it to us, or to your Sellercloud rep, send that rather than a screenshot.

4. Fix the one thing, then retry — don't rebuild#

Once you know the cause, fix that and nothing else:

• Unknown SKU → add the mapping or the product in Sellercloud.
• Unknown ship method → map the carrier and service to the partner's code once; it will be right for every future order.
• Order already handled by hand → mark it as dealt with so the warning stops, rather than letting the connector create a second copy.
• Bad data on an outbound 856 → correct it on the Sellercloud order (the weight, the tracking number, the carton) and let the document regenerate.

Then retry the order. A retry puts it back to the last step it finished, with the error cleared, and runs forward from there. It does not start over from the 850, so you don't get a second Sellercloud order and you don't resend documents the partner already accepted.

5. Check the next run#

A failed order is often the first sign of a change, not a one-off. A retailer opens a new DC, adds a product, changes a ship method code — and every order after that one will fail the same way until the mapping catches up.

So after the fix, look at the next scheduled run (or preview it) and confirm the pattern is gone. If you fixed the SKU on one order and three more are queued with the same SKU, you'll see it there before the retailer does.

The short version#

1. Find the order by PO number and see which step it stopped at.
2. Reconcile partner vs. interSend vs. Sellercloud; the problem is in one of the gaps.
3. Open the raw file only if the error line isn't specific enough.
4. Fix the one field, then retry. Never re-key and retry.
5. Preview the next run to make sure it was a one-off.

Done this way, a failed order is a ten-minute job. Done by guessing, it's an afternoon and a duplicate shipment.