Skip to content

Stacksync × Supabase Miami: AI-Native OperationsOct 13Reserve your spot

X12 transaction code

EDI 860 Purchase Order Change Request (Buyer Initiated) (X12 860)

EDI 860 is the PO change request, the X12 Purchase Order Change Request (Buyer Initiated) transaction set, used when a buyer changes a previously issued order. The buyer sends the 860 to the supplier and references the original 850. The supplier accepts or contests the change with an 865 Purchase Order Change Acknowledgment.

Standard
X12
Code
860
Partner references
140

At a glance

EDI 860 at a glance

What the 860 carries, who sends it to whom, when it goes out, and the segments trading partners list for it.

X12 860 Purchase Order Change Request (Buyer Initiated) summary
Document X12 860 Purchase Order Change Request (Buyer Initiated)
Business record Buyer order-change request
Who sends it to whom The buyer sends the 860 to the supplier and references the original 850. The supplier accepts or contests the change with an 865 Purchase Order Change Acknowledgment.
When it is sent A buyer needs to change quantities, pricing, dates, or line items on an open order, or cancel it outright, at any point in the order cycle including after partial shipment.
Match on Original purchase order, change revision and affected line
Partner references 140 trading partners in this directory
Related documents X12 850 Purchase Order, X12 865 Purchase Order Change Acknowledgment/Request (Seller Initiated)

Key segments in an EDI 860

The business segments that appear in at least half of the 171 partner document references listed below, most common first. The table leaves out envelope segments (ISA, GS, ST, SE, GE, IEA). Your partner guide sets which segments and elements your account must send.

Segment Name Purpose Partner references
BCH Beginning Segment for Purchase Order Change To indicate the beginning of the Purchase Order Change Transaction Set and transmit identifying numbers and dates. 171 of 171
POC Line Item Change To specify changes to a line item. 171 of 171
CTT Transaction Totals To transmit a hash total for a specific element in the transaction set. 167 of 171
REF Reference Information To specify identifying information. 161 of 171
DTM Date/Time Reference To specify pertinent dates and times. 156 of 171
PID Product/Item Description To describe a product or process in coded or free-form format. 153 of 171
N1 Party Identification To identify a party by type of organization, name, and code. 146 of 171
N4 Geographic Location To specify the geographic place of the named party. 134 of 171
N3 Party Location To specify the location of the named party. 131 of 171
N9 Extended Reference Information To transmit identifying information as specified by the Reference Identification Qualifier. 120 of 171

Stacksync connects EDI documents such as the X12 860 to your ERP, CRM and databases with two-way sync. Read the EDI overview, check pricing and security, or book a demo to walk through your partner guide.

Implementation guide

X12 860 mapping and validation

X12 860 Purchase Order Change Request (Buyer Initiated) is used when a buyer changes a previously issued order. Preserve original purchase order, change revision and affected line so the buyer order-change request in your business system stays connected to the original document.

Use the version and implementation guide agreed with your trading partner to confirm required fields and responses.

Map records and test the business result
Document or decisionRecord and matching IDsWhat to test
Match the business record buyer order-change request

original purchase order, change revision and affected line

  • Define which combination of original purchase order, change revision and affected line identifies one business record, its lines and any later revision.
Update the receiving system Processing the buyer order-change request

ID assigned by the receiving system and processing result

  • Apply a quantity reduction to the existing order instead of creating another order.
  • Test a cancellation arriving after allocation or shipment and route it to an exception owner.
Check the processing result Processing status for the buyer order-change request

Original document reference and matching response

  • Reconcile the buyer order-change request with the source after a timeout before sending it again. A lost response can occur after the destination has already processed the document.

How the related documents differ

Each message represents a different business event. Use shared references to connect the records while tracking each message’s outcome separately.

Implementation steps

  1. Choose the starting event and owner

    Decide which application acts when a buyer changes a previously issued order. Name the operational owner of the buyer order-change request and the team that resolves rejected or ambiguous messages.

  2. Keep record IDs connected

    Map original purchase order, change revision and affected line. Confirm qualifiers, code lists, units and date/time meaning against the agreed X12 version and partner guide. Preserve the source reference alongside any new destination identifier.

  3. Test failures before launch

    Run the failure cases in the mapping table against realistic buyer order-change request data. Check how the receiving system reports a rejection and how your team corrects it without creating a duplicate.

  4. Track every document to completion

    Record transport delivery and document validation separately from successful buyer order-change request processing. Give unresolved errors an owner and check the receiving system before approving retries.

Go-live checklist

  • An approved 860 sample and the agreed version and partner guide are available.
  • The mapping tests pass with realistic buyer order-change request data.
  • Each submitted document can be traced through delivery, validation and processing in the receiving system.
  • Your team knows how to investigate and recover a rejected or timed-out buyer order-change request without processing it twice.

Document structure

X12 860 Purchase Order Change Request (Buyer Initiated) at the element level

The X12 860 reference contains 55 segment entries and 162 data elements; 62 are marked mandatory in this reference. Use the version and partner guide agreed for your account to confirm required fields.

Segments
55
Data elements
162
Mandatory elements
62
Segments with elements marked mandatory in this reference
Segment Elements Mandatory
BCH 4 4
CUR 2 2
REF 3 1
PER 2 1
FOB 5 1
N9 2 1
N1 4 1
N2 1 1
N3 2 1
POC 13 1
Key identifiers in 860
  • Transaction Set Purpose Code
  • Purchase Order Type Code
  • Purchase Order Number
  • Date
  • Entity Identifier Code
  • Currency Code
  • Reference Identification Qualifier
  • Contact Function Code

Find your trading partner for X12 860

140 partners, 171 channels. Choose a channel to inspect its listed document reference and implementation context.

Catalog breakdown

Where X12 860 Purchase Order Change Request (Buyer Initiated) appears in this catalog

The largest groups of classified 860 catalog entries are in retail, apparel & footwear and grocery & food.

By industry

  • retail 50 channels
  • apparel & footwear 30 channels
  • grocery & food 25 channels
  • furniture & home 23 channels
  • building & hardware 12 channels
  • e-commerce & marketplaces 11 channels

By network

  • SPS Commerce 56 channels
  • TrueCommerce 16 channels
  • Rithum 7 channels
  • InterTrade 2 channels
  • OpenText 2 channels
  • CommerceHub 2 channels

FAQ

EDI 860 questions

What is an EDI 860?

EDI 860 is the PO change request, the X12 Purchase Order Change Request (Buyer Initiated) transaction set. Trading partners use it when a buyer changes a previously issued order. It carries the data for the buyer order-change request, and your system matches it on original purchase order, change revision and affected line.

Who sends an EDI 860 and who receives it?

The buyer sends the 860 to the supplier and references the original 850. The supplier accepts or contests the change with an 865 Purchase Order Change Acknowledgment. Your trading partner agreement confirms the direction and version for your account.

When is an EDI 860 sent?

A buyer needs to change quantities, pricing, dates, or line items on an open order, or cancel it outright, at any point in the order cycle including after partial shipment. Your partner guide sets any deadline or schedule for the document.

What are the key segments in an EDI 860?

Across 171 partner document references listed here, the business segments that appear most often include BCH (Beginning Segment for Purchase Order Change), POC (Line Item Change), CTT (Transaction Totals), REF (Reference Information), DTM (Date/Time Reference), PID (Product/Item Description). Each partner guide sets which segments and elements your account must send.

What is the difference between EDI 860 and EDI 850?

The 850 is the original purchase order. The 860 changes it after it has gone out: quantities, prices, dates or lines, or a cancellation.

What should I map for X12 860?

Start with original purchase order, change revision and affected line and the target buyer order-change request. Define duplicate detection, allowed updates and response correlation before mapping individual fields. Use the partner guide to check required fields and their formats.

How should I test 860 error handling?

Apply a quantity reduction to the existing order instead of creating another order. Test a cancellation arriving after allocation or shipment and route it to an exception owner. Also test a lost response after destination processing so that a retry cannot create an unintended duplicate or repeated adjustment.

Which partners list X12 860?

The directory on this page links 140 partner entries that list this message. Choose your partner and channel, then confirm which messages and versions your account requires.

Connect EDI to your business systems

See how Stacksync can fit your enterprise EDI workflow. Bring one partner guide and a sample exchange to plan the system mapping, exception handling and production rollout.