Understand EDI 860 purchase order changes with an example, key segments, and change codes. Learn how suppliers respond and avoid costly fulfillment errors.
An EDI 860 is an electronic data interchange (EDI) transaction that buyers send to suppliers to request changes to, or cancellation of, an existing purchase order (PO).
For suppliers, understanding 860 EDI transactions, their change codes, and how to respond is an important part of modern EDI practices that support accuracy and trading partner compliance.
What Is an EDI 860 Purchase Order Change?
An EDI 860 references the original EDI 850 purchase order, allowing suppliers to identify which PO needs updating without creating a new order.
Receiving an 860 doesn't automatically mean the supplier accepts the requested changes. Suppliers must review the revised terms, decide whether they can accommodate them, and formally acknowledge the changes if the retailer requires it.
When Do Retailers Send an EDI 860?
Retailers send an 860 when inventory needs, delivery schedules, or other business requirements change after the retailer submits the original PO. However, they may restrict modifications once fulfillment is underway.
Common reasons for sending a PO change include:
Quantity adjustments: Increase or decrease ordered quantities based on inventory levels or changes in demand.
Price corrections: Update agreed-upon pricing or correct errors in the original PO.
Shipping or delivery dates: Move scheduled dates to accommodate changing delivery requirements.
Ship-to changes: Redirect a shipment to a different warehouse, distribution center, or store.
Line item changes: Add products to an existing PO or remove items that are no longer needed.
Order cancellations: Cancel an entire PO when the retailer no longer needs the shipment.
Permitted changes and submission deadlines depend on each retailer's trading partner requirements. Modifications to orders already being prepared for shipment may require additional coordination.
What Are the Key Segments in an EDI 860?
EDI 860 segments identify the original PO, describe requested modifications, and provide supporting transaction details. Each serves a specific purpose, helping suppliers interpret changes and match them to the correct PO.
Segment | Name | Purpose |
|---|---|---|
ST | Transaction Set Header | Identifies the document as an 860 and assigns a control number |
BCH | Beginning Segment for Purchase Order Change | Identifies the original PO and indicates whether the document changes, replaces, or cancels it |
CUR | Currency | Specifies the currency used in the transaction |
REF | Reference Information | Provides additional identifiers, such as department or vendor reference numbers |
DTM | Date/Time Reference | Communicates relevant dates, including revised shipping or delivery dates |
N1 | Name | Identifies parties involved in the transaction, such as the buyer or ship-to location |
POC | Line Item Change | Identifies affected line items and specifies the requested changes |
PID | Product/Item Description | Provides descriptive information about products referenced in the order |
CTT | Transaction Totals | Reports the number of line items included in the transaction |
SE | Transaction Set Trailer | Marks the end of the transaction and provides a segment count for validation |
Not every 860 utilizes all these segments. Each retailer's implementation guide specifies which optional segments and data elements are required.
BCH Purpose Codes
The BCH segment uses the BCH01 purpose code to indicate whether an 860 changes, replaces, or cancels an existing PO.
Code | Meaning | What the Supplier Must Do |
|---|---|---|
01 | Cancellation | Cancel the referenced PO and stop any unfulfilled shipments |
04 | Change | Apply the specified changes while retaining unaffected order details |
05 | Replace | Replace the existing order details with the revised information provided in the 860 |
Not all retailers support every purpose code. Suppliers should consult each trading partner's implementation guide for accepted codes and processing requirements.
POC Change Type Codes
The POC02 element identifies the requested modification to an individual line item. These POC change type codes help suppliers determine how to update the corresponding sales order.
Code | Meaning | What the Supplier Must Do |
|---|---|---|
AI | Add additional item | Add the specified product and quantity to the sales order |
DI | Delete item | Remove the identified line item and stop fulfillment for that item |
PC | Price change | Update the affected item's price to match the revised terms |
QI | Quantity increase | Adjust the line item's quantity upward based on the adjustment details |
QD | Quantity decrease | Reduce the line item's quantity according to the revised order |
RS | Reschedule | Update the affected shipping or delivery dates |
CA | Change to line item | Review the specified line item and apply the indicated modifications |
Retailers may support different code subsets or interpret quantities and other values differently. Suppliers should follow each trading partner's implementation guide.
EDI 860 Example
An 860 communicates purchase order changes through ANSI X12 segments that identify the original order and describe the requested modifications. The following simplified example shows a retailer reducing an order quantity from 10 units to 8.
Example ANSI transaction:
ST*860*0001~
BCH*04*SA*PO12345***20261015~
POC*1*QD*10*2*EA~
CTT*1~
SE*5*0001~
In this example:
ST identifies the 860 transaction and assigns control number 0001.
BCH identifies a change (04) to purchase order PO12345, dated October 15, 2026.
POC identifies line item 1 and requests a quantity decrease (QD) of 2 units from the original 10.
CTT identifies one affected line item.
SE closes the transaction and confirms a total of five segments.
Equivalent JSON representation:
{
  "transactionType": "860",
  "controlNumber": "0001",
  "purposeCode": "04",
  "purchaseOrderType": "SA",
  "purchaseOrderNumber": "PO12345",
  "purchaseOrderDate": "2026-10-15",
  "lineItems": [
    {
      "lineNumber": "1",
      "changeCode": "QD",
      "originalQuantity": 10,
      "quantityDecrease": 2,
      "unitOfMeasure": "EA",
      "revisedQuantity": 8
    }
  ]
}
The JSON represents the same modification as structured data that can be mapped into ERP systems through solutions such as EDI integration with NetSuite. The exact JSON structure depends on the integration platform and trading partner requirements.
How Should Suppliers Respond to an EDI 860?
Suppliers should review requested PO changes, determine whether they can accommodate them, and update the corresponding sales order. Depending on retailer requirements, they may also need to send an EDI 865 purchase order change acknowledgment.
The process generally involves four steps:
Review the request for adjustment: Match the 860 to the original purchase order and verify the requested modifications.
Confirm acceptance: Determine whether the changes can be fulfilled as requested or require further coordination with the buyer.
Update the sales order: Apply accepted changes to the ERP or order management system and communicate updates to fulfillment teams.
Send an acknowledgment: If required, transmit an EDI 865 within the retailer's specified response window.
The key distinction in comparing 860 vs. 865 is who sends each transaction. Buyers send 860s to request modifications, while suppliers use 865s to accept, reject, or propose changes. Response deadlines vary by trading partner.
EDI 850 vs. 860 vs. 855 vs. 865: What's the Difference?
The 850, 855, 860, and 865 support different stages of the purchase order process, from placing orders to acknowledging changes.
Transaction | Sender | Purpose | When It's Sent |
|---|---|---|---|
EDI 850 | Buyer | Creates the original PO | When the buyer places an order |
EDI 855 | Supplier | Acknowledges the PO and communicates acceptance, rejection, or proposed changes | After the supplier processes the original 850 |
EDI 860 | Buyer | Requests changes to an existing PO or confirms acceptance of supplier-proposed changes | After the original order has been submitted |
EDI 865 | Supplier | Acknowledges, accepts, rejects, or proposes changes to a PO | When responding to an 860 or initiating a seller-side request for modification |
The EDI 855 purchase order acknowledgment addresses the original order, while the 865 handles subsequent changes. Not every retailer requires all four transactions.
What EDI 860 Mistakes Lead to Chargebacks?Â
Failing to process EDI 860 changes correctly can lead to shipment discrepancies, compliance violations, and retailer chargebacks. For example, a supplier that ships 100 units after receiving an 860 that reduces the order to 80 may face penalties for the 20 excess units.
Common mistakes that increase chargeback risk include:
Processing changes out of order: Applying an older 860 after a newer one can overwrite the most recent purchase order details.
Shipping against the original PO: Failing to update fulfillment records can result in shipments with incorrect quantities, prices, or delivery instructions.
Manual data entry errors: Re-keying requests into an ERP system increases the risk of incorrect quantities, missed line items, and other potential EDI errors.
Missing cancellations: Overlooking a canceled PO or deleted line item can result in unauthorized shipments and associated penalties.
Validation issues in incoming 860s may appear as error codes in 997 or 999 acknowledgments, helping suppliers identify problems before fulfillment. Validating changes, keeping accurate records, and updating fulfillment systems can help suppliers avoid retailer chargebacks and stay compliant with trading partners.
How Do You Automate EDI 860 Processing in Your ERP?
Automating 860 processing connects incoming requests to sales orders in your ERP. A properly configured integration can validate data, match orders, and reduce manual updates.
Effective EDI and ERP integration supports automated data exchange and exception handling. It flags changes that can't be processed automatically for review before they disrupt fulfillment.
Orderful's Mosaic uses a standardized API connection to exchange EDI data with business systems. It handles trading partner-specific mapping and validation while delivering structured JSON for ERP integration. This reduces manual data entry without requiring separate integrations for every retailer.
See How Orderful Connects EDI to Your ERP
Managing purchase order modifications across multiple trading partners doesn't have to mean additional manual work or complicated integrations. Orderful helps suppliers simplify EDI connectivity, validate incoming data, and keep information flowing between trading partners and business systems.
Book a demo to see how Mosaic can support your EDI integration needs.
EDI 860 Frequently Asked Questions
What Is an EDI 860?
An EDI 860 is an X12 purchase order change request that buyers send to suppliers to modify or cancel an existing purchase order. Changes may involve quantities, prices, dates, delivery locations, or individual line items. It references the original 850 purchase order, so suppliers can update the existing sales order instead of creating a new one.
What Is the Difference Between EDI 860 and EDI 865?
The buyer sends an 860 to request changes to an existing purchase order, while the supplier typically sends an 865 to acknowledge those changes. The acknowledgment communicates whether the supplier accepts, rejects, or proposes modifications to the request. Both transactions reference the original purchase order number from the 850.
What Does the POC Segment Mean in an EDI 860?
The POC segment identifies changes to individual line items. Its POC02 element uses codes such as AI (add item), DI (delete item), PC (price change), QI (quantity increase), and QD (quantity decrease). Supported codes vary by retailer. Other POC elements carry the quantity, unit of measure, and price for the changed line.
How Should a Supplier Respond to an EDI 860?
Suppliers should review the requested modifications, update the corresponding sales order when changes are accepted, and confirm that fulfillment reflects the revised terms. If required, they must also send an EDI 865 acknowledgment within the retailer's specified response window. Response windows and required codes vary by trading partner.
Can an EDI 860 Cancel a Purchase Order?
Yes. An 860 can cancel an entire purchase order using the cancellation purpose code (01) in the BCH segment. Individual line items can also be removed using the DI change code in the POC segment. If the retailer requires a response, the supplier confirms the cancellation with an EDI 865.
Does Every Retailer Use the EDI 860?
No. Some retailers send 860s for any change to an open order, while others ask suppliers to cancel and reissue the purchase order or handle changes through a supplier portal. Retailers that use the 860 also differ in which purpose codes and POC change codes they accept and whether they require an 865 in response. Check each trading partner's implementation guide before go-live.
How Do I Get EDI 860 Changes Into My ERP Automatically?
Use an EDI integration platform that receives the 860, validates it against the retailer's requirements, and maps the changes to the matching sales order in your ERP. Orderful's Mosaic delivers each 860 as structured JSON through one standardized API connection, so suppliers can apply quantity, price, date, and cancellation changes without re-keying them or building a separate integration for every retailer.
- 01What Is an EDI 860 Purchase Order Change?
- 02When Do Retailers Send an EDI 860?
- 03What Are the Key Segments in an EDI 860?
- 04EDI 860 Example
- 05How Should Suppliers Respond to an EDI 860?
- 06EDI 850 vs. 860 vs. 855 vs. 865: What's the Difference?
- 07What EDI 860 Mistakes Lead to Chargebacks?Â
- 08How Do You Automate EDI 860 Processing in Your ERP?
- 09See How Orderful Connects EDI to Your ERP
- 10EDI 860 Frequently Asked Questions
