EDI integration is the engineering that connects your ERP, WMS or TMS to your trading partners' X12 documents, so an 850 purchase order becomes an order in your system, an 856 ship notice leaves when the truck leaves, and an 810 invoice matches what you billed. It is not a product you install. It is a set of mappings, transport connections and error paths, built per partner, that fails with financial consequences when any one of them drifts.
That definition matters because it explains everything that follows: why the same 856 fails at one retailer and passes at another, why go-live is not the end of the work, and why the three build paths below cost what they cost.
The five ways EDI integration actually breaks
Most integration projects survive their test plan. They die in the first six months of production, in one of five places.
Mapping drift. A map is a translation table between your fields and a partner's segments, and it was written against one version of the partner's guide. Partners update guides without version numbers in the subject line. A field moves, a qualifier list changes, a segment goes from optional to mandatory. The map keeps validating and starts mis-translating. The failure shows up days later, as a deduction or a phone call, far from its cause.
Partner-specific dialects. The standard defines the envelope; the partner defines the language. The same 856 advance ship notice is not the same 856 at two retailers. Hierarchy requirements, timing windows, label formats and chargeback schedules differ per partner, and the differences live in 40-page implementation guides, not in the X12 standard. A map built "to spec" is built to the wrong spec until it is built to the partner's.
Acknowledgement gaps. Every outbound transaction should generate a 997 functional acknowledgment, and someone should know when one does not arrive. In practice almost nobody watches 997s. Rejections accumulate silently until a customer calls or a penalty letter arrives. The monitoring problem is the cheapest failure on this list and the most common.
Item-master disagreement. Your SKU, the partner's item number, the UPC, the GTIN. Somewhere one of them is wrong or missing, and the translation fails at runtime, per line item. Item-master failures look like EDI failures, get debugged as EDI failures, and are fixed in the item master.
Version upgrades. When a partner moves you from one X12 version to another — 4010 to 5010 is a common one — the version line in ISA and GS changes, but the real work is the partner guide that changed at the same time. Projects that tested only against the standard pass their tests and fail in production. Projects that tested against the partner's new guide pass both. Testing against a translator's idea of the standard is where the false confidence comes from.
Three integration paths, priced honestly
There are three ways to get documents moving, and the honest choice depends on how many partners you have, how supported your ERP is, and how much your own roadmap depends on the answer.
1. A connector for a supported ERP. If you run NetSuite, SAP, Acumatica or another ERP with an EDI ecosystem, a prebuilt connector plus the vendor's mapping service is the cheapest path by a wide margin. You pay per partner or per document, the vendor maintains the maps, and onboarding a standard partner takes days. The limit of this path is precise: it ends where your process stops matching the connector's model. Custom documents, non-standard flows, a homegrown system, or a partner whose guide the connector has never seen — at that point you are paying the vendor to say no. Typical subscription pricing is per trading partner and per document set, on top of any VAN or AS2 transport costs. Where the connector stops at your process, that is the work we do.
2. Middleware or iPaaS. An integration platform gives you a mapping editor, a transport layer and monitoring, and your team or a partner configures the maps. This is the middle path: cheaper than engineering, more flexible than connectors, and dependent on the platform's connectors for everything it touches. The recurring subscription is real money at scale, and the platform's model of your business becomes your model of your business. If you already run an iPaaS, EDI on it is usually the right call. If you do not, buying one only for EDI is rarely the cheapest route.
3. Engineered integration. Your documents, mapped and owned by you: a translation layer between your systems and your partners' X12, with acknowledgment monitoring and per-partner configuration. The upfront cost is higher than either product path, and the ongoing cost is engineering time rather than subscription fees. This path pays off in exactly three situations: your ERP has no connector (custom or legacy ERP); your partner count or document volume makes per-partner fees compound past the cost of owning the layer; or your process is the product, and a 3PL selling retail fulfillment cannot run on a connector's idea of an ASN.
The honest part of this page: for a company with a supported ERP, three standard partners and no roadmap pressure, path 1 is the right answer and we would say so in the call. The engineering path is for the company that has already discovered path 1's limit.
We have shipped X12 940, 945 and 856 through SPS Commerce, and integrated NetSuite, Microsoft Dynamics 365 Business Central, SAP Business One and Acumatica on the ERP side, Manhattan, Körber (HighJump) and Blue Yonder on the WMS side.
By your ERP
The integration problem changes shape with the system on your side of the wire.
- EDI integration with a custom, legacy or homegrown ERP — the page for the company whose system has no connector, and what the build actually involves
By document
Each reference page covers what the document carries, why yours gets rejected, and what the failure costs.
- EDI 856 — advance ship notice: the document that generates chargebacks. HL hierarchy, UCC-128 labels, dock failures
- EDI 940 — warehouse shipping order: the instruction from shipper to warehouse, segment by segment, plus the rejection catalog
- EDI 945 — warehouse shipping advice: the confirmation nobody reconciles against what actually left the dock
- EDI 850 — purchase order: the document every onboarding starts with, and the five fields the rest of the chain depends on
- EDI 810 — invoice: where billing leakage is born
- EDI 997 — functional acknowledgment: the document everyone automates and nobody reads
By trading partner
Retailer compliance is the same documents with a chargeback schedule attached. We publish one page per retailer only when we can source the retailer's real requirements: document set and versions, connectivity method, chargeback schedule, certification sequence, and a failure mode we have actually seen.
The remaining retailer pages are gated, not scheduled: a retailer whose guidelines we cannot verify does not get a page.
What this work produces, in numbers
Two engagements from our casebook describe the shape of the outcome better than any feature list.
A non-asset 3PL with major US retail accounts was hand-building EDI maps from scratch for every new trading partner. Every new retail contract started earning 8–10 weeks after signature, and chargebacks accumulated before the account turned profitable. We built an EDI accelerator with prebuilt maps for the 850, 856, 810, 940 and 945 documents against large-retail profiles, configured per partner without code changes, plus SSCC-18 label generation tied to pick confirmation and 997 monitoring with a 15-minute rejection alert. Onboarding moved from 8–10 weeks to 12 days (case C05).
A regional US freight 3PL was reconciling freight invoices in Excel after the fact. Accessorials went unchallenged, some delivered services were never billed, and one carrier API change stopped the rating flow for three weeks. We built a carrier adapter layer behind a single internal API and a dedicated audit service comparing every billed line against contracted rates. Monthly losses fell from $45,000 to $3,800, new carrier onboarding moved from three weeks to four days, and audit coverage reached 87% of invoice volume with no manual touch (case C01).
The common thread: the fix is not a document translation. It is the monitoring, the reconciliation and the per-partner configuration around it.
When a connector is the right answer
Buy the connector when: your ERP has a maintained EDI connector; your partners are standard enough that the connector lists them; your document set is the common three or four; and nothing on your roadmap depends on the integration being yours. That describes a large share of companies, and the connector vendors serve them well.
Hire engineers when: your system has no connector, your process deviates from every connector's model, your partner count makes per-partner pricing compound, or the integration is on the critical path of revenue — as it is for a 3PL whose retail accounts demand compliant ASNs before the first pallet earns.
How we start
A two-week diagnostic at $7,500, fixed price and fixed scope. We map your current document flows, your partners' guides, and the gap between them, and the findings document is yours whether or not we build anything together. Most audits end with one of three verdicts: buy the connector, fix the maps you have, or build the layer. All three are useful answers. Details on the diagnostic page.
Related reading
- EDI integration with a custom or legacy ERP
- EDI 856: HL structure and chargeback failures
- EDI 940: segments, rejections and mapping
- 3PL with retail clients: the buyer-side view
Written by the CrunchCode engineering team — the people who ran these integrations in production.