An 860 · Purchase Order Change Request — Buyer Initiated transaction is how a buyer changes an order they have already sent: quantities, dates, prices, items added or cancelled, ship-to details corrected. It is not a correction to a file. It is a renegotiation of the promise the original 850 · Purchase Order created — and treating it like a small edit is how suppliers end up shipping the wrong order, correctly.
I run SignalEDI. This series has walked the retail order-to-cash chain in order: the 850 that starts it, the 855 · Purchase Order Acknowledgment that promises it, the 856 · Ship Notice / ASN that ships it, the 810 · Invoice that bills it, the 846 · Inventory Inquiry/Advice that tells a buyer what you can sell, and the 852 · Product Activity Data that reports what actually sold. The 860 is the document that interrupts that tidy sequence, usually at the worst possible moment: after picking has started, sometimes after the truck is loaded.
What is an 860 · Purchase Order Change Request, and why does it matter?
The 860 answers one question: what, exactly, is different about this order now? A buyer sends it because something on their side moved — demand shifted, a promotion was pulled, a store closed, a price was agreed wrong, or the original order simply contained an error. The change can be surgical, one line's date moved by a week, or brutal: half the lines cancelled the day before the ship window opens.
What makes the 860 matter more than its volume suggests is timing. An 850 arrives when nothing has happened yet, so any system can handle it. An 860 arrives into a live operation. The order may already be acknowledged, allocated, picked, packed, or invoiced in part. Every one of those states changes what the change is allowed to mean — and a workflow that applies the 860 as if the order were still fresh will happily cancel lines that are already on a truck.
How is an 860 actually structured?
At the top, the 860 identifies the original purchase order it modifies — its number and date — and carries a change type that frames the whole transaction: is this a replacement order that supersedes the original in full, or a set of line-level changes to be applied against it? That distinction is the document, and confusing the two is the classic 860 failure. Apply a replacement as a set of deltas and you double-count everything that did not change. Apply deltas as a replacement and you silently delete every line the buyer did not mention.
Below the header, changed lines carry the same identifiers as the original order — the buyer's item numbers, your identifiers where they were exchanged, quantities, prices, and requested dates — with codes that say what kind of change each line represents: quantity increased, quantity decreased, item added, item deleted, date changed, price changed. Unchanged lines may be omitted entirely, repeated in full, or repeated only as context, depending on the buyer's implementation guide. There is no universal convention, which is why "we support the 860" always has to mean "we support this partner's 860, tested against their examples."
A companion document completes the loop: the supplier answers a change with the 865 · Purchase Order Change Acknowledgment / Request — Buyer Initiated, accepting, rejecting, or accepting with changes, line by line. An 860 that gets no 865 leaves the buyer assuming the new terms are in force. Silence, in this exchange, functions as agreement — whether or not anyone agreed.
Why do suppliers acknowledge the original order carefully and the change casually?
Because the 855 workflow had a human in it. The original order was reviewed, exceptions were caught, the promise was made deliberately. The change often lands in a different queue — handled as an administrative update by whoever maintains the order file, long after the warehouse has taken the original promise as ground truth.
The result is a split-brain order: the ERP shows the changed quantity, the pick list shows the original, the ASN goes out against whichever version the shipping system cached, and the invoice is written against a third. Every resulting chargeback and short-ship dispute is then argued from documents that are each, individually, "what the system said." The fix is not a better argument. It is a single rule: a changed order is a new promise, and it re-enters the same acknowledgment, allocation, and exception workflow the original order went through — at whatever stage the operation has actually reached.
Where do 860 workflows usually break?
The first break is the race with fulfillment. A cancellation that arrives after the ASN has been transmitted cannot unpick a pallet; it can only start a conversation about refusal, return, or acceptance at a discount. Systems need an honest answer for "too late to change" that is sent promptly in the 865, not a silent application of an impossible change.
The second break is partial changes read as complete orders. If the buyer's guide says the 860 carries changed lines only, an integration that rebuilds the order from the 860 alone will delete every unchanged line it was never sent. This is the single most destructive mapping error in the retail chain, precisely because the file itself is perfectly valid — the damage is done by an assumption, not a malformed segment.
The third break is never reconciling the changed order against what was already invoiced. Quantity decreases after partial invoicing, price changes after the 810 has gone out, and cancellations of lines already billed all need credit and rebill handling, not just an edited order record — otherwise the 860 quietly becomes an accounts-receivable dispute scheduled for next quarter.
Frequently asked questions
Is an 860 · Purchase Order Change Request the same as an 850 · Purchase Order?
No. The 850 creates the original order. The 860 modifies an 850 that already exists, identified by its original order number — changing, adding, or cancelling lines. A related transaction, the 830 · Planning Schedule, forecasts future demand without creating a firm order at all.
How should a supplier respond to an 860?
With the 865 · Purchase Order Change Acknowledgment, line by line: accepted, rejected, or accepted as changed. Lines that can no longer be changed because fulfillment has passed the point of no return should be rejected explicitly and immediately — not silently ignored.
Can an 860 change a price after goods have shipped?
Buyers sometimes send price changes late, but a shipped and invoiced line cannot simply be re-priced by editing the order — it has to be settled through the invoice and deduction process. Treating a late price change as a routine order edit is how unexplained deductions are born.
Each EDI document in this series answers exactly one question well. The 860's question is "here is what changed — does the promise still hold, line by line, from where the operation actually stands?" Answering it through the same disciplined acknowledgment path as the original order, instead of as a quiet file edit, is the discipline we build SignalEDI around.
— Chris, founder of SignalEDI
Top comments (0)