Your retailer mandated EDI. That's not the same as EDI working.
You're compliant, technically. You still get chargebacks and the bill keeps climbing. The gap is almost always between the EDI layer and your ERP.
A big customer — the kind whose logo you're glad to have on the website — informed you that you'll be doing EDI through SPS Commerce, and you'll be doing it by a date that has already passed. So you got connected. You are, technically, live.
And yet the chargebacks keep coming. The monthly bill keeps climbing. And when someone asks whether the ship notice you sent actually matches what left the dock, the honest answer is a shrug. You did the thing you were told to do, and it still doesn't feel like it works.
That's because two different things got quietly conflated. EDI compliance and EDI working are not the same, and the gap between them is almost always the connection between the EDI layer and your ERP — which is the part you can actually fix.
The documents that matter, in plain English
EDI has a vocabulary designed to make it sound harder than it is. Strip it down and a retail relationship mostly runs on four documents.
The 850 is the purchase order. Your customer telling you what they want. The 855 is the acknowledgment — you, confirming you can fill it (and flagging what you can't). The 856 is the advance ship notice, the ASN — you telling them exactly what's on the truck before it arrives, usually down to the carton and the label. And the 810 is the invoice — you asking to get paid for it.
That's the loop. PO in, acknowledgment out, ship notice out, invoice out. None of it is conceptually hard. All of it has to be exactly right, because the whole point of EDI is that no human is checking it on the way through.
Why "connected" isn't "working"
Here's the distinction that matters. SPS Commerce — the dominant name in retail EDI, and the one your customer most likely mandated — along with providers like TrueCommerce, Cleo, and OpenText, is good at the part it owns: the trading-partner handshake. They speak your retailer's dialect, they manage the connection, they keep up with the maps and the mandates so you don't have to. That half genuinely works, and it's why they exist.
The half that breaks is the one nobody sells you: the connection between that EDI layer and your ERP. The 850 has to become a real order in your system. The ASN has to be built from what your warehouse actually packed, not from what the order optimistically said. The 810 has to match both. When those hand-offs are manual, or approximate, or bolted together by someone who's since left, "connected" and "working" drift apart — and you feel it as chargebacks.
Chargebacks are a data-integrity problem
This is the reframe that saves shops the most money. A chargeback feels like a paperwork penalty, so it gets treated like one — someone disputes it, someone eats it, everyone moves on and it happens again next month.
But trace almost any chargeback back to its root and you'll find a mismatch: the ASN said the pallet held twelve cases and it held eleven; the label didn't match the carton; the notice arrived after the truck did; the invoice quantity disagreed with what shipped. That's not a paperwork problem. That's your ERP and your dock telling two different stories, and EDI faithfully broadcasting the disagreement to a customer who fines you for it. Fix the data integrity between the systems and the chargebacks dry up, because there's no longer a lie to catch.
Where SPS Commerce ends and your integration begins
I'm not here to dunk on SPS Commerce — they do the trading-partner side well, and rebuilding that yourself would be a bad use of your life. The fair way to think about it is a division of labor. They own the connection to your retailer. You own the connection to your own ERP. The second half is the half that bites, and it's the half consultants conveniently forget to mention when the project is scoped as "get us on SPS."
If your ERP is Ross, this is familiar territory — Ross was never designed to speak EDI natively, so the mapping between Ross orders, shipments, and invoices and the 850/855/856/810 loop is exactly the kind of integration work that either gets done carefully or gets done again.
Getting it right
Doing this properly is unglamorous and entirely achievable. Map the documents to real transactions in the ERP, in both directions, so nothing depends on a human retyping anything. Build the ASN from actual pack data, not from the order's hopes. Put reconciliation underneath it so a mismatch gets caught by you before it gets caught by your customer. And test against the partner's actual spec before go-live, because "it passed in the demo" and "it survives a real purchase order" are, once again, two different things.
Do that, and EDI stops being a monthly tax on your patience and goes back to being what it's supposed to be: boring infrastructure that quietly works.
The bottom line
Being mandated onto EDI is not the same as EDI working, and the difference lives in the gap between the provider and your ERP. SPS Commerce handles the handshake; the integration to your own system is on you, and it's where the chargebacks are born. Treat it as the data-integrity problem it actually is, and the penalties — and the low-grade dread every time that customer's name appears — go away.
Compliant on paper, still bleeding chargebacks? The fix is usually between the EDI layer and your ERP. Let's find it →. Related: the integration archetypes nobody names.
Most integration projects go sideways because nobody named the shape of the thing before building it. Here are the shapes.
Ross was never built to hand off cleanly to a modern WMS, so they drift. On a plant floor, drift isn't untidy — it's a compliance and cash problem.
NACHA files keyed by hand, payments typed into a bank portal, statements reconciled by eye. Every step is real money and one typo from the wrong account. It doesn't have to be.
learned it the hard way so you don't have to — one email starts it