EDI 850 (Purchase Order)
EDI 850 is the ANSI X12 transaction set that transmits a purchase order electronically from a buyer to a supplier — item numbers, quantities, unit prices, and ship-to details — in place of a faxed, emailed, or portal-entered PO. It's a one-way, buyer-to-supplier document: X12's own specification states it isn't meant to convey a PO change or a PO acknowledgment, which travel as separate transaction sets.
What's inside an 850
The transaction set carries a consistent structure across X12 versions, though the specific elements required vary by version (003010 through 008040 and beyond) and by trading partner:
- BEG segment — order identification: PO number, date, and order type.
- PO1 loop — one iteration per line item: quantity, unit of measure, unit price, and the product or part identifiers (a buyer's SKU, a UPC, or the vendor's own part number).
- TD5 segment — routing and carrier instructions for the shipment.
- REF and N1 segments — reference numbers and the ship-to/bill-to parties.
A specific retailer's implementation guide, not the generic X12 spec, governs exactly which fields are required and how they're coded — that mapping work happens once, during supplier onboarding.
Where it sits in the order cycle
The 850 is the first of several EDI documents that typically move in a fixed sequence:
| Transaction | Direction | Carries |
|---|---|---|
| 850 Purchase Order | Buyer → Supplier | The order itself |
| 855 PO Acknowledgment | Supplier → Buyer | Accept, reject, or propose changes |
| 856 Advance Ship Notice | Supplier → Buyer | What's actually shipping, and when |
| 810 Invoice | Supplier → Buyer | The bill for what shipped |
This runs in the opposite direction from EDI 832, which carries price and catalog data from supplier to buyer — the data the buyer's system draws on to build the 850 in the first place. The ASN that follows is a separate, dedicated glossary entry worth reading alongside this one.
What it requires from your product data
A PO1 line can only reference an item the supplier has already set up and can match against its own system — by GTIN, UPC, or vendor part number, whichever identifier the trading partner agreement specifies. If that identifier doesn't resolve to a known item on the supplier's side, the line typically bounces back as an exception rather than flowing through automatically.
That's why identifier cross-referencing and new item setup happen during onboarding, before the first PO is ever cut — an 850 arriving against an item that was never properly mapped doesn't fail gracefully; it stalls the order.
Frequently asked questions
What's the difference between an EDI 850 and an EDI 855?
The 850 is the buyer sending the order. The 855 is the supplier's response — accepting it as-is, rejecting it, or proposing changes. They travel in opposite directions, and a complete, acknowledged order cycle needs both.
Can an EDI 850 be used to change an order after it's sent?
No. X12's specification states the 850 is for placing an order, not for conveying purchase order changes or acknowledgment information — those use separate transaction sets, commonly an 860 for changes and an 855 for acknowledgment.
Does every retailer's EDI 850 look the same?
Structurally yes — the same segments appear across implementations — but which fields are required, which identifiers PO1 expects, and how qualifiers are coded differ by retailer and by X12 version. That detail lives in the retailer's own EDI implementation guide, which a supplier maps to during onboarding.
Does an EDI 850 require the item to already be set up on the supplier's side?
In practice, yes. The PO1 line identifies the item by GTIN, UPC, or vendor part number, and that identifier has to already exist and match in the supplier's system. This is why item setup and identifier mapping happen during supplier onboarding, ahead of the first purchase order.