An EDI 860 is the purchase order change a buyer sends after the original 850 has already gone out. It can raise a quantity, move a date, change a price, add a line, delete a line or cancel the order outright. This page explains the BCH header, the POC change loop, all 31 POC02 change codes, and how to flatten an 860 into Excel rows you can compare against the order it amends. It also covers the revised orders that arrive as a PDF instead.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
An 850 tells you what to do. An 860 tells you what to do differently, and it only makes sense next to the order it amends. Read it on its own and you can reach a confident, wrong answer.
BCH01 decides whether the POC lines are a short list of edits or a full restatement of the order. Purpose code 04 is a change, so only the listed lines moved. Purpose code 05 is a replace, so the listed lines are the whole order now and anything absent is gone. Parse a replace as a delta and you keep lines the buyer just removed.
POC03 carries the quantity ordered after the change, not the amount added or removed. Adding it to the quantity on the 850 is the most common single arithmetic error in the whole document, and it produces an order that is exactly twice as large as anyone asked for.
Two 860s against the same PO can land in either sequence, and nothing in the transport guarantees which one you process first. BCH05 is the change order sequence number and it is the only thing that tells you which amendment is newer. Process by arrival time and an old change quietly overwrites a new one.
The trading partners on a VAN send X12. Everyone else emails a revised PDF with the words REVISION 2 in the header and a changed quantity somewhere in the middle. That stream carries the same commercial risk and almost nobody has a report on it.
PurchaseOrders is a document extraction tool. It reads purchase orders and revised purchase orders that arrive as PDFs, scans or email attachments and returns the header plus every line as clean columns. It is not an EDI translator: it does not connect to a VAN, it does not parse X12, and it does not generate an 860 or an 865. If your large partners send true 860 files, keep the translator that handles them. This page exists because most buying and selling desks run both channels, and the second one is where revisions go unnoticed until the wrong quantity ships.
PO number, revision reference, change date, requested dates, then one row per item with quantity, unit of measure, price and part number. Line those up with what your translator writes and both channels land in one variance report.
The revision or amendment reference printed on a PDF becomes a column instead of something a person reads off the page, so you can sort revisions per PO the way BCH05 lets you sort X12 ones.
No template to build per partner and no coordinate mapping. A revised order that looks nothing like the last one still returns the same fields, which is the practical difference from a per partner EDI map.
Every line comes back separately with its own quantity, price and part number, which is the level a change comparison has to happen at. A header only capture cannot tell you which line moved.
Upload a folder of revisions and get one sheet, so a month of uninspected PDF amendments becomes a report you can actually reconcile.
Take the output in whatever shape the next step wants, including a JSON payload if the comparison runs in code rather than in a spreadsheet.
The BCH segment is the beginning segment for a purchase order change, and two of its elements decide how the rest of the document should be interpreted. Read them first, because getting either one wrong makes every row underneath it wrong in the same direction.
| Element | What it holds | Why it matters |
|---|---|---|
| BCH01 | Transaction set purpose code | Decides whether this is a delta or a restatement. See the table below. |
| BCH02 | Purchase order type code | The same code set the original 850 used, for example SA for a stand alone order or BK for a blanket order. |
| BCH03 | Purchase order number | The order being amended. This is your join key back to the 850. |
| BCH04 | Release number | Populated when the order is a release against a blanket, which is where a change gets ambiguous if you ignore it. |
| BCH05 | Change order sequence number | Which amendment this is. The only reliable ordering signal in the document. |
| BCH06 | Date | The date of the change, not the date of the original order. |
| BCH10 | Date | Commonly the original purchase order date, so you can confirm you matched the right order. |
BCH01, BCH02, BCH03 and BCH06 are mandatory in 004010. Everything else is optional, which in practice means your trading partner guide decides what you actually receive.
This is the element that separates a working 860 parser from a broken one. The same file layout means completely different things depending on one two character code at the very front.
| Code | Meaning | How to process the POC lines |
|---|---|---|
| 04 | Change | Only the listed lines changed. Lines absent from the 860 are untouched on the original order. |
| 05 | Replace | The listed lines are the order now. A line absent from the 860 has been removed. Do not merge, overwrite. |
| 01 | Cancellation | The whole order is cancelled. Line detail may be absent entirely and its absence means nothing. |
| 00 | Original | Rare on an 860 and usually a partner sending a first transmission down the change channel by mistake. |
| 06 | Confirmation | A confirming copy of a change already agreed by phone or email. Applying it twice is the risk. |
| 07 | Duplicate | A resend of something you have already seen. Deduplicate on BCH03 plus BCH05 rather than reprocessing. |
| 22 | Information copy | For visibility only. It is not an instruction and should not update anything. |
The practical rule is that 04 merges and 05 overwrites. If your partner guide does not state which they send, ask before you go live, because the failure mode is silent: a replace processed as a change leaves deleted lines sitting on your order and they will ship.
The detail loop of an 860 is POC, not PO1. That single difference is why an 850 parser pointed at an 860 returns an empty sheet and no error. POC carries an assigned line identifier, the change type, the new quantity, the unit of measure, the new price and a run of product identifier pairs.
| Element | Name | What to put in the column |
|---|---|---|
| POC01 | Assigned identification | The line number. Match it to the PO101 on the original 850 to know which line moved. |
| POC02 | Change or response type code | Mandatory. What kind of change this is. Translate it, do not store the raw code. |
| POC03 | Quantity ordered | The quantity AFTER the change. Not a delta. |
| POC04 | Quantity left to receive | What still has to arrive. Useful when part of the line already shipped. |
| POC05 | Composite unit of measure | A composite, so it can carry more than one sub element. Split it on the component separator. |
| POC06 | Unit price | The price after the change. |
| POC08 onward | Product ID qualifier and product ID, repeating | Pairs. BP buyer part, VP vendor part, UP consumer package code, UK GTIN 14. Keep the qualifier or the number is meaningless. |
The identifier pairs repeat many times through POC27 in 004010. Deciding in advance which qualifier goes in which spreadsheet column is the difference between a usable sheet and twenty near empty columns.
POC02 is X12 element 670. It is mandatory on every POC segment and it is the field that tells you what the buyer actually did to the line. These are the complete 004010 code values.
| Code | Meaning |
|---|---|
| AI | Add additional item |
| CA | Changes to line items |
| DI | Delete item |
| QC | Quantity change |
| QI | Quantity increase |
| QD | Quantity decrease |
| PC | Price change |
| PQ | Unit price and quantity change |
| PR | Unit price and reschedule change |
| RS | Reschedule |
| RQ | Reschedule and quantity change |
| MU | Multiple, for unit price quantity reschedule change |
| NC | Concurrent item, no change |
| CT | Change of dates |
| CB | Change of date terms |
| CC | Changes to terms |
| CE | Changes to item level allowance or charges |
| CG | Changes to total level allowance or charges |
| CF | Cancel previously transmitted purchase order |
| RC | Reject item change |
| RE | Replacement item |
| RM | Replacement item with modifications |
| RA | Replace mode of shipment |
| RB | Replace all dates |
| RZ | Replace all values |
| TI | Transfer item |
| AA | Packing configuration |
| CH | Change to original confirmation of original announcement |
| CI | Change to confirmation of revised announcement |
| OA | Original confirmation of revised announcement |
| OC | Original confirmation of original announcement |
Three of these deserve a note. NC means concurrent item, no change: the line is present purely for context and counting it as a change inflates every report you build. CF cancels the entire order from a line level segment, which is easy to miss if you are looking at BCH01 alone. And QC, QI and QD all describe a quantity move, so a report that filters on QC only will miss most of them.
The layout that works downstream is one row per POC segment, with the BCH header values repeated on every row. That gives you a sheet you can join to the original order on purchase order number plus line number.
| Column | Source |
|---|---|
| PO number | BCH03 |
| Change sequence | BCH05 |
| Change date | BCH06 |
| Purpose | BCH01, translated |
| Line number | POC01 |
| Change type | POC02, translated |
| New quantity | POC03 |
| Unit of measure | POC05, first sub element |
| New price | POC06 |
| Buyer part | The product ID whose qualifier is BP |
| Vendor part | The product ID whose qualifier is VP |
Then check CTT01 against your distinct POC01 values. CTT is the transaction totals segment and CTT01 counts the line items in the document, so if your row count and CTT01 disagree you dropped or duplicated something. On an 860 they should match exactly, which makes the 860 easier to verify than the 855 where a split line legitimately produces more rows than CTT01.
This is where a change gets lost between two companies that both think they did their part. Three different documents can come back and they mean three different things.
| Document | What it confirms | What it does not confirm |
|---|---|---|
| 997 functional acknowledgment | The file was syntactically valid and was received | That anyone read the change or agreed to it |
| 824 application advice | The receiving application accepted or rejected the content | That the change is commercially agreed |
| 865 purchase order change acknowledgment | The seller accepts, rejects or counters the change line by line | Nothing, this is the real business answer |
Plenty of trading partner agreements never require an 865 at all. That means the absence of a response to an 860 tells you nothing, which is an uncomfortable place to be when the change was a cancellation. If the change matters, the control is your own report of open changes with no matching 865, not an assumption that silence means yes. Our reference on EDI 997 error codes covers why an AK901 of A is a syntax pass rather than a business confirmation, which is the same trap one layer down.
Very few buying or selling desks run one channel. The accounts on a VAN send an 860 and everyone else emails a revised PDF, and the revised PDFs are where the manual comparison actually happens. The useful move is to make the two channels write the same columns: purchase order number, revision reference, change date, then one row per item with quantity, unit of measure, price and part number. Agree that layout once and both streams land in the same variance report, the same import file and the same open change list. That is the half of the problem PurchaseOrders solves, and it is deliberately the half an EDI translator does not. For the order that started the exchange see the EDI 850 to Excel converter, for the acknowledgment that comes back see the EDI 855 to Excel converter, and for the process side of amendments see how to amend a purchase order. If you need to go the other way and turn a document into data your EDI flow can send, see PDF purchase order to EDI.
Which one is right depends on whether this is one change you need to read today or a channel you have to reconcile every week.
| Route | Best for | What it takes | Watch out for |
|---|---|---|---|
| EDI translator export | Ongoing 860 volume | Your existing translator writing a CSV or a database drop | Many translators map the 860 with the same profile as the 850, which looks for PO1 and returns nothing when the detail loop is POC |
| Online EDI viewer | A single change file you need to read today | Pasting or uploading the file into a web tool | You are sending live partner pricing and order detail to a third party site |
| Parse it yourself | A few predictable partners | Split on the terminator and the element separator, read BCH01, then walk the POC loop | The BCH01 branch between change and replace is the part that has to be right, not the splitting |
| Excel text to columns | Almost nothing | Data then Text to Columns using the element separator | Produces one wide row per segment rather than one row per line, so the POC loop never becomes rows |
| PurchaseOrders | Revisions that arrive as PDFs rather than X12 | Uploading the revised order document | It reads documents, not X12, so it is the other channel rather than a replacement for the translator |
This is the path for the changes that do not arrive as X12, which for most desks is the majority of the partner list.
Drop in the PDF, the scan or the email attachment. Multi page revisions and a batch of mixed partners are both fine.
Tip: Start with the partner who revises orders most often, because that is where the variance is.
PO number, revision reference, dates and every line come back together, so you can spot a changed quantity or price before it reaches production or the warehouse.
Tip: Compare the line count to the original order the same way CTT01 checks an 860.
Take the columns in whatever shape the variance report wants, matching the layout your EDI drop already writes so both channels merge cleanly.
Tip: Keep a revision column so two amendments to one PO never collapse into one row.
Split the file on its segment terminator and each segment on its element separator, read BCH01 to learn whether the document is a change or a replace, then walk the POC loop writing one row per POC segment with the BCH header repeated on every row. Translate the BCH01 and POC02 codes as you go, then check your distinct line count against CTT01.
An EDI 860 is the purchase order change request a buyer sends after the original EDI 850 has already been transmitted. It amends the existing order rather than replacing the relationship, and it can change quantities, prices and dates, add or delete lines, or cancel the order entirely. The seller answers it with an 865 when the trading partner agreement calls for one.
POC02 is the change or response type code, X12 element 670, and it is mandatory on every POC segment. It says what happened to that line: QI for a quantity increase, QD for a decrease, PC for a price change, RS for a reschedule, AI to add an item, DI to delete one, and NC for a line listed with no change at all. There are 31 values in 004010.
An 850 creates a purchase order and an 860 amends one that already exists. The practical difference for anyone parsing them is the detail loop: an 850 carries its lines in PO1 segments while an 860 carries them in POC segments, so a parser built for one returns an empty result on the other without raising any error.
It is the new total quantity ordered for that line after the change, not the amount being added or removed. Adding POC03 to the quantity already on the order is the most common arithmetic mistake made with this document, and it produces an order roughly twice the size the buyer asked for.
Purpose code 05 is Replace, which means the POC lines in the document are the complete order as it now stands rather than a list of edits. Any line missing from the 860 has been removed. Purpose code 04 is Change and works the opposite way: only the listed lines moved and everything absent is untouched.
The 860 is the buyer asking for a change and the 865 is the seller answering it. An 865 accepts, rejects or counters the requested change line by line, in much the same way an 855 answers an 850. Many trading partner agreements never require an 865, so an unanswered 860 does not mean the change was accepted.
Use BCH05, the change order sequence number, rather than the time the file arrived. Two amendments against the same purchase order can be delivered in either order and nothing in the transport guarantees sequence, so processing by arrival time lets an older change overwrite a newer one.
No. PurchaseOrders reads purchase orders and revised purchase orders that arrive as PDFs, scans or email attachments and returns the header and line items as columns. True X12 860 files still need an EDI translator. The two are complementary, because most buying desks receive X12 from large partners and documents from everyone else.
The general EDI to spreadsheet guide, delimiters and envelopes.
The order that starts the exchange, flattened to rows.
The acknowledgment, with all 26 ACK01 status codes.
The reverse direction, document to EDI ready data.
Turn a PO or revision into a plain spreadsheet.
Delimited output for building an import file.
Line level accuracy, one row per item.
The same fields as JSON for a scripted flow.
Clear a revision backlog in one pass.
Built for high order volume buying desks.
