EDI didn’t go away when everything went API
Every new system speaks API. Your biggest customers still send an 850 and expect an 856 back that matches the cartons on the truck. EDI isn’t legacy you can ignore — it’s the contract that decides whether you get paid in full.
Why EDI matters more, not less
It’s easy to assume EDI is on its way out. New marketplaces, shipping platforms and payment tools all connect by API, and integration conversations increasingly start with “do they have an endpoint?” But the big-box retailers, national distributors and buying groups that make up a large share of many suppliers’ revenue still run their purchasing on X12 EDI, and their vendor compliance manuals are written around it.
The API world actually raises the stakes. Your shipping system, your marketplaces and your ERP now exchange data in real time, and your EDI partners expect the same accuracy and speed. A carton count or tracking number that is right in the API-driven parts of the business and wrong on the ASN is still wrong, and the partner who receives it is the one who fines you.
The documents that run the relationship
| Doc | What it is | What goes wrong |
|---|---|---|
| 850 | Purchase order from the partner | Fails to import on a price or item mismatch; nobody notices until the partner asks where the order is. |
| 855 | PO acknowledgement back to them | Sent late or not at all; the partner treats the order as unconfirmed. |
| 860 | PO change | Applied to the wrong lines, or not applied before the order ships. |
| 856 | Advance ship notice: what’s in every carton, with tracking | Missing tracking, cartons that don’t match the labels, or sent after the truck arrives. |
| 810 | Invoice | Doesn’t match the PO or the ASN, so payment is held or short-paid. |
| 846 | Inventory advice | Stale quantities, so the partner orders what you can’t ship or skips what you can. |
| 997 | Functional acknowledgement | Ignored, so a rejected document goes unnoticed. |
What a bad ASN actually costs
Retail compliance programs are specific and they’re enforced. An 856 that arrives after the shipment, lists cartons that don’t match the GS1-128 labels, or carries no tracking number can trigger a chargeback per shipment, a deduction from the invoice payment, or a manual receiving fee at the distribution center. One of those is an annoyance. A month of them is margin you didn’t know you were giving away, usually found when someone in AR tries to work out why a large customer keeps short-paying.
EDI errors don’t show up as errors. They show up as deductions.
The 846 is the quiet one. It tells a partner what you can ship, and like a marketplace listing it is a promise. Overstate it and you take orders you can’t fill; understate it and the partner buys elsewhere.
Onboarding a trading partner well
A new EDI customer is good news that arrives with a compliance manual. Whichever provider carries the documents — OpenText, SPS Commerce, TrueCommerce or one of the others — doing the setup well is mostly about decisions made up front:
- Which documents, which versions. Not every partner wants every document, and each has its own X12 version and segment rules. The setup should be exactly what this partner’s guide requires, nothing borrowed from the last one.
- Mapping to how the ERP really works. Partner item numbers to your items, their ship-to codes to your addresses, their units to yours, and their price list to the one the 850 will be checked against.
- Where each outbound field comes from. The 856 needs carton contents and tracking that often live in the shipping system, not the ERP. Decide how they get there before the first shipment, not after the first chargeback.
- Testing that looks like real life. Partial shipments, backorders, multi-carton freight, kits and price changes — the cases that break mappings — tested before certification, not discovered after go-live.
- Exceptions someone can act on. A failed 850 or a rejected 856 should land as a short, specific item in a queue with the document number and the reason, not buried in an email nobody can parse.
Where APIs and EDI meet
The real work now is the seams. The shipping platform knows the cartons and the tracking. The ERP knows the order, the item and the price. The EDI provider — OpenText, SPS Commerce, TrueCommerce and the like — knows the partner’s format and transmits it. When those three hand data to each other cleanly and on time, the ASN is right without anyone touching it. When they don’t, freight tracking that arrives a day later never makes it onto the ASN, a kit and an assembly sharing a part number break carton matching, and an import failure hides in a notification that names no document.
We’ve set up new trading partners end to end — connections, mappings, and customizations around 850s, 855s, 856s, 810s and 846s — and built the pieces that keep shipping data flowing into the ASN. The technical lessons are in the companion piece.
The short version
- EDI is still how many of your largest customers buy, and they enforce it with deductions.
- The ASN is where most of the money is lost, and it depends on data from more than one system.
- Onboard each partner to its own guide, map to how you actually operate, and test the awkward cases.
- Make every failure a specific, actionable exception — not an email.
Related: getting shipping data onto the ASN, and selling it at the price you meant.