An 865 · Purchase Order Change Acknowledgment / Request — Buyer Initiated transaction is the supplier's line-by-line answer to an 860 · Purchase Order Change Request: this change is accepted, this one is rejected, and this one is accepted only with a different date, quantity, or price. It does not change the order itself. It records what the supplier actually agreed to after the buyer asked to change it — and in a dispute, that record is usually the document that decides who is right.
I run SignalEDI. This series has walked the retail order-to-cash chain in order: the 850 · Purchase Order 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, the 852 · Product Activity Data that reports what actually sold, and yesterday the 860 · Purchase Order Change Request that interrupts that tidy sequence. The 865 is the reply that closes the interruption. Without it, the buyer assumes every change took effect. With it, both sides are working from the same revised promise.
What is an 865 · Purchase Order Change Acknowledgment, and why does it matter?
The 865 answers one question: for each change the buyer requested, what does the supplier commit to now? A buyer sends an 860 because something moved on their side — demand shifted, a promotion changed, a date slipped. The supplier's reality may have moved too. Some lines can still be changed. Some are already picked, packed, or on a truck. Some can be changed, but not to the date or price the buyer asked for.
That makes the 865 more than an administrative receipt. It is a negotiation record in a fixed format. Accepted means the new terms are in force. Rejected means the original terms still govern that line. Accepted with changes means neither the original nor the requested version is the promise — the counter-proposed version in the 865 is. If a supplier skips the 865, or sends one that simply accepts everything at the header level, they have not stayed neutral. They have, in practice, let the buyer's version become the only written record.
How is an 865 actually structured?
At the top, the 865 identifies the original purchase order and the change request it answers, so the buyer can match the response to the specific 860 they sent — not just to the order in general. That matching matters when a buyer sends two changes to the same order in one week: an 865 that answers "the order" without answering which change it responds to creates a second ambiguity while trying to resolve the first.
Below the header, the response repeats line by line. Each changed line from the 860 gets a status: accepted, rejected, or accepted with changes. Where the supplier counter-proposes, the line carries the supplier's committed values — the date they can actually ship, the quantity they can actually supply, or the price they will actually honor — rather than echoing back the buyer's requested values. Echoing the request while meaning something different is the quietest 865 failure: the file says agreement, the warehouse plan says otherwise, and nobody discovers the gap until the ASN or the invoice exposes it.
Unchanged lines normally need no response. The discipline is completeness over the changed lines: every line the 860 touched should get an explicit answer, because an unanswered line is read by the buyer's system as pending at best and accepted at worst — rarely as rejected.
How is an 865 different from an 855 · Purchase Order Acknowledgment?
The 855 acknowledges the original 850 · Purchase Order: can we fill this order, as ordered, at all? The 865 acknowledges an 860 change to an order that was already acknowledged once. The distinction sounds clerical and is not. The 855 is written before fulfillment begins, when almost anything can still be promised. The 865 is written into a live operation, when the truthful answer depends on where each line physically is — unallocated, picked, packed, shipped, or invoiced.
That is also why answering an 860 with a fresh 855 is a common and costly shortcut. A new 855 describes a whole order as if it were new; it does not tell the buyer which requested changes were accepted and which were refused. The buyer's system records a promise, not a decision on their change, and the rejected lines sail on as if they had been agreed.
Where do 865 workflows usually break?
The first break is the blanket accept. An integration that acknowledges every 860 automatically, without checking fulfillment state, will accept cancellations for goods already shipped and date changes the warehouse cannot meet. Automation is right for the transport of the 865. It is wrong for the decision inside it, unless that decision is genuinely checked against allocation and shipment status line by line.
The second break is the unexplained rejection. A rejected line with no reason and no counter-proposal leaves the buyer with no next move except a phone call — and, in many trading relationships, a rejected change that arrives without explanation is simply re-sent, louder. The useful rejection says, in effect: this line shipped on this date under the original terms, so the change is too late for this order, however reasonable it would have been last week.
The third break is timing. An 865 sent after the goods ship is history, not an acknowledgment. The value of the document is that it arrives while the buyer can still react — source the short line elsewhere, move the promotion, warn the store. Every day of delay converts a manageable exception into a chargeback argument about who knew what, when.
The fourth break is internal: the 865 goes out, but the ERP, the pick list, and the billing system keep their own versions of the revised order. An acknowledgment that the rest of the operation never reads is a promise made in public and broken in private. The accepted-with-changes values in the 865 have to become the values fulfillment and invoicing actually use.
Frequently asked questions
Is an 865 · Purchase Order Change Acknowledgment required after every 860?
In most retail and distribution relationships, yes — the buyer's implementation guide normally expects an 865 in response to an 860, line by line. Even where it is not formally required, silence is risky: the buyer will usually proceed as if the changes were accepted.
Can a supplier accept part of an 860 and reject the rest?
Yes, and that is the normal case. The 865 is line-by-line precisely so a supplier can accept the date change on one line, reject a cancellation on a line that already shipped, and counter-propose a quantity on a third — all in one response.
Does an 865 itself change the purchase order?
No. The 860 requests the change and the 865 records the supplier's decision about it. The revised order that fulfillment and invoicing should work from is the original 850 as modified by the accepted and counter-proposed lines in the 865 — not by the 860 alone.
Each EDI document in this series answers exactly one question well. The 865's question is "you asked to change the promise — here is, line by line, the promise we can actually keep." Sending that answer explicitly, promptly, and from the real state of the operation is the discipline we build SignalEDI around.
— Chris, founder of SignalEDI
Top comments (0)