EDI (Electronic Data Interchange) is a structured protocol for exchanging business documents between trading partners electronically — without email, fax, or manual data re-entry at either end. Instead of a buyer emailing a purchase order PDF and a supplier emailing back a confirmation, EDI replaces each message with a machine-readable transaction set that both systems parse automatically. A closed-loop procurement platform — one where ordering, supplier reply, receiving, and accounting handoff run in one connected record without retyping — treats inbound EDI transaction sets as one of several supplier-reply channels to ingest alongside email, WhatsApp, and web portals.
Quick answers
What is EDI in procurement? EDI is the exchange of procurement documents — purchase orders, acknowledgments, ship notices, and invoices — using standardized electronic formats that trading-partner systems parse directly. Neither party's team retypes the order details; the documents flow machine-to-machine.
What is the EDI 850? The EDI 850 is the purchase order transaction set in the ANSI X12 standard. When a buyer transmits an 850, the supplier's system receives a structured order — items, quantities, unit prices, requested ship date, addresses, and payment terms — in a format their system can process without manual entry.
What is EDIFACT? EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) is the international EDI standard. Where X12 is the North American convention, EDIFACT is dominant in Europe, Asia, and Latin America. The EDIFACT equivalent of the X12 850 is the ORDERS message; the EDIFACT equivalent of the X12 810 invoice is INVOIC.
Do SMBs actually need EDI? It depends on the supplier base. Large retailers, distributors, and industrial suppliers often require EDI as a condition of doing business. Independent food distributors, specialty suppliers, and local vendors typically reply by email or WhatsApp and have no EDI infrastructure. A procurement system that handles only EDI misses the long tail of suppliers; one that handles only email misses the mandated relationships. SMBs with a mixed supplier base need both.
How is EDI different from an email PO? An email PO is a human-readable document delivered as an attachment or body text — a person can read it, but their system cannot parse it without manual entry. An EDI document is a structured data stream a recipient's system processes directly. EDI eliminates re-entry at both ends for the relationships that justify the setup cost; email is faster to implement for the long tail of suppliers who have no EDI infrastructure.
The four core procurement transaction sets
EDI breaks the buying loop into discrete, numbered transaction sets. For buyers ordering physical goods, four transaction sets run in a cycle that mirrors the PO lifecycle.
X12 850 — Purchase Order
The 850 is the buyer's purchase order transmitted to the supplier. It contains the same fields as a PO document — item identifiers (UPC, GTIN, or the supplier's own SKU), ordered quantity, unit price, requested ship date, bill-to and ship-to addresses, payment terms — structured into segments the supplier's order management or ERP system can process without re-entry.
An 850 is how large retailers order from vendors. For a supplier receiving an 850, the order lands directly in their system, not in an inbox.
X12 855 — Purchase Order Acknowledgment
The 855 is the supplier's response to the 850. It confirms or modifies the buyer's order — accepted as-is, accepted with changes, or rejected. A properly structured 855 carries:
- Line-level accept / reject / change status
- Confirmed quantity per line (which may differ from ordered quantity if constrained)
- Confirmed unit price
- Estimated ship date
- Backordered or substituted line indicators
In a closed-loop procurement workflow, the 855 is the event that updates the purchase order from Sent to Confirmed — and the confirmed quantities, prices, and dates are what the three-way match runs against at receiving and invoice time. Receiving an 855 and not updating the PO state defeats the purpose of EDI: you get machine-to-machine delivery but still reconcile manually.
X12 856 — Advance Ship Notice (ASN)
The 856 is the supplier's shipment confirmation, sent when goods leave the warehouse. It contains:
- Line-level shipped quantity (which may differ from the confirmed 855 quantity if a partial ships)
- Tracking or PRO number
- Actual ship date
- Packaging structure: cases per pallet, units per case
The ASN gives the buyer advance visibility into what is inbound before it arrives at the dock. If the 856 shows the supplier shipped 80 of 100 ordered units, the receiving team knows to expect a partial shipment before the truck arrives — the receiving record can be pre-populated and the outstanding balance tracked against the open PO.
X12 810 — Invoice
The 810 is the supplier's invoice in structured form. It should reflect the quantities shipped per the 856 and the prices confirmed in the 855. The AP matching step compares the 810 against both — this is the EDI version of three-way matching.
When the upstream documents were in sync — the 850 was acknowledged, the 856 matched the 855, and the 810 reflects what shipped at the confirmed price — the AP match is clean. When they were not in sync, the 810 triggers a match exception with a pre-calculated dollar variance that routes to a human reviewer.
EDIFACT equivalents
| X12 (North America) | EDIFACT (International) | Document |
|---|---|---|
| 850 | ORDERS | Purchase order |
| 855 | ORDRSP | Order acknowledgment |
| 856 | DESADV | Despatch advice (ASN) |
| 810 | INVOIC | Invoice |
| 832 | PRICAT | Price/catalog update |
How EDI fits into closed-loop procurement
Standard EDI implementations treat each document as a discrete exchange: send the 850, receive the 855, file it, manually act on the information. That is EDI as a document-transport layer.
The procurement-loop version treats each document as an event that updates shared order state:
- 850 sent — the purchase order is transmitted. PO status moves from Draft to Sent.
- 855 received — the system parses the acknowledgment and applies confirmed quantities, prices, and delivery dates as a reviewable PO update. The operator approves or overrides the diff. PO moves to Confirmed.
- 856 received — the advance ship notice pre-populates the receiving record. Dock staff can verify inbound shipment contents before the truck arrives. PO moves to In Transit.
- Receiving — actual received quantities are captured against the pre-populated receiving record. Short shipments or unexpected substitutions that appeared in the 856 are flagged immediately, not discovered at the invoice stage.
- 810 received — the invoice is matched against 855-confirmed prices and actual receiving counts. If numbers reconcile within tolerance, the bill routes to accounting with audit context. If not, the dollar variance is pre-calculated and the exception goes to a human reviewer.
This is the same loop that runs for email and WhatsApp-based supplier replies. EDI is the machine-readable version of the same supplier conversation — with the same obligation to close the loop on the buyer side by updating order state from each inbound document.
EDI implementation: brokers, VAN, and native
There are three common implementation paths:
Managed EDI brokers and VANs
Traditional EDI uses a Value-Added Network — a clearinghouse that routes documents between trading partners. Brokers like SPS Commerce and TrueCommerce handle translation between the buyer's data and the X12 or EDIFACT structure, then route through the VAN. Buyer-side broker costs typically run $200–$500/month plus per-transaction fees for high volumes and one-time setup fees per trading partner.
Brokers make sense when the buyer has high EDI volume with large retail trading partners and needs managed compliance with retailer-specific EDI specification guides — each major retailer publishes proprietary EDI guidelines that deviate from the base standard. The trade-off: brokers add cost and create a separate reconciliation lane outside the procurement workflow. The 855 acknowledgments land in the broker's interface, not in the PO record.
EDI API services
Newer services expose EDI exchange through REST APIs, reducing VAN overhead. Trading-partner setup and document mapping are still required, but the document exchange can be integrated directly into procurement software rather than routed through a separate interface.
Native EDI in a procurement platform
A procurement platform with native EDI handles exchange internally — the 850 is the platform's PO transmission format for EDI-capable suppliers, inbound 855s and 856s update the PO state directly, and the 810 feeds the matching workflow. No separate broker interface to reconcile against the PO.
For SMBs with a mixed supplier base — some EDI-capable, some email-only, some WhatsApp — native procurement handling of all three channels in the same order record solves the fragmentation problem where EDI documents arrive in one system and email replies arrive in another, and a person must manually reconcile them against the same purchase order.
When SMBs actually need EDI
EDI is not a universal requirement. Two situations clearly justify setup cost and complexity:
1. A large trading partner requires it. A major retailer, industrial distributor, or big-box supplier has a vendor EDI compliance program. They issue EDI 850s and expect 856 ASNs in return. Non-compliance can mean chargebacks or losing the account. EDI setup is not optional for those relationships.
2. Order volume with a supplier exceeds the manual-entry threshold. If a buyer sends 20+ POs per week to the same supplier, machine-to-machine exchange eliminates meaningful overhead at both ends. The setup cost pays back quickly at that volume.
For an SMB buying from a regional food distributor, a specialty textile supplier, and a handful of small artisan producers — all of whom reply by email and have no EDI infrastructure — EDI setup adds friction without benefit for those relationships. They stay on email and WhatsApp. The right procurement architecture supports both channels in the same record, routing each supplier communication through whichever path that supplier actually uses.
How LineNow handles EDI
LineNow supports EDI X12 4010/5010 and EDIFACT D24A alongside email and WhatsApp as native supplier-communication channels. For EDI-capable suppliers, the platform transmits the 850 and ingests inbound 855 acknowledgments, 856 advance ship notices, and 810 invoices — updating purchase order state directly without a separate broker reconciliation lane. For non-EDI suppliers, the same procurement loop runs through email and WhatsApp, with AI-parsed supplier replies updating the same PO record.
For a manufacturer or specialty retailer with a mixed supplier base, all supplier channels — EDI, email, WhatsApp, portal — converge on the same living purchase order. The closed-loop runs in one place regardless of which channel a given supplier uses.
Start your 90-day free trial at linenow.co — connect your first EDI-capable supplier alongside your email and WhatsApp relationships.
Related
- Purchase Order (PO): Definition, Anatomy, Lifecycle, and Why SMBs Need Them — the source document that the EDI 850 transmits and the 855 acknowledges
- Three-Way Matching: What It Is, How It Works, and Why It Breaks at SMB Scale — EDI 810 invoices run through the same matching logic as paper and PDF invoices; 855 and 856 upstream documents make the match cleaner
- Blanket Purchase Order (Blanket PO): What It Is, How Releases Work, and When to Use One — blanket POs with large retail trading partners are typically implemented as EDI blanket orders; the 850 is the release transmission and the 855 acknowledges it against the blanket commitment
- Email Invoice Parsing for B2B Supplier Payments and POs — how AI-parsing of supplier email replies works alongside EDI ingestion when suppliers use different channels
- Procurement for SMB Manufacturers: BOMs, Long Lead Times, EDI, and Closing the Loop — how manufacturers integrate EDI with multi-level BOM demand, statistical replenishment, and closed-loop receiving
- Closed-Loop Procurement: Forecast, Buy, Receive, Repeat