EDI 860 is the X12 purchase order change a buyer sends to revise an order already placed. Every change type code, all segments, an annotated sample 860 file, and how it differs from the 850, 855 and 865. AIMS360 applies the change to the live order with allocation following automatically, using EDI built into the ERP as a single feature rather than an outside provider. No document or kilocharacter fees.
An EDI 860 is the X12 transaction a buyer sends to change a purchase order it has already issued, without cancelling and reissuing it. This reference covers what an 860 is, every change type code, the segments, an annotated sample file, how the 860 relates to the 850, 855 and 865, and why the document that arrives after the order is the one most ERPs handle badly.
An EDI 860 is the Purchase Order Change Request, Buyer Initiated, transaction set in the ANSI ASC X12 standard. A buyer sends it to a supplier to change a purchase order that has already been transmitted, targeting specific lines rather than cancelling and reissuing the whole order.
Every X12 document carries a three-digit code: 850 is the purchase order, 856 is the advance ship notice, and 860 is the change to the order. The code appears in the file's ST segment, which is why an 860 always opens with ST*860.
The 860 exists because purchase orders are written before demand is known. A category sells faster than planned and the buyer wants more units. A style stalls and the buyer wants fewer. A distribution center reschedules and the ship window moves. A cost is renegotiated after the order was cut. Each of those is a change to an order that is already sitting in your book, and reissuing a fresh 850 for every one of them would destroy the audit trail on both sides.
What makes the 860 commercially dangerous is timing. The 850 arrives when nothing has happened yet. The 860 arrives when stock is allocated, a pick may be printed and a shipment may be half built. Applying it late means shipping the old quantity at the old price to the old date, which is a short pay, a compliance deduction, or both.
Trading partners and routing guides call the same file a PO change, a change order, a PO revision, a purchase order change request or simply "an 860." They all mean this transaction set. A change initiated by the seller rather than the buyer is the 865, covered below.
This is the part of the 860 that matters operationally. The header carries a transaction set purpose code that separates a revision from a cancellation, and each affected line carries its own change or response type code. Read together, they tell you exactly what moved.
| Code | Meaning | What it does to the order |
|---|---|---|
01 |
Cancellation | The entire purchase order is dead. Everything allocated to it has to be released. |
04 |
Change | A revision. The line-level codes below say what changed. |
05 |
Replace | Used by some partners to restate the order in full rather than send a delta. |
06 |
Confirmation | The buyer confirming acceptance of a change the seller proposed on an 865. |
These sit in the line item change loop and are the codes your system has to act on.
| Code | Meaning | What has to happen in the ERP |
|---|---|---|
AI |
Add item | A line that was not on the original order. Needs a live availability check before it is committed. |
DI |
Delete item | The line comes off entirely. Allocation must be released or the stock stays reserved for nothing. |
PC |
Price change | The unit price moves. If it does not reach the invoice, the invoice fails against the buyer's order. |
QI |
Quantity increase | Extra units are wanted. Commit against real availability, not against the number on the old order. |
QD |
Quantity decrease | Units come off. Release the difference back to sellable stock. |
CA |
Changes to line items | A general line change where the partner does not use a more specific code. |
NC |
No change | The line is restated unchanged so the whole order is visible. Do not double-apply it. |
Quantity and price get the attention, but the dates on an 860 cause more chargebacks. Each date qualifier is a different deadline, and any of them can move.
| Qualifier | Date | Why it matters |
|---|---|---|
010 |
Requested ship date | When the buyer wants it to leave. Drives allocation and the pick. |
037 |
Ship not before | Ship early and it is a compliance violation in its own right, even though the goods arrived. |
038 |
Ship no later than | The hard end of the window. |
001 |
Cancel date | Miss it and the order can be refused at the door with the freight already paid. |
002 |
Anticipated delivery | Arrival at the DC, which is not the same as the ship date once transit is counted. |
An 860 can also revise commercial terms that were set on the original order: allowances and charges such as co-operative advertising, defective allowance, discount and new store discount; terms of sale including the discount percentage, discount days and net days; freight terms; and the backorder rule. Treating an 860 as a quantity update alone is how allowances get missed and margin quietly disappears.
An 860 is a structured text file made of segments. Each starts with a two or three letter ID and holds data elements separated by a delimiter. The header identifies the order being changed, the detail loop repeats once per affected line, and the summary closes the file.
| Segment | Name | What it carries |
|---|---|---|
| ISA / GS | Interchange and group envelope | Sender and receiver IDs, control numbers and the standard version. The functional identifier for a purchase order change is PC. |
| ST | Transaction set header | Opens the change. ST01 is 860, ST02 is the control number. |
| BCH | Beginning segment for purchase order change | The most important segment in the file. Carries the transaction set purpose code, the purchase order type, the original PO number, the original PO date and the change date. This is how the change is matched to the order. |
| REF | Reference identification | Department number, the customer number the buyer assigned you, merchandise type, promotion or deal number. |
| PER | Administrative communications contact | Who to call, often pointing at the routing guide. |
| FOB | F.O.B. related instructions | Freight terms: collect, collect with freight credited back, or prepaid by the seller. |
| CSH | Sales requirements | The backorder rule: consignment, no backorder, or backorder if out of stock. |
| SAC | Service, promotion, allowance or charge | Allowances and charges with their percentages. Co-operative advertising, defective allowance, discount, free goods, new store discount. |
| ITD | Terms of sale | Terms basis date, discount percentage and days, net due date and net days, payment method. |
| DTM | Date/time reference | The revised dates, each with its own qualifier. See the date table above. |
| N9 / MTX | Reference identification and text | Free-form notes, often a pointer to vendor contract conditions. |
| N1 / N3 / N4 | Name, address, geographic location | Bill to, buying party and ship to, with the store or distribution center code. |
| POC | Line item change | The change itself. Carries the change type code, the quantity ordered before the change, the quantity to add or remove, the unit of measure, the unit price, and paired qualifier and value item identifiers. |
| CTP | Pricing information | Additional price points such as suggested retail and retail. |
| PID | Product / item description | Free-form product, colour and size descriptions for human readers. |
| CTT | Transaction totals | The number of line items, used as an integrity check. |
| SE | Transaction set trailer | Closes the change and counts the segments from ST through SE inclusive. |
Two practical notes. First, some partners carry the changed line in a PO1 baseline segment rather than POC, and a few specifications reference both, so confirm which one you will receive before you build a map. Second, segment and code requirements vary by trading partner: each retailer publishes its own 860 specification defining which segments are mandatory and which code values are accepted. AIMS360 configures the map per retailer.
A quantity increase of 50 units on one line of an existing order, with a revised ship window and a co-operative advertising allowance. Simplified for readability; identifiers are placeholders.
ISA*00* *00* *01*BUYERID *12*VENDORID *260805*0930*^*00403*000000123*0*P*>~ GS*PC*BUYERID*VENDORID*20260805*0930*0123*X*004030VICS~ ST*860*0001~ BCH*04*SA*4412887***20260612*****20260805~ <- 04 = change, PO 4412887, original PO date, change date REF*DP*5~ <- department number REF*MR*D~ <- merchandise type, D = domestic FOB*CF~ <- collect, freight credited back to the buyer CSH*N~ <- no backorder SAC*A*B720****1*20~ <- allowance: co-op advertising, 20% of item list cost ITD**15*****30~ <- terms basis receipt date, net 30 DTM*010*20260901~ <- revised requested ship date DTM*038*20260915~ <- revised ship no later than DTM*001*20260930~ <- revised cancel date N1*ST*DISTRIBUTION CENTER*93*002~ <- ship to, buyer location code N3*2201 EXAMPLE ROAD~ N4*ANYTOWN*IN*46952*USA~ POC**QI*800*50*EA*4.65**IN*0005398318*UP*025725210114*VN*2886F2*IT*0308-86280-0065~ <- QI = quantity increase: 800 on order, add 50, each, at 4.65 <- then buyer item no., UPC, vendor item no., buyer style no. PID*F*08***YOUTH BASEBALL PANTS~ PID*F*75***BLACK/WHITE~ PID*F*91***XL~ CTT*1~ <- one changed line SE*20*0001~ <- 20 segments from ST through SE inclusive GE*1*0123~ IEA*1*000000123~
Illustrative rather than a specification. Envelope characters, control numbers, ID qualifiers and code values are set by each trading partner's published 860 guideline. Note the repetition separator, shown here as ^, is often a non-printing character. Read the routing guide before you build a map, or let the AIMS360 EDI team handle it.
Four transactions sit in the order-change conversation and they are routinely confused. The difference is who is talking and what they are asserting.
| Document | What it says | Direction | When |
|---|---|---|---|
| 850 Purchase Order | Send me this many of that item. | Buyer to supplier | The original order |
| 855 PO Acknowledgment | Here is what I can accept, change or reject on your order. | Supplier to buyer | After the 850 |
| 860 PO Change Request | Change what I already ordered. | Buyer to supplier | Any time after the 850 |
| 865 PO Change Ack / Request | I accept, reject or counter that change. Or: here is a change I need. | Supplier to buyer | After the 860, or seller initiated |
The pairing is the thing to remember. The 850 is answered by the 855. The 860 is answered by the 865 where the partner requires it, and by a 997 functional acknowledgment in every case. Silence on an 860 is rarely an acceptable answer, because the buyer has no way to know whether you saw it.
From there the order flows on through the 856 advance ship notice with GS1-128 carton labels, the 810 invoice and the 820 payment. Every one of those has to reflect the revised order rather than the original one, which is the whole problem the 860 creates.
Receiving an 860 is easy. Any translator can parse one. The difficulty is that an 860 is not information, it is an instruction to mutate a record that other processes are already acting on. That is where the architecture shows.
Add per-document fees and a heavy change period costs more exactly when margin is thinnest.
No file to reconcile, no second system, and no per-document charge.
A useful question when evaluating any ERP: ask what happens to allocated stock when a quantity decrease arrives. If the answer involves a person and a spreadsheet, every 860 is a small margin leak, and a season of them is a large one.
The 860 is common wherever buying happens well ahead of the season and demand is re-forecast before goods ship. Sporting goods, department stores, off-price and mass retail all use it heavily. AIMS360 supports the 860 across its retailer EDI network, with the map configured to each partner's specification.
If a retailer you sell to is not listed, ask. New retailer maps are added regularly, and the 860 is part of the standard document set rather than an add-on.
AIMS360 reads the beginning segment and matches the change to the live order on the buyer's purchase order number and original PO date. If the purpose code says cancellation rather than change, the whole order is handled as a cancellation.
Changed lines are matched using the identifiers the retailer sends: their item number, the UPC or GTIN, your vendor item number, their style number, and their size and colour codes. Because those are cross-referenced against your styles when the connection is set up, matching does not depend on a person recognising a SKU.
Increases, decreases, added lines, deleted lines and price changes are written to the live order. Lines marked no change are restated and skipped rather than double-applied. The revised requested ship, ship-not-before, ship-no-later and cancel dates replace the originals.
Quantity removed is released back to sellable stock so it can serve other demand. Quantity added is committed against what is available now, not against the number on the old order. The revised ship window drives the pick, so the warehouse is never working from a stale ticket.
Revised allowances, discounts, freight terms and payment terms are captured on the order and carried onto the invoice, so the 810 matches the buyer's revised order and clears without a short pay.
AIMS360 sends the 997 functional acknowledgment, and the 865 purchase order change acknowledgment where the partner requires one. Failed or unacknowledged documents are flagged, and chargebacks are tracked by reason code so a repeating problem is visible rather than buried in a remittance.
The questions consumer brands ask most often about purchase order changes.
EDI 860 is the Purchase Order Change Request, Buyer Initiated, transaction set in the ANSI ASC X12 standard. A buyer sends it to a supplier to change a purchase order that has already been transmitted, targeting specific lines rather than cancelling and reissuing the entire order. It ties back to the original 850 through the purchase order number and date.
Quantities up or down, unit prices, added lines, deleted lines, and the dates on the order including the requested ship date, ship not before, ship no later than, anticipated delivery and cancel date. A header purpose code can also cancel the whole order. Beyond that, an 860 can revise allowances and charges, terms of sale, freight terms and the backorder rule, which is why treating it as a quantity update alone causes margin to leak.
Direction. The 860 is buyer initiated: the retailer is asking to change an order. The 865 is the purchase order change acknowledgment or request, seller initiated: it is how you accept, reject or counter the buyer's change, and it is also how you propose a change of your own. Where a partner requires an 865, staying silent on an 860 is not an acceptable response.
The 850 creates the order. The 860 changes an order that already exists. Both come from the buyer, but they arrive at very different moments: the 850 lands before anything has happened, while the 860 can land after stock is allocated and a pick is printed. That timing is why the 860 is the harder of the two to handle correctly.
At the line: AI adds an item, DI deletes an item, PC is a price change, QI is a quantity increase, QD is a quantity decrease, CA is a general line change, and NC restates a line with no change so the full order is visible. At the header, the transaction set purpose code separates a change from a cancellation, most commonly 04 for a change and 01 for a cancellation.
BCH is the beginning segment for a purchase order change, and it is the most important segment in the file. It carries the transaction set purpose code that says whether this is a change or a cancellation, the purchase order type, the buyer's original purchase order number, the original purchase order date and the date of the change. Without it there is nothing to match the change against.
POC is the line item change segment. It carries the change type code, the quantity that was on order before the change, the quantity to be added or removed, the unit of measure, the unit price, and then paired qualifier and value item identifiers: the buyer's item number, the UPC or EAN, your vendor item number, the buyer's style number, and their size and colour codes. Some partners carry the changed line in a PO1 baseline segment instead, so confirm which one you will receive.
4010 and 5010 are the most common, and 4030 in the VICS retail subset appears in a number of retail programs. The segment structure is stable across versions. What differs between partners is which segments and code values are mandatory, and that is handled per retailer in the map rather than by the version number.
Commercially, not always. An 860 is a request, and where the partner supports an 865 you can accept it in full, accept it with changes, or reject it. In practice most retail programs treat the change as binding unless you push back quickly, and the window for pushing back is short. What you cannot do is ignore it, because the invoice will be measured against the revised order rather than the original one.
It happens often, and it is a commercial conversation rather than a technical one. If a quantity decrease or a cancellation lands after the shipment left, the change cannot be applied to that shipment and the buyer is notified through the acknowledgment. What matters is that the system knows the shipment was already committed, rather than silently reducing an order that is physically on a truck. Keeping the order, allocation and shipment in one platform is what makes that distinction visible.
No. AIMS360 EDI is built in-house and included, so there is no per-document, per-kilocharacter or VAN fee. That matters more on the 860 than on any other transaction, because change orders arrive in bursts at the end of a season and a metered plan turns a bad forecast into a bigger bill. See pricing.
Built in. AIMS360 develops and owns its EDI engine and runs it inside the consumer brands ERP. It is not a resold or white-labeled third-party service such as SPS Commerce, TrueCommerce, DiCentral or Cleo. On the 860 specifically this is the difference between a change being applied to a live order with allocation following automatically, and a change being handed over as a file for someone to key in.
The 860 is common across sporting goods, department stores, off-price and mass retail, wherever buying happens well ahead of the season and demand is re-forecast before goods ship. AIMS360 supports it across its retailer EDI network, including Dunham's Sports, PGA TOUR Superstore, Buckle, Dick's Sporting Goods and the TJX banners. The full list is on the EDI retailers page.
A 997 functional acknowledgment in every case, confirming the file arrived and parsed. Where the trading partner requires it, an 865 purchase order change acknowledgment as well, stating whether you accept the change, accept it with modifications, or reject it. Confirm which the partner expects during setup, because the outbound 860 specification usually documents only what they send, not what they want back.
AIMS360 applies the 860 to the live order, adjusts allocation, moves the ship window and rebuilds the ASN and invoice from the revised order. Built-in EDI, no middleware, no per-document fees.
By Shahrooz Kohan, CEO, AIMS360. Reviewed by the AIMS360 EDI team. Last updated August 2026. Talk to our team.
Transaction details on this page describe general ANSI ASC X12 conventions and are for orientation only. Segment usage, code values and required documents vary by trading partner. Always work from the current specification and routing guide supplied by your retailer. Third-party company names and trademarks are the property of their respective owners.
