An EDI 850 is an X12 purchase order: the document a buyer sends a seller to order goods, carrying the PO number, the ship-to and bill-to locations, the lines with quantities, prices and item IDs, and the delivery dates. It is the first document in every EDI onboarding and the most consequential one, because every document after it — the 940, the 945, the 856, the 810 — joins back to an 850 field. A wrong value here does not fail here. It fails weeks later, at the dock or on a remittance.
Why every onboarding starts with the 850
No partner certifies you on the documents that report reality first. They certify you on the document that creates the obligation: can you receive our purchase order, acknowledge it, and fulfill against it exactly?
That sequencing makes the 850 the template for the whole relationship. The item IDs your system accepts, the location codes you recognize, the date qualifiers you schedule on — all of it is established when the 850 map is built, and every later map inherits the choices. In the retail 3PL program behind these pages, the accelerator's prebuilt map set covered the 850, 856, 810, 940 and 945 together, precisely because the five documents are one data model viewed at five moments.
The segments that carry the order
BEG — beginning segment. The purpose code, the PO type, the PO number and the PO date. The number is the key that joins the entire chain: the 856's PRF segment carries it, the 810's BIG carries it, and reconciliation across all of them is a lookup on it.
REF — references. Vendor numbers, promotion IDs, department numbers: key-value pairs with partner-specific qualifiers. The buyer uses REF to carry identifiers its own systems need; your map has to know which ones matter.
FOB — freight terms. Who pays for the freight and how it is arranged: prepaid, collect, third party. Small segment, real money, frequently misread.
ITD — terms. Payment terms, encoded as type, basis, discount percent and day counts. The classic 2/10 net 30 lives here.
DTM — dates. The requested delivery date (qualifier 002) and, in retail, the delivery window: do-not-deliver-before and do-not-deliver-after qualifiers that turn a date into an appointment constraint.
N1 loop — parties. Ship-to, bill-to, vendor. Each carries a name plus the partner's own location code, and the ship-to code is what the fulfillment side validates against.
PER — buyer contact. Who to call when the order cannot be fulfilled as written.
PO1 — line item. Line number, quantity ordered, unit of measure, unit price, and the product ID pairs: the buyer's item number, the UPC/GTIN, the vendor part number, in whatever combination the partner sends.
CTT — trailer. Line count, closing the set.
The five fields that decide whether the chain works
Five fields in the 850 determine whether the rest of the documents can even be correct.
1. The PO number (BEG03). It must be unique per buyer, stable across changes, and stored exactly as sent. Every downstream join — ASN to order, invoice to order, the 945 back to the 940 — is a lookup on this string. A partner that renumbers POs on amendment, or a map that trims leading zeros, breaks joins silently and retroactively.
2. The ship-to code (N1*ST). The location code, not the address, is the operative value: the fulfillment system books work by code. If the code is not in your location master, the order cannot be accepted as-is. New stores and DCs are the recurring cause; the fix is a master-data process — a new location gets created before the first PO arrives, not after.
3. The product ID pair on PO1. The buyer sends the item under some combination of qualifiers: the GTIN, the buyer's item number, the vendor part number. Your item master has to carry the same cross-reference, and the map has to know which qualifier wins when they disagree. This is where new items fail first: the PO arrives before the cross-reference exists, and the line cannot be matched.
4. The requested delivery date and window (DTM). Retail delivery is an appointment, not a hope. The requested date plus the do-not-deliver-before/after qualifiers define when the receiver will actually accept the load. A map that reads the date but drops the window produces on-time shipments that get turned away.
5. Unit price and terms (PO104, ITD). The price on the line is the price the 810 will be checked against, and the terms define when payment is due. Any gap between the PO price and what the seller's system expects becomes a deduction later — not an error now. Price integrity at the 850 is the cheapest place to protect margin anywhere in the chain; the same asymmetry, on the carrier side, is how a regional freight 3PL accumulated $45,000 a month in unbilled and misbilled charges before automated reconciliation brought it to $3,800 (case C01).
Changes and acknowledgments: an 850 is not sent once
A purchase order is not a static document. Quantities move, dates slide, lines are cancelled. Partners handle changes in one of two ways: re-issuing the 850 under the same PO number with change markers, or sending an 860 — the dedicated purchase-order change document that carries per-line change actions. Your map has to know which convention the partner uses. A re-issued 850 treated as a new order creates a duplicate obligation; an amendment treated as informational loses the change entirely.
The other half of the conversation runs in the opposite direction: the 855 purchase-order acknowledgment, the seller's line-level answer — accepted, rejected, backordered, with dates. Retail programs increasingly require it, because the buyer's replenishment system needs your acceptance state, not a guess. The practical rule: generate the 855 from the same validation that fulfillment runs on. An acknowledgment that accepts an order the warehouse will later reject is worse than silence, because the buyer schedules on it.
Treat the 850/855 pair as a handshake with a paper trail: every amendment acknowledged, every acknowledgment carrying dates the buyer can schedule against.
Why your 850 gets rejected
The 850's failure modes are validation failures with business causes:
- Unknown ship-to code. The location is not in your master. The order sits in exception while someone decides whether to create it — and the delivery window keeps approaching.
- Unresolvable item ID. No cross-reference for the product ID the buyer sent. New-item introductions and packaging changes are the usual triggers.
- Date window violations. The requested date falls outside the do-not-deliver constraints, or in the past by the time the order is processed.
- Price mismatch. The PO price disagrees with the contract or the seller's price file. Accept it and you have agreed to it; reject it and the order stalls. Either way the disagreement has to surface, not default.
- UOM confusion. Cases on the PO where the item master stocks eaches, or vice versa. The order is accepted and the fulfillment is wrong by a factor.
- Stale data in flight. The PO was amended on the buyer's side while the original sat in your queue. Which version you accept must be definable — by change marker, date or control number — or fulfillment runs against an obligation that no longer exists.
The pattern is the same as every document in this set: the 850 validates against the standard, but it executes against your masters — locations, items, prices. Rejection handling plus master-data hygiene is the operating surface; the map is the small part.
An annotated 850
One line, one ship-to, full terms. Same PO number the 940, 945 and 856 examples on this site carry, because that is how the chain actually joins.
ISA*00* *00* *ZZ*RETAILERISA *ZZ*VENDORISA *260810*0815*U*00401*000000121*0*P*>~
GS*PO*RETAILER*VENDOR*20260810*0815*121*X*004010~
ST*850*0001~
BEG*00*SA*PO-88231**20260810~
REF*IA*VENDOR-0042~
FOB*PP~
ITD*01*3*2**10**30~
DTM*002*20260820~
N1*ST*MAIN STREET STORE*92*00456~
N3*456 MAIN ST~
N4*CINCINNATI*OH*45202~
N1*BT*RETAILER BILLING*92*00001~
PER*BD*BUYER NAME*TE*5135550142~
PO1*00001*100*CA*25.50**UK*00012345678905*VN*ABC-114~
CTT*1~
SE*14*0001~
GE*1*121~
IEA*1*000000121~
- GS code PO — functional group for purchase orders.
- BEG — purpose 00 (original), type SA (stand-alone order), number PO-88231, dated 2026-08-10: the join key for everything downstream.
- REF — vendor number under qualifier IA; many partners use ZZ (mutually defined) for identifiers like this.
- FOB — freight prepaid.
- ITD — basic terms on invoice-date basis: 2% discount if paid within 10 days, net 30.
- DTM — requested delivery 2026-08-20; window qualifiers would follow if the buyer sends them.
- N1 loop — ship-to MAIN STREET STORE and bill-to, both under the buyer's location codes (qualifier 92).
- PER — buyer contact.
- PO1 — line 1: 100 cases at $25.50, identified by GTIN-14 (qualifier UK) and vendor item number (qualifier VN). Two IDs on one line is normal; which one your system treats as primary is a map decision.
- CTT/SE — one line, fourteen segments.
What a bad 850 costs
The 850's failures are cheap individually and expensive structurally. Each exception order costs someone an hour of reconciliation; the structural cost is that the error propagates with the freight. A wrong ship-to becomes a rerouted load. A wrong price becomes a deduction on the remittance, sixty days after nobody remembers the order.
The onboarding number frames the stakes: in the retail program cited throughout this section, hand-built maps took 8–10 weeks per trading partner; prebuilt, per-partner-configured maps took the same work to 12 days (case C05). The 850 map is where that work starts, and where the quality of everything after it is set.
If your purchase orders are generating exceptions, the two-week diagnostic maps your 850 flow end to end — guides, masters, maps — at a fixed $7,500, with findings you keep.
Written by the CrunchCode engineering team — the people who ran these integrations in production.