EDI documents
EDI 850 Purchase Order
The EDI 850 is the purchase order a buyer sends to a supplier in X12 format: what to ship, how many, at what price, to which location and by when. This page covers the 850 specification at segment level, a sample with its totals, the envelope, and what the order becomes in your ERP.
Updated
What is an EDI 850?
The EDI 850 is the X12 Purchase Order transaction set. A buyer sends it to a supplier to place an order, and it carries the PO number, the order date, the parties and locations, the requested dates, and one line per item with quantity, unit and price. The EDIFACT counterpart is the ORDERS message.
X12 limits its purpose: the 850 is for the placement of purchase orders and "should not be used to convey purchase order changes or purchase order acknowledgment information". Changes come as an 860, the answer goes back as an 855. In grocery, the same role is filled by the 875 Grocery Products Purchase Order. Among the EDI documents a supplier handles, the 850 is the inbound one that starts the cycle, and every later document refers back to its PO number and line numbers.
Where the 850 sits in the order-to-cash flow
The 850 starts the cycle. Four documents answer it or build on it.
| Document | Direction | Relation to the 850 |
|---|---|---|
| 997 functional acknowledgment | Supplier to buyer | Confirms the file was received and parsed |
| 855 acknowledgment | Supplier to buyer | Accepts, changes or rejects the lines |
| 856 ship notice | Supplier to buyer | Reports what shipped, citing the PO number in PRF01 |
| 810 invoice | Supplier to buyer | Bills it, citing the PO number in BIG04 |
The EDI 850 specification: segments
The X12 004010 definition has three areas. The heading holds BEG and the order-level data, the detail area is the PO1 loop, which can repeat 100,000 times, and the summary holds CTT and AMT.
| Segment | Name | What it carries | What goes wrong |
|---|---|---|---|
| BEG | Beginning Segment for Purchase Order | BEG01 purpose (00 original), BEG02 type (SA stand-alone, DS dropship, NE new order), BEG03 PO number (1 to 22 characters), BEG05 order date | A resent file with the same BEG03 creates a second sales order |
| REF | Reference Identification | Department, vendor number, contract | A vendor number the ERP has under another customer |
| DTM | Date/Time Reference | 010 requested ship, 002 delivery requested | The two dates swapped: the order ships on the delivery date |
| N1, N3, N4 | Name, Address Information, Geographic Location | BY buying party, ST ship to, BT bill to, with the buyer's location code in N104 | A new store or DC code that has no address in the ERP |
| PO1 | Baseline Item Data | PO101 line number, PO102 quantity, PO103 unit, PO104 unit price, then up to ten ID pairs | Item not found; cases read as eaches; price differs from the agreed price |
| PID | Product/Item Description | Free-form description, 80 characters | None; it is informational |
| PO4 | Item Physical Details | Pack and inner pack size | An inner pack that differs from the item master |
| SAC | Service, Promotion, Allowance, or Charge | Allowances and charges per line or per order | An allowance that is dropped and then missing on the invoice |
| SDQ | Destination Quantity | One line split across store numbers | The line total is booked and the store split is lost |
| CTT | Transaction Totals | CTT01 number of PO1 lines, CTT02 hash total of the quantities | A count mismatch rejects the set |
| AMT | Monetary Amount | TT, the total transaction amount | Order total differs from the sum of the lines |
PO1 is the segment that takes the mapping work. It has 25 elements: five for line number, quantity, unit, price and price basis, and then PO106 to PO125, ten pairs of a qualifier and a product ID. One line can name the same item as UP (UPC), UK (GTIN-14), VP (vendor's part number), BP (buyer's part number) and PI (purchaser's item code) at once, in any order, and each partner picks its own combination. The integration reads the qualifiers, not the positions.
A sample 850, with delimiters
One order for two items, to be shipped to one distribution center. Elements are separated by *, segments end with ~.
ST*850*0001~
BEG*00*SA*4500018236**20260928~
REF*DP*042~
DTM*010*20261002~
DTM*002*20261006~
N1*BY*HARBOR RETAIL*92*0001~
N1*ST*HARBOR RETAIL DC 07*92*0007~
N3*1200 DOCK STREET~
N4*COLUMBUS*OH*43215*US~
PO1*1*24*EA*12.50**UP*614141104826*VP*10482~
PID*F****WALL ANCHOR KIT 50 PC~
PO1*2*16*EA*8.75**UP*614141104994*VP*10499~
PID*F****CABLE CLIP 8MM 100 PC~
CTT*2*40~
AMT*TT*440~
SE*16*0001~
The totals can be checked by hand. There are 2 PO1 segments, so CTT01 is 2. The hash total in CTT02 is the sum of the PO102 quantities, 24 plus 16 is 40. Line 1 is 24 times 12.50, which is 300.00, line 2 is 16 times 8.75, which is 140.00, and AMT carries the sum, 440. From ST to SE there are 16 segments, so SE01 is 16. The empty element between 12.50 and UP is PO105, the price basis, left out here. The two asterisks after the PO number skip BEG04, the release number.
The envelope around it
The 850 is inbound, so the buyer is the sender in ISA06 and GS02. The functional identifier in GS01 for purchase orders is PO.
ISA*00* *00* *01*123456789 *ZZ*NORTHFIELD *260928*1410*U*00401*000001203*0*P*>~
GS*PO*123456789*NORTHFIELD*20260928*1410*1203*X*004010~
ST*850*0001~
SE*16*0001~
GE*1*1203~
IEA*1*000001203~
Three pairs have to match: ISA13 and IEA02 (000001203), GS06 and GE02 (1203), ST02 and SE02 (0001). GE01 counts the transaction sets in the group, and one group can hold many 850s, each with its own ST and SE. GS08 gives the version the content follows, here 004010. ISA15 is P for production and T for test, and a T file must never create a live sales order.
The qualifier in ISA05 and ISA07 says what kind of ID follows: 01 is a DUNS number, 08 is the qualifier Kroger specifies, ZZ is mutually defined. Delimiters are agreed per partner; Walmart fixes them at ~, * and > for its drop-ship vendors.
Who sends the 850, and how they differ
Each buyer publishes its own subset of the standard as an implementation guide. Three public ones, checked on 3 October 2026:
| Buyer and version | BEG02 | Item IDs in PO1 | Also in the guide |
|---|---|---|---|
| Kroger, 005010 | NE | UA case code or UK GTIN-14, PI purchaser's item code, PL order line number, quantity in cases | DTM 704 delivery appointment, N9 references, MTX text, CTT with weight and volume |
| D&H, 004010 | SA or DS | VP, BP and UP on one line | ITD terms, REF at line level, AMT total |
| Walmart drop ship, 004010 in its sample | DS in its sample | Not on the public page | File named WMI_850PO_... over SFTP; changes follow as an 860 |
The differences are small on paper and decide whether an order imports. Kroger's 850 orders in cases and identifies the item by a 14-digit GTIN and the purchaser's item code, where D&H sends the vendor's part number, so the item lookup and the unit conversion need a different rule per partner. A UPC padded to 14 digits is not the same string as the 12-digit UPC in the item master. The guides are public: Kroger's 850 map and Walmart's EDI interface page. Partner specifics are under EDI with Walmart and EDI with Kroger.
What goes wrong and what it costs
An 850 that passes the syntax check can still fail as an order. The failures that reach the warehouse:
- Duplicate order. The buyer resends an interchange, or sends BEG01 06 (confirmation) for an order that was already placed another way. Without a check on buyer ID plus BEG03, the ERP holds two sales orders for one PO.
- Unit of measure. PO103 says CA and the ERP sells in eaches. 24 cases of 12 booked as 24 units ships 264 units short.
- Item not found. One unknown ID on one line. Rejecting the whole order delays the other lines; importing without the line makes the 855 and the invoice disagree with the PO.
- Price mismatch. PO104 is 12.50 and the price list says 12.80. The invoice is later short-paid by 24 times 0.30, which is 7.20, and the difference arrives as a deduction.
- Late acknowledgment. Partners set a deadline for the 855. Chewy's guide requires it within 24 hours of receipt of the order.
The cost shows up downstream. A wrong quantity or item on the order becomes a wrong 856 and a wrong 810, and those are the documents retailers attach penalties to. The schedules are under EDI compliance.
Handling the 850 on the ERP side
An 850 becomes one sales order. The mapping per field:
| 850 element | ERP field | Rule |
|---|---|---|
| Sender ID and N1*BY | Customer | Looked up from a partner table, never created from the file |
| BEG03 | Customer PO number | Unique per customer; a repeat is held, not imported |
| N1*ST, N104 | Ship-to address | Location code translated to an address record |
| PO101 | Line reference | Stored, because the 855, 856 and 810 have to return it |
| PO106 to PO125 | Item | Qualifier decides the lookup key; unit converted with the pack size |
| PO104 | Price | Compared with the price list; a difference is flagged before the 855 goes out |
NetSuite, Business Central and the store platforms have no X12 translator of their own, so this step sits outside them. We build it as an EDI integration to your systems: the 850 is validated against the partner's guide, the 997 is returned, the order is created through the ERP's API and an order that fails a lookup waits in a queue with the reason shown in the dashboard. A resend of the same PO is recognized and never becomes a second order. How orders flow further is described under order integration. Tell us which partners send you orders.
Frequently asked questions
What is the difference between an EDI 850 and an 855?
The 850 is the order from the buyer. The 855 is the supplier's answer to it: accepted as sent, accepted with changes to quantity, price or date, or rejected. The 850 opens the order and the 855 is the first business response, separate from the 997 that only confirms the file was received.
What is the difference between an EDI 850 and an 860?
The 850 places a new order. The 860, which X12 names Purchase Order Change Request - Buyer Initiated, amends an order that already exists: a quantity, a date, a cancelled line. The X12 purpose statement of the 850 says it is not to be used for purchase order changes, so a changed order arrives as an 860 that refers to the original PO number.
Which segments are mandatory in an 850?
In the X12 standard: ST, BEG, at least one PO1 line and SE. Every trading partner adds its own required segments on top in its implementation guide, usually the N1 loop for the ship-to, DTM for the ship and delivery dates, and CTT for the line count.
What is the EDIFACT equivalent of the 850?
The ORDERS message. The pairing is industry convention, since neither standards body publishes an official crosswalk, but it is consistent across sources. European retail partners send ORDERS, often in the EANCOM subset, where a North American partner sends an 850.
Can an EDI 850 land as an order in Shopify or another store platform?
Yes, through a translation step. The store platform has no X12 parser, so the 850 is translated and mapped outside it and the result is created as an order through the platform's API, with the PO number, the ship-to and the buyer's item numbers resolved to your own. See Shopify EDI integration.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase