What Is EDI 860? Purchase Order Change Explained

What is EDI 860?

EDI 860 is the ANSI X12 Purchase Order Change Request - Buyer Initiated transaction set. A buyer sends it to a seller to modify a previously transmitted EDI 850 purchase order, such as changing quantities, prices, dates or cancelling specific lines, without voiding the order and starting over.

The transaction follows the X12 standard maintained for U.S. trading partners. EDI 860 documents follow the x12 format set by the American National Standards Institute (ANSI), a not-for-profit organization that regulates EDI formats in the U.S. If you're working with European or APAC suppliers running EDIFACT instead, the equivalent message is ORDCHG. An EDIFACT ORDCHG message is used to update and amend a previously sent EDIFACT ORDERS message, referencing the past purchase order number, and then detailing the required changes. Same job, different syntax, and yes, if you run both standards you'll be mapping this logic twice.

EDI 860 vs. cancelling and resending an EDI 850

This is where a lot of confusion happens. You have two ways to change an order: send a targeted 860, or cancel the original 850 and issue a brand new one. They are not interchangeable, and picking the wrong one breaks things downstream.

Using EDI 860 makes it easy to change orders without needing to cancel an order and create a new EDI 850 transaction. The 860 references the original PO and applies only the delta. The supplier's system maintains the 850 as the base record and applies each 860 as a versioned change, creating an audit trail of the order's full modification history. Cancel-and-reissue throws that history away. Your ERP sees a dead PO and a fresh one with no explicit link back to the original, unless you're maintaining that mapping manually in a reference field.

Not every retailer treats this the same way. Some trading partners lean on the 860 heavily for quantity and date tweaks, while others still prefer a clean cancel-and-reissue for most changes and only use the 860 for narrower scenarios. Check the partner's implementation guide before you assume behavior is uniform across your supplier base.

The seller's side of this conversation is the EDI 865. Always sent by the buyer to the supplier, referencing the original 850; the supplier accepts or contests the change with an 865 Purchase Order Change Acknowledgment. Some programs allow it to run in reverse too: EDI 860 can also be used as a response to EDI 865, when a seller is requesting a change instead of the buyer, in which case it can indicate acceptance, acceptance with changes, or rejection. Partners can loop between 860 and 865 until both sides land on the same terms.

Segment structure: what's actually inside an EDI 860

The 860 mirrors the 850's shape but swaps the header segment and adds change codes at the line level. Here's what an implementer actually needs to check.

• BCH replaces the 850's BEG segment. BCH01 is the transaction set purpose code (00 = original change, 05 = reissue of change) and BCH02 is the PO type code, matching the original 850's BEG02.
• Original PO reference sits in the BCH segment too. This is the original PO that the 860 modifies, and the PO number field must match the 850's BEG03 exactly. A stray leading zero here is enough to bounce the whole transaction.
• PO1/POC line loop carries the change code. Change codes include AI (add item), CA (cancel entire order), CI (cancel line), DI (delete line), QI (quantity increase), QD (quantity decrease), and PI (price change).
• Only the changed lines travel, in most implementations. The 860 must only transmit what changed, so if only line 3 of a 10-line PO is changing, the 860 should contain only a PO1 for line 3, unless the trading partner's spec requires full-PO retransmission.
• CTT closes the count. CTT01 is the number of PO1 loops in the 860, not the total lines in the original 850, so a full-cancel 860 may show CTT01=1 while a multi-line revision shows CTT01=6, and mismatched counts cause functional acknowledgment rejections.

Picture a big-box retailer that sent an 850 for 500 units of a SKU with a ship date of next Friday, then decides three days later it only needs 350 units and can push the date a week. The buyer's EDI system fires an 860 referencing that original PO number, carrying a single PO1 line with a QD (quantity decrease) code and an updated DTM date segment, nothing else. The supplier's translator applies that as a delta against the open order. No new PO number, no re-keyed header data, no lost history.

Why a PO change is rarely just a procurement event

Here's what most EDI teams miss: an 860 doesn't stop at the ERP. If freight was already tendered against the original 850's quantities, that quantity decrease or date shift can leave a carrier dispatched for the wrong weight, a warehouse picking against stale numbers, or an ASN about to go out with data that no longer matches reality.

Think through the sequence. The 850 goes out, the buyer's routing logic (or the supplier's, depending on who owns freight) tenders a load based on those original quantities and dates. Days later the 860 lands, cutting the quantity by 30% and moving the ship date. If nothing downstream is watching for that signal, you end up with a truck booked for a load that's now smaller, or worse, dispatched on the wrong day entirely. The warehouse floor is still working off the original pick list. The ASN that eventually goes out doesn't match what was actually loaded, which is exactly the kind of mismatch that triggers retailer chargebacks.

This is precisely where transportation systems need to be plugged into the same event stream as your EDI translator, not treated as a downstream afterthought. Platforms like MercuryGate, Descartes, and Blue Yonder can re-tender or re-route once they see the updated order data, but only if someone built the integration to push that 860-derived change to them in the first place. Multi-carrier tendering tools such as Cargoson work the same way: the moment the underlying order line changes, the tender needs to be pulled and reissued before the ASN goes out, not after a driver is already at the dock. Miss that window and you're doing it manually over the phone, which is exactly the workflow EDI was supposed to eliminate.

Common implementation pitfalls

• Sellers who never built 860 support at all. Some suppliers only mapped inbound 850s and handle every subsequent change by phone or email, which defeats the point and introduces manual entry errors right at the point where accuracy matters most.
• Ambiguous change codes. Change code CA cancels the entire order while CI cancels just a line and DI deletes a line entirely, and teams that don't build clear logic for each code end up applying the wrong action against the open order.
• Partners requiring full-PO retransmission. Some trading partner specs require full-PO retransmission rather than a delta of only the changed lines, so a mapping built against one retailer's expectations will fail against another's.
• Timing races with the ASN. If an 856 has already been generated or transmitted by the time the 860 arrives, you need a defined cutoff policy with the trading partner for what happens next, because most systems won't automatically reconcile a shipped ASN against a change that landed an hour later.

FAQ

Does every retailer support EDI 860? No. Support and usage patterns vary heavily by trading partner guide, and some retailers prefer cancel-and-reissue of the 850 for most scenarios rather than a change document.

What's the difference between EDI 860 and EDI 876? EDI 876, Grocery Products Purchase Order Change, is sent by suppliers notifying their buyer of changes to the initial order received as an EDI 875 Grocery Products Purchase Order, so it's a grocery-specific, seller-initiated variant rather than a general-purpose buyer-initiated change document.

How should a seller respond to an EDI 860? With an EDI 865. The buyer sends the EDI 860 to initiate the change, and the seller sends back an EDI 865 Purchase Order Change Acknowledgment to confirm.

Is there an EDIFACT equivalent? Yes, ORDCHG, mapped directly to X12's 860 in cross-standard reference tables.

What happens if I ignore an 860? You fulfill against outdated order data, which is exactly the scenario the transaction set exists to prevent, and it flows straight through to invoice mismatches and chargebacks once the ASN and the invoice no longer line up with what the buyer actually authorized.