EDI 865 PO Change Acknowledgment: The Complete Guide (2026)

Say a buyer just moved the goalposts: an 860 change request arrived, cutting two lines, doubling a third, and pushing the ship date. Whatever you do next — comply, push back, or split the difference — the buyer's system needs a formal answer. That answer is the EDI 865 Purchase Order Change Acknowledgment, the closing half of the change conversation and one of the most underused documents in the order chain.

Two jobs in one transaction

The 865 has a dual identity written into its name in the standard: acknowledgment and request. In its common role, it responds to a buyer's 860 — confirming, line by line, which changes you accept, which you reject, and which you can only partially meet. In its second role, it travels the other direction as a seller-initiated change: you asking the buyer to accept a modification to a confirmed order, because a lot didn't pass inspection or a component ran short. Not every trading relationship enables the second mode, but where it exists it beats the alternative — an email to a buyer who may or may not update their system.

Structurally it will feel familiar if you know the 855: a BCA header segment referencing the PO being changed, then detail loops echoing affected lines with ACK-style statuses and POC-style change detail, dates in DTM. The vocabulary of acceptance and rejection is the same; only the subject differs.

Partners vary in which changes they will even send through this channel — some route price revisions through buyers instead, some restrict the exchange to quantities and dates. Reading the partner's implementation guide up front spares you from building responses the other side will never process.

Why the response leg matters

It's tempting to treat the 865 as bureaucratic overhead — the change was applied, why announce it? Three reasons:

• It closes the loop in the buyer's system. Until an acknowledgment posts, the buyer doesn't know whether the revised order is real. Planning, receiving, and payables all key off the acknowledged state.
• It's your objection channel. A change you can't meet — quantities already picked, a date physically impossible — needs a rejection on the record, in the buyer's system, before freight moves. A rejected change line in an 865 is dramatically better evidence than a phone call when the deduction conversation happens later.
• It keeps documents consistent. The acknowledged state is what your 856 ship notice and invoice should be generated against. An explicit 865 forces the change to actually apply in your ERP rather than floating in an inbox.

Automating the conversation

The 860/865 exchange automates cleanly because it's deterministic: the change either fits your fulfillment state or it doesn't. EDISQ applies inbound 860s to the order in your ERP, evaluates each change against current fulfillment status — unpicked lines accept automatically, in-progress lines flag for a human decision — and generates the 865 from the outcome. The 850-to-change-to-acknowledgment thread stays linked end to end, so anyone looking at the order sees its full revision history rather than three disconnected documents. That thread has audit value beyond operations: when a deductions analyst asks why a shipment differed from the original order, the linked chain answers in seconds — original commitment, buyer's change, your acknowledged response — without anyone reconstructing history from emails.

The cost of answering

Since the 865 only exists when orders change, its volume is inherently modest — which makes flat per-document pricing kind to it. Under EDISQ's model, it draws from the same pool as everything else: 25 free documents monthly, then from $0.50 per document with tiered declines to $0.10, billed marginally, with no mapping or setup charges underneath. Answering every change formally costs pocket change; not answering them has a way of costing real money.

FAQ