X12 transaction guide · Ordering
EDI 860 Purchase Order Change Request
Official X12 name: Purchase Order Change Request - Buyer Initiated
The X12 document a buyer sends to change or cancel a purchase order that was already sent to the supplier.
- Sent by
- Buyer
- Received by
- Supplier or vendor
- Standard
- ANSI ASC X12
- EDIFACT equivalent
- ORDCHG
What is an EDI 860?
The EDI 860 Purchase Order Change Request (Buyer Initiated) is the ANSI X12 transaction set a buyer uses to modify a purchase order it has already sent. Changes can include adding or deleting lines, changing quantities or prices, updating dates or ship-to locations, or cancelling the entire order.
Because the 860 changes an existing order, the receiving system must find the original sales order and apply the change correctly. Suppliers often respond with an 865 purchase order change acknowledgment, or with an updated 855, depending on the partner's rules.
How to read this diagram: the top row shows who sends the 860, to whom, and which documents usually come before and after it. The lower part shows what X12 release 004010 itself requires: the envelopes around the 860 and the segments and loops the standard marks as required, area by area. Optional loops are listed by the segment that starts them rather than drawn in full. This is the standard's minimum, not a trading partner's requirement: each partner's implementation guide usually makes some optional loops mandatory, restricts the codes and may use a different release.
When it is used
- Increasing or decreasing quantities on an open order
- Changing requested delivery dates or ship-to locations
- Adding or removing line items
- Cancelling an entire purchase order
Where it fits in the document flow
Structure
Key segments in the 860
The segments most implementations use, described in plain language. The last column shows what X12 release 004010 itself requires: "Required" marks a segment the standard requires in every 860; "Optional, common" marks a segment the standard leaves optional, or that sits in an optional loop, but that implementations often use. This is the standard's requirement, not your trading partner's: each partner's implementation guide names the release it uses, makes some optional segments mandatory and restricts the values, and requirements can differ between releases. The requirement status comes from one published X12 reference listing and has not been checked against a second source.
| Segment | Name | What it carries | In X12 004010 |
|---|---|---|---|
| BCH | Beginning Segment for Purchase Order Change | Change purpose, purchase order type, purchase order number and original order date. | Required |
| DTM | Date/Time Reference | Updated delivery, ship or cancel dates. | Optional, common |
| N1 loop | Party Identification | Updated or confirmed ship-to and other parties. | Optional, common |
| POC | Line Item Change | The line being changed, the type of change, the new quantity, price and item identifiers. | Optional, common |
| CTT | Transaction Totals | Number of changed line items. | Optional, common |
Example
Sample EDI 860
A change (04) to purchase order PO123456. The POC segment increases the quantity on line 1 (QI) to 36 units at the same price.
Illustrative data only, not tied to one X12 release or trading partner. The interchange (ISA/IEA) and functional group (GS/GE) envelopes are omitted for readability.
ST*860*0001~
BCH*04*SA*PO123456***20261015~
POC*1*QI*36**EA*12.50**UP*012345678905~
CTT*1~
SE*5*0001~The sample is the same one shown above, with a note beside each segment the first time it appears. Segment IDs are highlighted at the start of each line; the fields after them are separated by asterisks, and each segment ends with a tilde.
Avoid problems
Common 860 errors and how to prevent them
Applying changes to the wrong order
The 860 must be matched to the original order by purchase order number. Orders created from a different number cannot be updated automatically.
Creating duplicates
Treating an 860 like a new order creates duplicate sales orders. Changes should update the existing order.
Ignoring orders already shipped
Changes that arrive after shipment need a review step rather than an automatic update.
Trading partners
Integration guides that include the 860
How ECOM helps
Automate the 860 with ECOM
Solution
Order-to-Cash Automation
Automate the flow from purchase order to payment across every customer channel.
Solution
Procure-to-Pay Automation
Automate purchasing, receiving and supplier invoicing across EDI, portals and documents.
Solution
EDI Integration
Exchange X12 and EDIFACT documents with partners and integrate them directly with your ERP.
EDI 860 FAQs
What is the difference between an 850 and an 860?
The 850 creates a new purchase order. The 860 changes or cancels a purchase order that was already sent.
How does a supplier respond to an 860?
Typically with a 997 functional acknowledgment and, if the buyer requires it, an 865 purchase order change acknowledgment or an updated 855.
Can an 860 cancel an entire order?
Yes. The change purpose code in the BCH segment can indicate a full cancellation.
More general questions about EDI are answered in the EDI FAQ.
Need help with the EDI 860?
ECOM maps, tests and monitors X12 documents for your trading partners and integrates them with your ERP.