EDI 850: Purchase Order (PO)

The EDI 850 is the X12 purchase order. A buyer, usually a retailer, distributor or manufacturer, sends it to a supplier to order goods: which items, how many, at what price, where to ship them and by when. It starts the order-to-cash cycle. The supplier loads it as a sales order, confirms receipt with a 997 and often an 855, ships against it with an 856 and bills it with an 810.

Request a 30-minute call

Reviewed October 2026 against X12 4010 and 5010

The 850 at a glance

Code: X12 850
Name: Purchase Order
Also called: PO
Sent by: Buyer: a retailer, distributor or manufacturer
Sent to: Supplier
When: Whenever the buyer orders. Changes to an open order usually come as an 860, or as a replacement 850 if the partner works that way.
Acknowledged with: 997 Functional Acknowledgment, 855 Purchase Order Acknowledgment
Related documents: 855 Purchase Order Acknowledgment, 856 Ship Notice/Manifest (ASN), 810 Invoice, 820 Payment Order/Remittance Advice
EDIFACT equivalent: ORDERS

Where does the 850 sit in the cycle?

Each document is usually answered by a 997 functional acknowledgment, which only confirms it arrived and parsed.

Which segments does an 850 use?

The standard column is what X12 itself requires. Your trading partner's implementation guide will require more, and it wins.

Segment	Name	Standard	What goes in it
ST	Transaction set header	Mandatory	Starts the purchase order and gives it a control number that the SE repeats.
BEG	Beginning segment for purchase order	Mandatory	Purpose (original, cancel, replace), order type (stand-alone, blanket, release, drop ship), PO number, release number and PO date.
CUR	Currency	Optional	Only when the order is not in the currency both sides assume.
REF	Reference identification	Optional	Department, your vendor number, promotion or contract numbers. Values here often have to come back on the label and the invoice.
PER	Administrative communications contact	Optional	The buyer or order contact.
FOB	F.O.B. related instructions	Optional	Who pays the freight and where title passes. It decides whether you may bill freight on the 810.
SAC	Service, promotion, allowance or charge	Optional	Order-level allowances and charges, such as a freight allowance or a promotional discount.
ITD	Terms of sale	Optional	Payment terms. If they differ from your customer record, the invoice will be paid on these.
DTM	Date/time reference	Optional	Requested delivery date, or a ship window (not before, no later than) and a cancel-after date.
TD5	Carrier details (routing)	Optional	A required carrier or routing instruction when the buyer controls the freight.
N1	Name (party)	Optional	Buyer, ship-to and bill-to, by codes the buyer assigned. For drop ship, the consumer. The loop is optional in the standard and required by nearly every guide.
PO1	Baseline item data	Mandatory	One per line: line number, quantity, unit of measure, unit price, and item IDs in pairs of qualifier and value. The PO1 loop is mandatory.
CTP	Pricing information	Optional	Extra prices for the line, such as the retail price to print on the ticket.
PID	Product/item description	Optional	Free-text description. Read it, never match on it.
PO4	Item physical details	Optional	The pack the buyer expects, such as 12 per carton. Compare it with your item setup.
SDQ	Destination quantity	Optional	Quantities by store or DC when one PO line is split across many locations.
CTT	Transaction totals	Optional	Number of PO1 lines, sometimes with a hash total. The loop is optional in the standard; most guides require it.
SE	Transaction set trailer	Mandatory	Segment count from ST to SE, and the same control number as the ST.

4010 or 5010?

The 850 changes little between 4010 and 5010. 5010 turns the heading lead-time segment into a small loop, uses MTX instead of MSG for free text in several loops, lets the N9 loop carry paperwork and file-format references, and renames segments such as N1 (Party Identification) and REF (Reference Information). Partner guides differ far more than the releases do: one retailer never sends SDQ, another sends every store order through it.

What does an 850 look like?

Sample with made-up data. X12 4010. Every company, number and address is invented.

ISA*00* *00* *ZZ*BASINHW *ZZ*NORTHFORK *261008*0912*U*00401*000001001*0*P*>~
Interchange envelope. Fixed width: every field is padded to its exact length, so the whole line is always 106 characters. ZZ means the sender and receiver IDs are mutually agreed rather than a DUNS number. 00401 is the envelope version; the version of the documents inside is in the GS. P means production; T would mean test.
GS*PO*BASINHW*NORTHFORK*20261008*0912*1001*X*004010~
Functional group. PO says the group holds purchase orders, X and 004010 say they follow X12 release 4010, and the 1001 here must match the GE at the bottom.
ST*850*0001~
Start of one purchase order. 0001 is the control number the SE must repeat.
BEG*00*SA*BH2026-04417**20261008~
00 is an original order (not a cancel or replace). SA is a stand-alone order, as opposed to a release against a blanket. BH2026-04417 is the PO number you will echo on the 855, 856 and 810.
REF*DP*042~
Buyer department 042. Easy to drop on the floor, and many partners want it back on the carton label and the invoice.
PER*BD*Purchasing*EM*po@basinhardware.example~
Buyer contact. BD is the buyer, EM says the next value is an email address.
DTM*002*20261020~
Requested delivery date, October 20. Some partners send a ship window instead (a not-before and a no-later-than date).
N1*ST*Basin Hardware DC 2*92*0002~
Ship-to. The name is for people; the code after 92 (0002) is what the buyer actually checks. Store it on the sales order.
N3*400 Freight Way~
Ship-to street address.
N4*Ogden*UT*84401~
Ship-to city, state and ZIP.
PO1*1*24*EA*18.4**BP*BH-77812*VN*NT-FH20*UP*614141000012~
Line 1: 24 each at $18.40. The buyer part number, your item number and the UPC all ride on the same line. Any one of them may be the one your ERP knows.
PID*F****Framing hammer, 20 oz~
Free-form description. Useful to a person; never use it to match the item.
PO1*2*12*EA*11.25**BP*BH-77840*VN*NT-PB24*UP*614141000029~
Line 2: 12 each at $11.25.
PID*F****Pry bar, 24 in~
Description for line 2.
CTT*2~
Two PO1 lines in this order. Check it before you load the order.
SE*14*0001~
End of the order: 14 segments counting ST and SE, and the same control number as the ST.
GE*1*1001~
One transaction set in this group, group number 1001.
IEA*1*000001001~
One group in this interchange, and the same control number as the ISA.

Why do 850s fail to become clean sales orders?

The 850 rarely bounces at the translator. It fails one step later, when it tries to become a sales order, and those failures are quiet: an order waits in an error queue, or it loads with the wrong price and nobody notices until the invoice is rejected.

Problem	What happens	Fix
The ship-to code is not in your ERP	The order finds no ship-to, or lands on a default address	Keep a cross-reference of the partner’s location codes and refresh it from their store list (some partners send an 816)
An item ID you do not recognize	The line fails, or matches the wrong item	Keep a customer item cross-reference for each ID type the partner sends: UPC, buyer part number, your part number
Units of measure disagree	The buyer orders 24 each, you sell cases of 12, and the order loads as 24 cases	Store the unit conversion per customer item, and check the PO4 pack against it
The price is not your price	The order loads at one price and the 810 later fails the buyer’s price match	Flag price differences before you acknowledge, and settle them on the 855, not on the invoice
A change arrives as a new 850	Duplicate orders	Check the BEG purpose code and the PO number before creating another order, and agree with the partner how changes arrive
A ship window your ERP cannot hold	The ERP keeps one date; the partner sends a not-before date and a cancel-after date	Store both dates and plan picking from the window. Shipments after the cancel date can be refused
Store quantities in SDQ	The ERP sees one line for 240 units and the warehouse ships it as one lot	Split SDQ into per-location lines or orders before release
No 855 sent on time	The partner treats the order as accepted as sent, and some programs charge for missing acknowledgments	Send the 855 automatically when the order loads, and route exceptions to a person

Where does the 850 land in your ERP?

For an inbound document the question turns around. It is not where the data comes from, but where it has to go so the rest of the cycle works. Every value dropped here is one you cannot send back on the 856 or the 810.

Segment	Lands in	Why it matters later
BEG PO number	Customer PO field on the sales order header	Echoed on the 855, the 856 (PRF) and the 810 (BIG). One typo breaks all three
BEG PO date	Order date, or a field of its own	Many guides want it back on the ASN and the invoice
REF department, vendor number	Fields on the order header	Often required on carton labels and invoices, and most ERPs have no slot for a department
DTM	Requested date, plus the cancel date	Late shipments are measured against these dates, not yours
N1 ship-to code	Ship-to cross-reference	Must be echoed exactly on the 856 and the 810
PO1 line number	A reference on each sales order line	Many partners want the original line number back. ERPs that renumber lines lose it
PO1 item IDs	Customer item cross-reference	The 856 and 810 should name items the way the 850 did
PO1 price	Line price, compared with yours	The 810 has to match it, or match the price agreed on the 855

How do you get 850s working?

Route	Fits when	Watch out for
Managed EDI provider or VAN with a web portal	One or two partners, low volume, nobody in house to own maps	Orders are retyped into the ERP. That is workable at a few orders a week, and it is where ship-to and item mistakes start
Managed EDI or an iPaaS connector wired to your ERP	Your ERP has a supported connector and your partners are large retailers with ready-made maps	Check that the connector handles your partner’s location codes, unit conversions and SDQ, not only the happy path
An in-house translator	Many partners, high volume, or an ERP that no connector supports	You own the maps, the AS2 certificates, the monitoring, and whoever gets called when a 850 fails at night

The 850 is usually the first document a partner turns on and the easiest to get passing. Map it with the 856 and 810 in mind, because the fields you drop now are the ones those documents fail on later. Getting all three right in one pass is the ERP and EDI integration work we do.

Questions about the 850

What is the difference between an 850 and an 855?

The 850 is the buyer's order. The 855 is the supplier's answer to it, line by line: accepted, accepted with changes to quantity, price or date, or rejected.

How does a buyer change an order after sending the 850?

Usually with an 860 Purchase Order Change Request. Some partners resend a full 850 marked as a replacement in the BEG segment instead. The implementation guide says which, and your system has to handle the one your partner uses.

Do I have to answer every 850?

Send a 997 for every one if the partner asks for acknowledgments, and most do. An 855 is needed only when the partner's program requires it, though many large buyers do.

Can one 850 cover many stores?

Yes. A buyer either sends one 850 per store or DC, or one 850 with SDQ segments that split each line by location. The second form has to be broken into per-location orders or pick lists before the warehouse can use it.

What is a drop ship 850?

An order where the buyer has sold to a consumer and asks you to ship to that consumer directly. The 850 carries the consumer's address as a party, and the buyer usually specifies the packing slip you must include.

New trading partner asking for the 850?

Send us their implementation guide. We will tell you what your ERP already holds, what is missing, and the shortest path to a test file that passes.

Request a 30-minute call See engagement models