What EDI actually is
Electronic Data Interchange (EDI) is the structured, computer-to-computer exchange of business documents between trading partners. Not emails. Not PDFs. Structured data — in a standardised format — that flows directly from one business system into another without human intervention.
When a retailer sends you a purchase order, they're not emailing a PDF. They're transmitting an EDI 850 transaction — a formatted file that your ERP can parse and convert directly into a sales order. When you ship the goods, you send back an EDI 856 Advance Ship Notice. When you invoice, an EDI 810. The whole transaction cycle — order, acknowledgement, shipment, invoice, payment — can happen with no one manually touching a document.
EDI has been around since the 1970s. It predates the internet. And despite being decades old, it still underpins the majority of B2B commerce between manufacturers, retailers, distributors, and logistics providers. If you sell to a major retailer, automotive OEM, or large distributor, EDI isn't optional — it's a contractual requirement. Failure to comply isn't just inconvenient; it typically comes with financial chargebacks.
The transaction sets you'll actually encounter
EDI standards define hundreds of transaction types, but manufacturing companies typically deal with a core set:
The specific transaction sets, versions (X12, EDIFACT, RosettaNet), and field requirements vary by trading partner. A Walmart 850 and a Target 850 are both "purchase orders" but they have different mandatory fields, different code values, and different validation rules. This is why EDI is harder than it looks.
"Every trading partner has their own EDI implementation guide. The standard defines the format. The guide defines the requirements. They are not the same document."
Why EDI implementations are brittle
EDI implementations fail in predictable ways. Here are the four failure patterns we encounter most often:
1. Mapping as a one-time project
EDI maps — the translation rules between your internal data model and the EDI format — are built once, deployed, and forgotten. Then your trading partner updates their implementation guide. Or you change your item numbering system. Or you add a new warehouse. The map is now wrong, and transactions start failing silently. Without active monitoring, you find out when a chargeback arrives.
2. The 997 trap
A 997 Functional Acknowledgement tells you the transmission arrived and was syntactically valid. Many teams treat a 997 as confirmation that the document was processed. It isn't. A trading partner can send a 997 and then reject the underlying document in their own system. You need to track application-level acknowledgements — not just transmission receipts — to know whether an order was actually accepted.
3. No ERP integration — the "EDI mailbox"
The most common EDI architecture we inherit is what we call the "mailbox" model: EDI transactions arrive at a VAN or SFTP server, and someone downloads them manually and imports them into the ERP. This is EDI without the "Electronic" part. The transmission is automated; the processing isn't. Manual imports mean delays, errors, and a person in the middle who becomes a bottleneck and a single point of failure.
4. Trading partner onboarding as a crisis
Adding a new trading partner — or onboarding to a new retailer's EDI requirements — typically takes weeks and requires a developer. Each partner has their own requirements, their own test environment, their own certification process. If your EDI infrastructure isn't designed to onboard new partners quickly, every new customer relationship starts with a project.
Architecture: VAN, AS2, or API?
There are three main ways EDI documents get transmitted between trading partners, and most manufacturers end up using all three depending on who they're trading with:
The right answer is usually a managed EDI platform (SPS Commerce, TrueCommerce, DiCentral, or a similar provider) that handles the connectivity layer — VANs, AS2, SFTP, APIs — and translates between EDI formats and a standardised internal format. Your integration work then connects that platform to your ERP, rather than connecting to each trading partner individually.
Critical distinction
EDI connectivity (getting documents in and out) and EDI integration (connecting those documents to your ERP business processes) are two separate problems. Most EDI providers solve the first. The second is where most of the implementation work lives.
ERP integration: where the real work is
Getting an EDI 850 into your system is the easy part. Turning it into a sales order in your ERP — with the right customer, the right items mapped to your internal part numbers, the right prices validated against your price book, the right warehouse assigned based on ship-to address — that's where the complexity lives.
Here's what a properly integrated EDI-to-ERP flow looks like for the order cycle:
Chargebacks: the hidden cost of getting EDI wrong
Most large retailers operate compliance programmes that fine suppliers for EDI errors. Late ASNs, incorrect carton labels, invoices that don't match the PO, missing transaction sets — each of these triggers a chargeback that can range from a flat fee to a percentage of the invoice value.
For a manufacturer doing $20M/year with a major retailer, chargeback exposure from EDI non-compliance can easily run into six figures annually. We've seen cases where a manufacturer's entire margin on a retailer relationship was being eroded by chargebacks — chargebacks caused not by product issues but by EDI timing and formatting errors that were entirely preventable.
The fix is almost always the same: automate the ASN generation so it fires within minutes of shipment confirmation, validate invoices against the originating PO before transmission, and build monitoring that alerts on transmission failures before the trading partner's deadline passes.
How to get EDI integration right
Based on what we've seen work, here's the framework we apply to EDI integration projects:
EDI is one piece of the integration picture
EDI handles the B2B layer — the trading partner relationships. But inside your four walls, you still have ERP, MES, WMS, PLM, and CRM that need to talk to each other. EDI data that flows cleanly into your ERP and then gets re-keyed into your WMS has only solved half the problem.
If you're thinking about EDI integration, it's worth considering the broader integration architecture at the same time. Our post on manufacturing system integration → covers the internal integration patterns that complement a solid EDI implementation.
Talk through your EDI workflow, not just the file format
If EDI is creating chargebacks, manual work, or poor visibility, the issue is usually deeper than document transmission. It is the workflow between trading partner messages, ERP processing, and operational timing.