An EDI 855 is the acknowledgment your supplier sends back after you transmit an 850, and it is where you find out what is really going to ship. It answers line by line: accepted, quantity changed, price changed, backordered or rejected. This page explains the BAK header, all twenty six ACK01 status codes, and how to flatten an 855 into Excel rows you can compare against the order you sent. It also covers the order confirmations 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 has one answer per line. An 855 has a status, a quantity that the status applies to, and sometimes several of both on the same line. That is where the reading goes wrong.
ACK01 says IQ, or IB, or R4. None of it reads as English, and the difference between IP and IQ is the difference between a price change and a quantity change. A spreadsheet full of raw codes is barely more useful than the file it came from.
Sixty units shipping and forty backordered is one PO1 with two ACK segments. A parser that assumes one status per line records the sixty and silently loses the forty, so the order looks short for reasons nobody can trace.
BAK02 decides whether line detail is present at all. AK means no ACK segments and the whole order confirmed. AE means only exceptions are listed, so a missing line is an accepted line. Read the lines without the header and you can reach the opposite conclusion.
The accounts on a VAN send X12. The rest email a PDF order confirmation that lands in an inbox and gets checked by eye, if at all. The price and quantity changes in that stream are just as real and nobody is reporting on them.
PurchaseOrders is a document extraction tool. It reads purchase orders and supplier order confirmations 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 855 or a 997. If your large suppliers send true 855 files, keep the translator that handles them. This page exists because most buying desks run both channels, and the second one is where the price and quantity changes go unnoticed.
PO number, supplier, confirmation date, promised ship date, 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 sheet.
No template to build per supplier and no coordinate mapping. A confirmation that looks nothing like the last one still returns the same fields, which is the practical difference from a per partner EDI map.
An 855 echoes buyer part and vendor part as qualifier and value pairs. Confirmations on paper carry the same two numbers in different columns, and both survive the extraction so the item match still works.
Take a spreadsheet for the variance review, delimited output to build an import file, or JSON over the API to feed the same downstream job your EDI drop already writes to.
Every extracted document reports its line count, so you can run the same sanity check a CTT01 segment gives you inside an 855.
Long confirmations that run over several pages stay as one document, and a folder of mixed suppliers can be processed in a single pass.
The 855 mirrors the order you sent, then adds a status layer on top of it. The PO1 segments echo your lines back, and an ACK segment underneath each one says what the supplier is actually going to do about that line. Read the two together or the file tells you nothing.
| Segment | What it carries | Spreadsheet column it becomes |
|---|---|---|
| ST | Transaction set header. ST01 is 855 and ST02 is the control number you quote when a partner asks which acknowledgment you mean. | Usually dropped, but keep ST02 for traceability |
| BAK | The acknowledgment header. BAK01 purpose, BAK02 acknowledgment type, BAK03 the buyers original PO number, BAK04 the PO date, BAK08 the sellers own order number and BAK09 the date the acknowledgment was created. | PO number, order date, acknowledgment type, supplier order number |
| REF | Qualified reference numbers such as a contract, department or vendor order reference. | One column per qualifier you care about |
| PER | Contact details for the person or desk at the supplier who handled the order. | Supplier contact name, phone, email |
| DTM | Dates by qualifier, most usefully 017 estimated delivery, 067 current schedule ship and 002 delivery requested. | Promised ship date, promised delivery date |
| N1 loop | Parties keyed by N101: SE selling party, ST ship to, BY buying party, VN vendor. N3 and N4 carry the address. | Supplier name, ship to, bill to |
| PO1 | One per acknowledged item, echoing the line the buyer ordered: quantity, unit of measure, price and the qualifier and value part number pairs. | One spreadsheet row per line item |
| ACK | The status of the PO1 above it. ACK01 is the line item status code, ACK02 the quantity that status applies to, ACK03 the unit of measure and ACK04 a date qualifier with ACK05 the date. | Status, status quantity, promised date |
| CTT | CTT01 counts the PO1 segments in the transaction. | Not a column. Use it to check your parse |
Two elements do more work than the rest. BAK03 is the buyers purchase order number, which is what you join the acknowledgment back to your own order on. BAK09 is the date the acknowledgment was created, and it is not the same as BAK04, which is the date of the original order. Teams that report on supplier response time and use BAK04 by mistake end up measuring nothing.
BAK02 sets the shape of everything below it. Before you look at a single line, this code tells you whether to expect ACK segments at all, and whether the file lists every line or only the exceptions. There are fifteen codes in X12 element 587.
| BAK02 | Meaning | What it tells you before you read a single line |
|---|---|---|
| AC | Acknowledge with detail and change | Something moved. Expect ACK segments and expect at least one of them to differ from what you ordered. |
| AD | Acknowledge with detail, no change | Confirmed as ordered, with the lines echoed back so you can prove it. |
| AE | Acknowledge with exception detail only | Only the problem lines are listed. Silence on a line means it was accepted as ordered. |
| AH | Acknowledge, hold status | The order is parked at the supplier, not confirmed and not rejected. |
| AK | Acknowledge, no detail or change | A receipt for the whole order with no ACK segments at all. |
| AP | Acknowledge, product replenishment | Used in vendor managed replenishment programs. |
| AT | Accepted | A plain acceptance. Common in narrow trading partner guides that trim the code list. |
| NA | No acknowledgment needed | Rare inbound. Usually seen in a guide describing what the partner will not send. |
| RD | Reject with detail | Rejected, with the lines listed so you can see which items caused it. |
| RF | Reject with exception detail only | Rejected, listing only the offending lines. |
| RJ | Rejected, no detail | The whole order is refused and the 855 will not tell you why. Pick up the phone. |
| RN | Rejected, not as agreed | Refused on terms, typically price or contract, rather than on stock. |
| RO | Rejected with counter offer | A negotiation, not a failure. Someone has to act on it. |
| RV | Rejected, violates industry practices | Rare, and usually a sign the order itself was built wrong. |
| ZZ | Mutually defined | Meaningless without the trading partner guide that defines it. |
The code that catches people out is AK, acknowledge with no detail or change. An AK acknowledgment is valid, complete and carries no ACK segments whatsoever. A parser that looks for line status and finds none tends to report the acknowledgment as empty or broken, when the supplier has actually confirmed the whole order as ordered. AE and RF cause the mirror image problem: they list only the exception lines, so any line missing from the file is a line that was accepted. Absence means yes in one code and unknown in another, which is why BAK02 has to be read first.
ACK01 is X12 element 668, the line item status code. It is the field that decides whether your inventory plan still holds. Twenty six codes are defined, and they fall into four groups worth treating differently in a spreadsheet.
| ACK01 | Meaning | Group |
|---|---|---|
| IA | Item accepted | Accepted |
| IC | Item accepted, changes made | Accepted with change |
| IQ | Item accepted, quantity changed | Accepted with change |
| IP | Item accepted, price changed | Accepted with change |
| IS | Item accepted, substitution made | Accepted with change |
| IE | Item accepted, price pending | Accepted with change |
| DR | Item accepted, date rescheduled | Accepted with change |
| SP | Item accepted, schedule date pending | Accepted with change |
| BP | Item accepted, partial shipment, balance backordered | Split |
| AC | Item accepted and shipped | Accepted |
| AR | Item accepted and released for shipment | Accepted |
| AA | Item accepted, order forwarded to alternate supplier location | Accepted |
| IB | Item backordered | Delayed |
| IH | Item on hold | Delayed |
| IF | Item on hold, incomplete description | Delayed |
| IW | Item on hold, waiver required | Delayed |
| ID | Item deleted | Not coming |
| IR | Item rejected | Not coming |
| R1 | Item rejected, not a contract item | Not coming |
| R2 | Item rejected, invalid item product number | Not coming |
| R3 | Item rejected, invalid unit of issue | Not coming |
| R4 | Item rejected, contract item not available | Not coming |
| R5 | Item rejected, reorder as a just in time order | Not coming |
| R6 | Item rejected, reorder as an extended delivery order | Not coming |
| R7 | Item rejected, reorder as a drop shipment | Not coming |
| R8 | Item rejected, reorder as a surge order | Not coming |
The practical grouping matters more than the individual codes. Anything in the accepted group needs no action. The accepted with change group is where margin quietly leaks, because IP and IQ mean the price or quantity you agreed is not the price or quantity you are getting, and nobody is going to call you about it. The delayed group affects promise dates to your own customers. The not coming group needs a new source today. If you build one column in your sheet, build that one.
A single ordered line can carry more than one ACK segment. If you order 100 units and the supplier ships 60 now and backorders 40, a correct 855 has one PO1 with two ACK segments beneath it: one with ACK01 of BP or IA for 60, and one with IB for 40. This is the single most common way an 855 parse goes wrong. A converter written on the assumption of one status per line reads the first ACK, records 60 units accepted, and silently drops the backordered 40. The order looks short and nobody can explain why. When you flatten an 855, write one row per ACK segment rather than one row per PO1, and carry the line number down so the rows still group.
The same rule protects your totals. CTT01 counts PO1 segments, not ACK segments, so on a file with split lines your row count will legitimately exceed CTT01. Compare CTT01 to your distinct line numbers, not to your row count.
The whole reason to get an 855 into a spreadsheet is the comparison. Put the ordered quantity and price beside the acknowledged quantity and price, keyed on the PO number from BAK03 and the line number, and three columns of differences fall out: quantity variance, price variance and date variance. Those three are the entire commercial content of the document. Everything else is envelope.
Worth knowing before you build the report: an 855 is not proof of anything legally settled, and a supplier that acknowledges with changes has, in contract terms, made a counter offer rather than accepted your order. Whether a purchase order is legally binding covers where US law lands on that, and the purchase order acknowledgment process covers what to do with the exceptions once you can see them.
Most buying teams do not get an 855 from every supplier. The large accounts on a VAN send X12. Everyone else emails a PDF order confirmation, and that stream gets read by eye and keyed by hand, or more often not checked at all. Those are the same three variances hiding in an inbox. Pointing both channels at one column layout is what makes the comparison complete. The purchase order PDF to Excel converter and the CSV export produce that layout directly, line item extraction is the part that has to be right for a line level comparison, and a backlog of confirmations clears in one pass with bulk purchase order upload. Buying desks running high order volume usually start at purchase order extraction for wholesale distribution.
The 855 is the second document in a four step exchange. The EDI 850 purchase order is what starts it and the 850 to Excel page covers reading one. Before the 855 arrives you should already have had a 997 functional acknowledgment, which is a syntax receipt rather than a business answer and is the first place to look when no 855 turns up at all. The EDI 856 advance ship notice follows when the goods actually move, and cXML vs EDI compares the two formats large buyers run. For the opposite direction, turning 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 file 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 855 volume | Your existing translator writing a CSV or a database drop | Most translators flatten one row per line and quietly collapse split ACK segments, so check a partial shipment before you trust the totals |
| Online EDI viewer | A single file you need to read today | Pasting or uploading the file into a web tool | You are sending live supplier pricing and order detail to a third party site |
| Parse it yourself | A few predictable suppliers | Split on the terminator and the element separator, walk the PO1 loop, then walk the ACK segments under each line | The ACK loop and the code lookups are the fiddly part, 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 a table, and cannot pair an ACK segment with the PO1 above it |
| Extract from the document | Confirmations that arrive as PDF or email | Uploading the confirmation and exporting the columns | Covers the non EDI channel only, which is exactly the gap it is meant to fill |
This is the path for the confirmations that do not arrive as X12, which for most buying desks is the majority of the supplier list.
Drop in the PDF, the scan or the email attachment. Multi page confirmations and a batch of mixed suppliers are both fine.
Tip: Start with two or three confirmations from the supplier who changes prices most often.
PO number, supplier, promised dates and every confirmed line come back together, so you can spot a changed quantity or price before it reaches your plan.
Tip: Compare the line count to the order you sent, the same way CTT01 checks an 855.
Take the columns in whatever shape the variance report wants, matching the layout your EDI drop already writes so both channels merge cleanly.
Tip: Agree the column layout once, then both confirmation channels can share it.
Split the file on its segment terminator, split each segment on its element separator, then walk the PO1 loop writing one row per ACK segment rather than one row per line, repeating the BAK header values on every row. Translate the BAK02 and ACK01 codes as you go. Check your distinct line count against CTT01.
An EDI 855 is the purchase order acknowledgment a supplier sends back after receiving an EDI 850. It confirms, changes or rejects the order line by line, telling the buyer what will actually ship, at what quantity and price, and when. It is the first document in the exchange that carries a commercial answer rather than a receipt.
ACK01 is the line item status code, X12 element 668. It says what the seller is doing with that line: IA accepted, IC accepted with changes, IQ quantity changed, IP price changed, IB backordered, ID deleted and IR rejected are the ones you see most. Twenty six values are defined in total.
The 850 is the purchase order the buyer sends. The 855 is the acknowledgment the supplier sends back to confirm, change or reject it line by line. The 850 states intent, the 855 states what will actually happen, and the difference between the two is the variance a buying desk needs to see.
The buyers purchase order number is in BAK03, the third element of the BAK segment. BAK01 before it is the transaction set purpose code and BAK02 is the acknowledgment type. BAK03 is what you join the acknowledgment back to your original order on.
Almost always because BAK02 is AK, acknowledge with no detail or change. That is a valid complete acknowledgment of the whole order exactly as it was sent, and it carries no line detail by design. Check BAK02 before treating a detail free 855 as a broken file.
Yes, and missing it is the most common parsing bug. A supplier shipping 60 of 100 units and backordering the rest sends one PO1 with two ACK segments underneath it. Flatten one row per ACK segment, not one row per line, or the backordered quantity disappears from your sheet.
No. PurchaseOrders reads purchase orders and order confirmations that arrive as PDFs, scans or email attachments and returns the header and line items as columns. True X12 855 files still need an EDI translator. The two are complementary, because most buying teams receive X12 from large suppliers and documents from everyone else.
It is set by your trading partner agreement rather than by the standard, and one business day is a common commitment. What the standard gives you is BAK09, the acknowledgment date, so you can measure the gap against BAK04 and hold suppliers to whatever was agreed.
The order that starts the exchange, flattened to rows.
The reverse direction, document to EDI ready data.
Turn a PO or confirmation into a plain spreadsheet.
Delimited output for building an import file.
Line level accuracy, one row per item.
Structured output for a system feed.
The same fields as JSON for a scripted flow.
Clear a confirmation backlog in one pass.
Built for high order volume buying desks.
