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.
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 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*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.
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*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*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.
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".