X12 transaction guide · Ordering
EDI 865 Purchase Order Change Acknowledgment/Request - Seller Initiated
The X12 document a seller uses to accept, reject or modify changes a buyer made to a purchase order, or to propose its own change.
- Sent by
- Seller or supplier
- Received by
- Buyer
- Standard
- ANSI ASC X12
- EDIFACT equivalent
- ORDRSP
What is an EDI 865?
The EDI 865 Purchase Order Change Acknowledgment/Request - Seller Initiated is the ANSI X12 transaction set a seller uses to respond to changes the buyer made to an existing purchase order. It tells the buyer which changes are accepted, which are rejected and which are accepted with modifications. The same transaction set also lets the seller start a change itself, for example to propose a different ship date or quantity.
The 865 closes the loop on the 860. Without it, a buyer cannot be sure that a requested change will actually be reflected in what ships and what is invoiced.
How to read this diagram: the top row shows who sends the 865, to whom, and which documents usually come before and after it. The lower part shows what X12 release 008010 itself requires: the envelopes around the 865 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
- Accepting or rejecting a buyer's 860 order change
- Confirming changes with different quantities or dates
- Proposing a seller-initiated change to an open order
Where it fits in the document flow
Structure
Mandatory segments in the 865 (X12 release 008010)
The segments X12 release 008010 marks as mandatory at their level, in order. Segments inside optional loops are needed only when the loop is used. This is the standard's requirement, not your trading partner's: each partner's implementation guide names the release it uses, adds the optional segments it requires and restricts the values. The requirement status comes from one published X12 reference listing and has not been checked against a second source.
- ST
- BCA
- SAC
- LDT
- N9
- N1
- AMT
- ADV
- LM
- LQ
- POC
- PID
- ACK
- QTY
- SCH
- SLN
- PD
- CTT
- SE
Practical example
The 865 in practice
A retailer sends an 860 asking to raise the quantity on one line and move the delivery date earlier. The supplier can supply the extra units but not the earlier date, so it returns an 865 accepting the quantity change and rejecting the date change, with the date it can meet. The retailer updates its open order and plans receiving for the confirmed date.
Implementation
Implementation considerations for the 865
- Respond line by line, so the buyer knows exactly which changes were applied.
- Update the sales order before the 865 is sent, so ship notices and invoices match the confirmed changes.
- Check each partner's rules on response times and whether seller-initiated changes are accepted at all.
How ECOM helps
Automate the 865 with ECOM
Solution
Order-to-Cash Automation
Automate the flow from purchase order to payment across every customer channel.
Industry
Retail
Retail and eCommerce EDI for suppliers and retailers, from purchase order to payment, with compliance built in.
Solution
EDI Integration
Exchange X12 and EDIFACT documents with partners and integrate them directly with your ERP.
More general questions about EDI are answered in the EDI FAQ.
Need help with the EDI 865?
ECOM maps, tests and monitors X12 documents for your trading partners and integrates them with your ERP.