The plain-English definition of EDI
Electronic data interchange is the computer-to-computer exchange of business documents between two companies in a standard electronic format. The key words are standard and computer-to-computer. Before EDI, a purchase order lived on paper or in an email: a buyer printed or typed it, a supplier's clerk read it and rekeyed the lines into their own order system, and every rekeying step added delay and the chance of a typo. With EDI, the buyer's system generates the purchase order as a structured electronic document, transmits it, and the supplier's system reads it and creates the sales order automatically. No fax, no PDF attachment, no data entry.
What makes this work is that both sides agree on the format in advance. An EDI document is not a free-form file; every field, the buyer's account number, the item identifiers, the quantities, the delivery date, sits in a defined position governed by a published standard. That rigidity is EDI's whole value: because the format is agreed, a supplier in Ontario can exchange documents with a retailer in Arkansas without either side ever looking at the other's software. EDI predates the web, and large retail, grocery, automotive, and logistics supply chains have decades of process built on it, which is why it remains the default language of high-volume B2B trade even in 2026.
How EDI documents actually work: 850s, 810s, and the rest
EDI documents are called transaction sets, and each common business document has a numbered type. In North America the dominant standard is ANSI X12, where a purchase order is an 850, an invoice is an 810, and an advance ship notice is an 856. Internationally, the UN's EDIFACT standard plays the same role with named message types (ORDERS, INVOIC, DESADV) instead of numbers. The two standards do not interoperate directly, so companies trading across both worlds typically rely on translation software or a provider that speaks both.
A typical retail order cycle chains several of these documents together. The retailer sends an 850 purchase order. The supplier commonly responds with an 855 acknowledgment confirming what it can fulfill, then sends an 856 advance ship notice as the goods leave the warehouse, so the retailer's receiving dock knows exactly what is on the truck, and finally an 810 invoice. A small technical receipt called a 997 functional acknowledgment typically confirms each transmission arrived and parsed. Transport between partners historically ran through value-added networks (VANs), essentially secure mailbox services, while many trading partners now also support direct connections over protocols like AS2 or SFTP. The exact document mix varies by trading partner, but the pattern is consistent.
| X12 document | What it is | Who typically sends it |
|---|---|---|
| 850 | Purchase order | Buyer (retailer, distributor) |
| 855 | Purchase order acknowledgment | Supplier |
| 856 | Advance ship notice (ASN) | Supplier, as goods ship |
| 810 | Invoice | Supplier |
| 940 / 945 | Warehouse shipping order / shipping advice | Brands working with 3PL warehouses |
| 997 | Functional acknowledgment (receipt) | Either side, automatically |
EDI vs ERP vs API: three different things that get confused
These three acronyms travel together and get mixed up constantly, so here is the clean separation. An ERP is your internal system of record: the software where your orders, inventory, accounting, and customers live. EDI is a communication standard between companies: the agreed format two separate businesses use to exchange documents. An API is a general-purpose way for two pieces of software to talk to each other in real time, and it is the mechanism behind most modern integrations. Asking "EDI vs ERP" is a bit like asking "postal service vs filing cabinet": one moves documents between organizations, the other stores and processes them inside yours. They are not alternatives; a company that trades via EDI still needs somewhere for those documents to land, and that somewhere is usually the ERP.
EDI vs API is the more genuine comparison, because both move data between systems. EDI is batch-oriented, document-shaped, and standardized across thousands of trading partners; an API is typically real-time, flexible, and specific to whoever built it. Large retailers keep EDI because it lets them onboard any supplier against one published specification instead of building custom API integrations with each vendor. Modern platforms increasingly offer APIs alongside EDI, and plenty of supply chains run both, but when a big-box trading-partner guide lands on your desk, it will almost always be written in EDI terms.
- ERP: your internal system of record for orders, stock, and accounting.
- EDI: the standardized document format exchanged between separate companies.
- API: the real-time software-to-software mechanism behind most modern integrations.
- In practice: EDI documents flow in and out, and the ERP is where they are processed.
How EDI integrates with an ERP like Odoo
EDI only earns its keep when the documents flow straight into your workflows. A translated 850 that someone still has to retype into the order screen has saved nothing. In an integrated setup, an inbound 850 creates a sales order in the ERP automatically, complete with the right customer, pricelist, and delivery address; confirming the shipment generates the 856 from the actual picked quantities; and validating the invoice produces the 810. The ERP is the source of truth, and the EDI layer, whether a managed provider, a translation service, or a direct connection, is plumbing on the edges. In our integration work with Odoo this is typically built either through a managed EDI provider that exposes an API Odoo can talk to, or through custom connectors, and the mapping between each trading partner's specification and Odoo's order fields is where most of the real project effort lives.
The most common trigger we see is retail and big-box compliance. When a mid-size food producer lands its first listing with a major grocery banner, or a consumer brand gets a purchase order from a national chain, the trading-partner agreement typically mandates EDI from day one: orders arrive as 850s, shipments must be announced with an 856 and carton-level labeling, and invoices must match or the supplier risks compliance chargebacks that eat directly into margin. The same pattern applies to suppliers working with large distributors and to brands shipping through 3PL warehouses, where the 940/945 pair keeps the ERP's inventory in sync with the warehouse floor. We covered the Canadian retail angle specifically in our guide to Odoo EDI integration for Canadian B2B and wholesale, and our integration service is the team that builds these connections.
What EDI software costs, and when a business actually needs it
EDI pricing is quote-heavy, but the structure is knowable. Costs typically stack in three layers: a setup or onboarding fee per trading partner (each retailer's specification has to be mapped and tested), a recurring subscription to the EDI provider or VAN, often scaled by document volume or number of trading partners, and the integration work that ties the documents into your ERP. Fully managed web-EDI portals sit at the cheap end but leave you retyping data by hand, which defeats the point past a handful of orders; integrated EDI costs more up front and then removes the per-order labor entirely. As a rule of thumb, the more trading partners and the more order volume you have, the faster an integrated setup pays back.
As for whether you need it at all: EDI is a requirement-driven purchase, not an aspiration. If no trading partner mandates it and your order volume is manageable by email and portal entry, you can skip it without guilt. The genuine triggers are a retailer or distributor contract that requires EDI compliance, order volume high enough that manual entry is producing errors and chargebacks, or a 3PL relationship that needs automated warehouse messaging. If one of those describes you, the practical next question is what your specific setup would cost, and we built a free tool for exactly that: it walks through your trading partners, document types, and volume, and produces a readiness picture and cost estimate for an Odoo-integrated EDI setup.
Run the free Odoo EDI readiness & cost estimator →