EDI 860 Purchase Order Change Request

What is an EDI 860?

The EDI 860 is the X12 Purchase Order Change Request - Buyer Initiated. A buyer sends it to change a purchase order it already sent as an 850: add a line, delete a line, change a quantity, a price or a date, or cancel the order. X12 gives it a second use: the buyer can send it to confirm a change the seller initiated. The EDIFACT message for the same purpose is ORDCHG, purchase order change request.

The 860 refers back to the original order by PO number and line number, and it carries only what changes. That makes it smaller than the 850 and harder to process: the change only makes sense against the order it changes, and that order has to be found, still be open and not yet shipped.

850 vs 860, and where the 860 sits

The 850 must not carry changes: the X12 purpose statement of the 850 says it "should not be used to convey purchase order changes". A buyer that resends the full order as a new 850 with the same PO number breaks that rule, and an integration that does not check the PO number creates a duplicate. The 860 exists so the change arrives as a change. Its functional identifier is PC; the 865's is CA.

The segments of an 860

The X12 004010 860 lists 189 segment positions, most of them copies of 850 segments for the parts that can change. Retail guides use a handful.

BCH01 and POC02 codes

X12 004010 defines 29 change codes for POC02. RZ is the one with a rule in the standard: the receiver replaces the values in the original order line with the values in the 860. With QD or QI the change is relative, and the guides do not agree on which element holds what, as the retailer table below shows.

A sample 860, with delimiters

PO 4500018236 from the 850 sample ordered 24 units on line 1 and 16 on line 2. The supplier's 855 confirmed 24 and 12. On 30 September the buyer accepts the lower quantity with an 860.

ST*860*0001~
BCH*04*SA*4500018236**001*20260928*****20260930~
POC*2*QD*12*12*EA*8.75**UP*614141104994*VP*10499~
CTT*1*12~
SE*5*0001~

BCH01 is 04, change. BCH03 repeats the PO number and BCH06 the original PO date of 28 September; BCH05 is 001, the first change, and BCH11, after four empty elements, the date of the change request. POC01 is 2, the line number from PO101 of the 850. POC02 is QD, quantity decrease. In this sample POC03 is the new ordered quantity, 12, and POC04 the quantity still to receive, also 12, since nothing has shipped. The order was 24 plus 16, which is 40 units and 300.00 plus 140.00 is 440.00. After the change it is 24 plus 12, which is 36 units and 300.00 plus 105.00 is 405.00, the merchandise total the 810 invoice bills later. There is 1 POC segment, so CTT01 is 1, and CTT02, the hash total of POC03, is 12. There are 5 segments from ST to SE, so SE01 is 5.

The envelope around it

ISA*00*          *00*          *01*123456789      *ZZ*NORTHFIELD     *260930*0835*U*00401*000001219*0*P*>~
GS*PC*123456789*NORTHFIELD*20260930*0835*1219*X*004010~
ST*860*0001~
SE*5*0001~
GE*1*1219~
IEA*1*000001219~

The 860 comes from the buyer, so the sender ID in ISA06 and GS02 is the same as on the 850, and the control numbers continue the buyer's sequence: 1203 on the 850, 1219 here. GS01 is PC. ISA13 has to equal IEA02, GS06 GE02, ST02 SE02, and SE01 has to be the real count of 5. ISA15 is P for production and T for test. A translator that routes inbound files by GS01 sends PC groups to the change map; a group sent with the wrong code goes to the wrong map. Best Buy's own 860 sample carries GS01 PO, the 850's code, which a strict translator would reject or misroute.

Who sends the 860, and how they differ

Three published guides, checked on 3 October 2026, use the same transaction set three ways.

The same intent, line 2 down from 16 to 12, is POC*2*QD*12*12*EA in the sample above, POC*2*QD*16*4*EA under the Exchange's rule, a POC*2*RZ*12... with the full line for Best Buy, and not possible at Walmart, whose 860 only cancels whole lines. A mapping that reads POC03 as the new quantity at the Exchange would set the line to 16 and ship 4 too many. Walmart's guide is public on its developer portal; the program is described under EDI with Walmart.

What goes wrong with changes

• The change arrives after the pick. An 860 that lowers a line after the warehouse picked it needs the pick reversed, or an 865 that rejects the change. Applied to the sales order alone, it leaves the 856 shipping more than the order says.
• An 860 booked as an 850. The PO number already exists, so the order is created twice. The rule is simple and has to be in the integration: an 860 never creates an order.
• Relative and absolute quantities mixed up. QD with 4 read as "set to 4" turns 16 into 4 instead of 12, as the Exchange's convention shows.
• Cancel codes. BCH01 01 cancels the whole order; POC02 DI cancels one line. Applying a line cancel to the order, or the reverse, cancels the wrong amount.
• Change sequence. Two 860s for the same PO processed in the wrong order leave the older change in place. BCH05 and BCH11 set the order.

Handling the 860 on the ERP side

The 860 changes the sales order that the 850 created. The order is found by the customer's PO number, the line by the buyer's line number, which has to be stored on each sales order line when the 850 is booked.

Every applied change also needs to reach the documents that follow: the pick list, the 856 and the 810. A change that cannot be applied, because the goods already left, is held and reported, and where the partner uses the 865 it is rejected there.

We build the 860 as part of an EDI integration: changes matched to the order and line, applied according to each partner's convention for quantities and codes, checked against pick status and stock, and held in the dashboard when they arrive too late. The order flow stays the same for orders from your webshop and from EDI. Tell us which partners change orders by 860.