EDI 850 purchase order: segments and exceptions

An EDI 850 is a purchase order sent as structured data. It is transaction set 850 in the X12 standard, and a supplier’s system can read it without rekeying: the PO number, the ship-to, and each line’s item, quantity, unit and price. How it is used varies by trading partner, so follow that partner’s implementation guide.

What is an EDI 850 purchase order?

EDI, electronic data interchange, lets two companies’ systems exchange business documents in an agreed format. X12 describes itself as a non-profit, ANSI-accredited, cross-industry standards development organization that develops and maintains EDI standards. It defines transaction sets, each with the data content for a specific business purpose.

The 850 is the set for placing purchase orders. X12’s own description of the 850 says it provides for customary and established business practice for placing purchase orders for goods and services. It also says the set should not be used to convey purchase order changes or acknowledgments. Other sets do that, covered below.

The number is a label, not an acronym. X12 publishes in versions, and the X12 examples linked here use version 004010. Partners may use others, so ask which version and which fields a partner expects.

What is inside an 850?

An 850 is a series of segments, each a short line of data. In plain language:

Segment	Name	What it tells you
ISA, GS (closed by GE, IEA)	Envelopes	Sender, receiver, dates and control numbers. The ISA segment also declares the separator characters.
ST, SE	Transaction set header and trailer	ST names the set (850) and gives a control number. SE counts the segments in the set.
BEG	Beginning segment	Purpose (original or replacement), order type, PO number, PO date.
CUR, REF, PER	Currency, references, contact	Currency, extra reference numbers, a person or office for administrative questions.
DTM	Date and time	Dates such as requested delivery or requested ship.
N1 (with N3, N4)	Name and address	Buyer, ship-to, bill-to and their addresses.
PO1	Baseline item data	One line: line number, quantity, unit of measure, unit price, item identifiers.
PID	Product description	Item description, coded or free-form.
CTT	Transaction totals	Number of line items, and optionally a hash total.
AMT	Monetary amount	A total amount for the order.

What does a sample 850 look like?

Everything below is fictional: the company, the numbers and the dates. The ISA and GS envelope segments are left out. Real partners differ.

ST*850*0001~
BEG*00*SA*48213**20261001~
DTM*002*20261012~
N1*BY*Cedar Ridge Hardware*92*0042~
N1*ST*Cedar Ridge Hardware Store 2*92*0042-02~
PO1*1*24*EA*38.50*PE*VP*DM-1020*BP*CR-5531~
PO1*2*12*EA*7.25*PE*VP*FL-3300~
CTT*2~
SE*9*0001~

Reading it line by line:

ST*850*0001 starts transaction set 850 with control number 0001.
BEG*00*SA*48213**20261001: 00 means original, SA means stand-alone order, 48213 is the PO number, the empty element is the release number, and the date is October 1, 2026.
DTM*002*20261012: delivery requested on October 12, 2026.
N1*BY and N1*ST: the buyer and the ship-to. The 92 means the code that follows was assigned by the buyer.
PO1*1*24*EA*38.50*PE*VP*DM-1020*BP*CR-5531: line 1, quantity 24, unit each, price 38.50, priced per each, vendor part number DM-1020, buyer’s part number CR-5531.
CTT*2: two line items.
SE*9*0001: nine segments in the set, control number 0001.

The asterisk and tilde are the separators in this sample, and the sender declares which characters it uses. The codes shown (00, SA, 002, 92, EA, PE, VP, BP) come from X12 code lists, but which codes a partner uses is set in its guide. Some use NE for a new order instead of SA. X12’s own basic purchase order example has a similar shape, with an address and an order total added.

Which transactions go with the 850?

X12’s supply chain flow shows the 850 opening the ordering stage, after catalog and item data are exchanged. The related sets:

Set	Name	Role
997 (or 999)	Functional Acknowledgment (Implementation Acknowledgment)	Reports whether the message was received and passed syntax checks, accepted or rejected. It is not acceptance of the order.
855	Purchase Order Acknowledgment	The seller’s response to the order. X12’s example has a supplier answering line by line, with changes to date, price, quantity or product.
860	Purchase Order Change Request, Buyer Initiated	The buyer asks to change an order already sent.
856	Ship Notice/Manifest	The seller says what is shipping and how it is packed. Often called an advance ship notice.
810	Invoice	The seller bills for the goods.
820	Payment Order/Remittance Advice	The buyer sends payment details.

Which of these a partner requires, and how quickly, is in its implementation guide. Some partners need only a few.

What goes wrong with EDI 850 orders in practice?

Valid EDI can still be wrong for your business. A 997 says only whether the message passed syntax checks. These are the usual exceptions:

Unknown customer or ship-to. The buyer’s code in the N1 segment is not in your customer file.
Unknown item. The part number in the PO1 segment, whether vendor, buyer or UPC, has no match in your item list or cross-reference.
Price mismatch. The unit price differs from your price list or contract.
Unit-of-measure mismatch. The PO says 12 each, and you sell by the case of 12. Or the price is per each where you quote per case. Pack-size confusion can turn into a twelve-times error.
Duplicate PO. The same PO number arrives twice. It may be a resend or a replacement. A purpose code of 05 in the BEG segment means replace, so check before you create a second order.
Quantity outlier or missing field. A quantity far outside the customer’s pattern, or a required date or code left blank.

Send each exception to a queue with the reason attached, let a person decide, and fix the cross-reference so the same case passes next time.

What should you ask about EDI order processing software?

If you look at EDI order processing software, ask these, and get the answers in writing:

Which transaction sets and versions it handles today, and how it onboards a new trading partner.
How it sends and receives: through a value-added network (VAN), AS2 or SFTP, depending on the partner.
Where item and customer cross-references live, and who edits them.
What happens to an order that fails a check: is there an exception queue, and can you reprocess it?
Whether it sends the 855, 856 and 810 for you, or only receives the 850.
Which ERP and version it connects to today, and how orders reach the ERP.
How it is priced: per partner, per document, or flat.

EDI vs email orders: how do they compare?

	EDI 850	Email or PDF
Format	Structured, agreed with each partner	Free-form, differs by customer
Setup	Both sides agree on a spec, test it and choose how to send it	None. The customer just sends it.
Typical errors	Mapping: unknown codes, units and prices	Reading: wrong customer, item or quantity
Who asks for it	Often larger customers with their own requirements	Smaller customers, or anyone
Responses	997, 855, 856 and 810 in set formats	Replies by email

How does a small distributor handle customers who still send email or PDF orders?

Most distributors end up with both. Do not force EDI on small customers. It takes setup on both sides, and a small buyer may have no reason to do it.

One intake and one exception queue. EDI and email orders end at the same checks: customer, item, unit, price, stock. See purchase order automation for how to scope that.
Ask email customers for the fields EDI would carry. Account number, ship-to, PO number, your item number or a consistent part number, unit and requested date. A simple order form helps.
Decide EDI customer by customer. If a customer requires it, get its implementation guide and test plan before you agree. Some partners set rules about how fast to send acknowledgments or ship notices.
Let software read email and PDF orders when the volume justifies it, with review before anything is entered. NIST’s Generative AI Profile warns about confidently stated but wrong output, which is why review matters.
Track the exception rate by channel. It shows where the work is. The order to cash guide covers the other measures.

Frequently asked questions

What does 850 mean in EDI?

It is the X12 number for the Purchase Order transaction set. Other numbers cover other documents, such as 855 for the acknowledgment, 856 for the ship notice and 810 for the invoice.

Is an EDI 850 the same as a PDF purchase order?

No. It is the same kind of business document in a different form. The 850 is structured data a system reads directly. A PDF is a page that has to be read, by a person or by software.

What is the difference between an 850 and an 855?

The 850 is the buyer’s order. The 855 is the seller’s acknowledgment of it, including any changes the seller proposes.

Do I need EDI to sell to a larger customer?

Some customers require it and many do not. Check the customer’s vendor or supplier requirements, and ask for its implementation guide before you commit.

Where Dockmend fits

Dockmend is being built to start with emailed purchase orders, the orders an EDI feed does not cover. It is meant to match the customer and products, check inventory, prepare the order in your ERP, coordinate shipping and flag exceptions to your staff. Your people approve it and handle unknown items, price disagreements and judgment calls. Dockmend is still being built, and we have not announced support for any EDI network or ERP. Join the pilot

This guide is general information, not legal or compliance advice. EDI details vary by trading partner, version and implementation guide, so check your partner’s before you build or change anything.