EDI 850 purchase order: segment map and the fields that must round-trip

Start at the envelope, not the transaction set

Every X12 transmission is wrapped. ISA opens the interchange and carries the sender and receiver identifiers, the control number, and the test or production indicator. GS opens the functional group and carries the functional identifier code, which is PO for an 850. ST opens the transaction set with the identifier 850 and a control number that SE must match. Interchange level rejections almost always resolve to an ISA qualifier or identifier mismatch rather than to anything inside the order, so read the envelope before reading the order.

BEG carries the intent of the order

BEG is the beginning segment for a purchase order. BEG01 is the transaction set purpose code and separates an original from a cancellation or a replacement. BEG02 is the purchase order type code and tells the supplier what kind of commitment this is, which matters because a blanket order and a release against that blanket create different obligations. BEG03 is the purchase order number, which becomes the match key for every downstream document. BEG05 is the purchase order date. Getting BEG02 wrong is a commercial error, not a formatting one.

• BEG01 purpose codes commonly used: 00 original, 01 cancellation, 05 replace, 06 confirmation, 07 duplicate
• BEG02 order type codes commonly used: SA stand-alone order, BK blanket order, RL release or delivery order, DS drop ship, NE new order, RE reorder
• BEG03 purchase order number, the key that the 855, 860, 865, 856 and 810 all quote back
• BEG05 purchase order date

Header segments set terms once for the whole order

The header carries what applies to the whole order: CUR for currency when it is not the default of the relationship, REF for reference identifiers such as a contract or department number, PER for the buyer contact, FOB for shipping and title terms, ITD for payment terms, DTM for order level dates, and an N1 loop for the parties. The N1 loop is where the ship-to, bill-to, and vendor identities are stated, each with its own entity identifier code. When a supplier says it cannot route an order, the answer is usually a ship-to identifier in the N1 loop that is not in their customer master.

• CUR currency, when different from the relationship default
• REF reference identification, for contract, release, or department references
• PER administrative contact for the buyer
• FOB shipping and title terms, and ITD terms of sale and payment
• DTM order level dates, with qualifiers such as 002 delivery requested and 010 requested ship
• N1 loop for ship-to, bill-to, and vendor identities

The PO1 loop is where identity is won or lost

PO1 is the baseline item data segment and repeats once per line. PO101 is the assigned line number, PO102 the quantity ordered, PO103 the unit of measure, and PO104 the unit price. Then come alternating product identifier qualifier and value pairs, which is how the same physical item is stated in the buyer's language and the supplier's at the same time. Sending both a buyer part number and a vendor part number removes most matching failures at the supplier end. PID follows with a free form description, which is for a human and should never be the field either side matches on.

• PO101 assigned identification, the line number quoted back in the acknowledgment
• PO102 quantity ordered and PO103 unit of measure
• PO104 unit price, with PO105 a basis of unit price code where required
• BP buyer part number, VP vendor part number, UP UPC consumer package code, MG manufacturer part number
• PID free form product description, for human reading only

CTT and SE close the order and prove nothing was dropped

CTT is the transaction totals segment. CTT01 is the number of PO1 line items and CTT02 an optional hash total of the quantities. SE closes the transaction set with a count of every segment including ST and SE, and a control number that must equal the one on ST. A CTT line count that disagrees with the lines actually present is the fastest signal that a mapping step truncated the order, and it is worth checking before assuming the supplier lost lines.

Decide now which fields must round-trip into the 855

An acknowledgment is only useful if it can be compared to the order line by line. Before going live, agree with the supplier that the 855 will quote the purchase order number from BEG03, the line number from PO101, and the acknowledged quantity, unit of measure, price, and promised date per line. Without a returned line number the comparison degrades into matching on part number and quantity, which fails as soon as an order carries the same part on two lines with different dates. Store ordered values immutably so the comparison stays possible after the supplier proposes a change.

The suppliers who will never send you an 850 response

An 850 only reaches suppliers with an EDI relationship. In most purchasing organisations that is a minority of the vendor base, and the remainder receive a PDF by email and reply in prose. Pacteva handles that remainder: the same reviewed order goes out as a secure accountless link, the supplier responds per line, and the buyer resolves any proposed difference. The exported result carries the ordered value, the supplier response, the buyer decision, and the current commitment as separate fields, which is the comparison an 855 would otherwise give you. Pacteva does not generate or transmit X12.

Validate the workflow with one real purchase order

Before buying or replacing software, run one representative multi-line PO from reviewed source through supplier response and buyer resolution. Include at least one accepted line, one proposed date or quantity change, and one delivery or reminder edge case. Confirm that every participant can identify the current owner and next action, that the original order remains unchanged, and that the final commitment can be exported and traced to its response and decision. Also verify the supplier experience on a normal phone and desktop browser, revoke and reissue a response link, inspect a failed delivery, and test the role boundary with a non-owner buyer. This evidence is more useful than a feature checklist because it exposes adoption friction, hidden authority, and incomplete system boundaries before the workflow reaches production volume.