The ASC X12 transaction set for a purchase order. A buyer sends it to a supplier to order goods or services; the supplier typically answers with an 855 acknowledgment, later an 856 ship notice and finally an 810 invoice.

Which segments does an 850 have to contain?

The ISA, GS and ST envelopes, a BEG header (purpose, order type, PO number, date), at least one PO1 line item, and the SE, GE and IEA trailers. N1 party loops and the CTT totals segment are optional in the standard, but almost every trading partner's implementation guide requires them.

How do I open an 850 file?

An 850 is plain text, so any text editor shows the raw segments. An EDI viewer such as EDI Studio parses the envelopes, loops and elements into a tree and names each element, so the file reads as an order instead of a wall of asterisks.

How to Read an X12 850 Purchase Order (With a Real Example)

The X12 850 is the purchase order, and it's usually the first transaction set anyone learns. It's also the one people bluff about understanding. This walks through a real 850 segment by segment.

A complete (small) 850

ISA*00*          *00*          *ZZ*ACMEBUYER      *ZZ*SUPPLIER01     *260715*1432*U*00401*000000001*0*P*>~
GS*PO*ACMEBUYER*SUPPLIER01*20260715*1432*1*X*004010~
ST*850*0001~
BEG*00*SA*4500123456**20260715~
REF*DP*042~
PER*BD*JAN MERCER*TE*8475550142~
FOB*PP*OR*ORIGIN~
DTM*002*20260801~
N1*ST*ACME DISTRIBUTION CENTER*92*DC-04~
N3*1400 INDUSTRIAL PKWY~
N4*WAUKEGAN*IL*60085*US~
PO1*1*48*CA*18.5000**UP*012345678905~
PID*F****STAINLESS CLEANER 32OZ~
PO1*2*12*CA*24.7500**UP*012345678912~
PID*F****GLASS CLEANER 32OZ~
CTT*2~
SE*16*0001~
GE*1*1~
IEA*1*000000001~

The envelope: ISA, GS, ST

The outer three segments are bookkeeping. They carry no purchase order information at all.

ISA is the interchange header and it is the only fixed-width segment in X12 — every element is padded to an exact length, which is why you see those runs of spaces. It matters more than it looks: position 106 of the ISA defines the segment terminator, and ISA16 defines the component separator. A parser that assumes ~ and > rather than reading them from the ISA will eventually meet a partner who uses something else.

ISA13 here is 000000001, the interchange control number. It must match IEA02 at the bottom. GS opens a functional group — GS01*PO says this group contains purchase orders — and its control number GS06 must match GE02.

ST*850*0001 opens the transaction set itself. 0001 must match SE02.

BEG: the segment that actually says "purchase order"

BEG*00*SA*4500123456**20260715~

BEG01 = 00 — transaction set purpose. 00 is Original. 01 is Cancellation, 05 is Replace.
BEG02 = SA — purchase order type. SA is a stand-alone order; BK is a blanket order.
BEG03 = 4500123456 — the PO number. This is the element everyone actually wants.
BEG04 — empty here (release number).
BEG05 = 20260715 — the PO date, always CCYYMMDD in 004010 and later.

Note the doubled asterisk in 4500123456**20260715. That's an empty BEG04, not a typo. Counting positions by eye is exactly where manual reading goes wrong.

N1 loops: who and where

The N1 loop identifies a party. The qualifier in N101 is what gives it meaning:

Qualifier	Meaning
`ST`	Ship To
`BT`	Bill To
`SF`	Ship From
`BY`	Buying Party
`VN`	Vendor

A very common onboarding failure is a partner sending N1*ST where your map expects N1*SF. Both are structurally valid. Only the semantics are wrong, so a schema validator will pass it happily and the shipment will go to the wrong place.

N101*92 in our example is an "assigned by buyer" identification code — DC-04 is Acme's own warehouse code, not a DUNS number.

PO1: the line items

PO1*1*48*CA*18.5000**UP*012345678905~

PO101 = 1 — line number.
PO102 = 48 — quantity ordered.
PO103 = CA — unit of measure. CA is case, EA each, LB pound.
PO104 = 18.5000 — unit price. Decimal places vary by partner and are a frequent source of penny-level invoice disputes.
PO106/PO107 = UP / 012345678905 — product ID qualifier and value. UP is UPC; VP is vendor part number, BP buyer part number.

Product identifiers repeat in pairs, so a single PO1 can carry a UPC, a vendor part, and a buyer part all at once.

CTT and SE: the arithmetic

CTT*2 declares two line items. If the file contains three PO1 segments, a conforming partner rejects it.

SE*16*0001 declares sixteen segments, counting ST and SE themselves. Count the segments from ST down: that's the number that has to be there. This is the single most common thing hand-editing breaks — add a REF segment, forget to bump SE01, and the interchange bounces.

Reading this faster

Everything above is mechanical, which is why it's worth not doing by hand. A structured view renders the loop nesting directly and shows element names on hover, so BEG03 reads as "Purchase Order Number" instead of "the third thing after BEG, assuming I counted the empty one".

Next: what the 997 says when your 850 is rejected.