BCH
Beginning segment for purchase order change: purpose, PO type, the PO number and date being changed, and the change date.
EDI 860: Purchase Order Change Request (Buyer Initiated)
A buyer’s change to an order already sent: add, delete, or modify lines, quantities, prices, or dates. Buyer to supplier. This page covers what the 860 is for, the segments you meet when you open one, the documents it travels with, where it tends to go wrong, and how it moves over AS2 into your systems on Files.com, which receives, parses, validates, and routes it as configuration.
No credit card required · 7-day free trial · Live in minutes
#1 MFT vendor in Gartner Peer Insights
Trusted by 4,000+ companies
Every protocol included
What The 860 Is For
The 860 changes an 850 after it has gone out. A buyer sends it to add or remove lines, change quantities or prices, move dates, or cancel the order, referencing the original PO number and describing each change at the line level with a change code that says what kind of change it is.
The supplier answers with an 865, accepting or rejecting the changes. Because the 860 modifies commitments already in motion, both sides have to agree on how late in the cycle a change can arrive, and an 860 that lands after the 856 has shipped is a return, not a change.
The Segments You Meet First
In document order, the segments that carry the 860's meaning. A partner's implementation guide says which are required and which fields each must hold.
REF
References tied to the original order.
DTM
Revised dates.
N1
Parties, when a ship-to or bill-to changes.
POC
Line item change: the change type (add, delete, quantity change, price change), the new quantity, and the product identifiers.
CTT
Transaction totals.
Where It Goes Wrong
Applying a change to the wrong line because product identifiers in the POC do not match the 850, and processing a change that arrived after fulfillment. Systems also disagree on whether an 860 replaces the whole order or only the lines it names; the change codes in POC settle it, and a translator that ignores them applies the wrong thing.
The Documents It Travels With
The 860 rarely moves alone. These are the documents that precede, answer, or settle it.
850 · Purchase Order
A buyer’s order to a supplier: the items, quantities, prices, dates, and ship-to locations.
See The 850865 · Purchase Order Change Acknowledgment / Request (Seller Initiated)
The seller’s answer to a buyer’s change request, or a change the seller proposes on its own.
See The 865855 · Purchase Order Acknowledgment
The supplier’s answer to a purchase order: accepted, rejected, changed, or backordered, line by line.
See The 855997 · Functional Acknowledgment
The receipt that says an EDI transmission arrived and was parsed, with any syntax errors found.
See The 997How The 860 Moves On Files.com
A partner sends the 860 over AS2, SFTP, or FTPS, and it lands in that partner’s inbox folder on Files.com with the transport receipt recorded. From there it is a workflow, not a project: TransformScript parses the X12 natively into the JSON, CSV, or XML your ERP or WMS reads, content validation flags a document whose contents are wrong before anything ingests it, and an automation routes the result to the system and the people who act on it.
Outbound is the mirror image. Your system exports its record, TransformScript builds the 860 the partner’s guide specifies, and the file dropped in the partner’s outbox goes out over AS2 with automatic retries until the MDN confirms delivery. Every transmission in both directions is in the audit log, and delivery monitoring alerts when a 860 that was due never arrives. The full picture is on the EDI software page.
EDI 860 Questions
What teams ask about the 860 and how it moves on Files.com.
An EDI 860 is the X12 Purchase Order Change Request, Buyer Initiated. A buyer sends it to modify an 850 already sent, adding, deleting, or changing lines, quantities, prices, or dates, and the supplier responds with an 865.
The 860 is the buyer asking for a change. The 865 is the seller’s acknowledgment of that change, or a change the seller initiates on its own.
Yes. Files.com is a standards-compliant RFC 4130 AS2 endpoint, and a 860 sent by a trading partner lands in that partner’s inbox folder with a signed MDN receipt returned to the sender. Partners who exchange over SFTP or FTPS connect to the same platform and the document lands in the same place.
Yes. TransformScript parses the X12 860 natively and writes the JSON, CSV, or XML your systems ingest, as a step in the workflow that fires when the document arrives. Outbound, the same engine builds a 860 from your system’s export and drops it in the partner’s outbox for delivery.
Exchange The 860 Without The Legacy Stack
Start the 7-day trial, turn AS2 on, and exchange certificates with your partner. The 860 lands in their folder, parses into the record your system reads, and every transmission carries a signed receipt.
No credit card required • Free for 7 days • Live in minutes