An EDI 850 is the X12 purchase order your retail and distribution partners send, and it arrives as one unbroken run of segments rather than a spreadsheet. This page explains what each segment holds, how to flatten a hierarchical 850 into flat Excel or CSV rows, and how to get the PDF and emailed orders from your smaller accounts into those same columns.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
The 850 is a machine to machine format. It was designed to be parsed by software, not read by a person, and nothing about it lines up with rows and columns.
Many 850s arrive with no line breaks at all. Segments end with a terminator character and elements are split by a separator, both declared in the ISA header. Open it in Excel and you get a single very wide row, or one enormous cell.
One order has a BEG header, one or more N1 party loops, then a repeating PO1 loop with one entry per item. Turning that into rows means repeating the header on every line, which no delimiter setting in Excel will do for you.
BEG02 says SA. N101 says ST. PO106 says UP. None of it reads as English, so a spreadsheet full of raw qualifiers is barely more useful than the file it came from. The codes have to be translated as part of the conversion.
X12 is a large standard and every retailer publishes its own implementation guide picking the segments and qualifiers it sends. A parser tuned to one partner tends to break on the next one, which is why this is rarely a one time job.
PurchaseOrders is a document extraction tool. It reads purchase orders that arrive as PDFs, scans or email attachments and returns the header plus every line item as clean columns. It is not an EDI translator: it does not connect to a VAN, and it does not generate a 997 acknowledgment. If your large partners send true X12 850 files, keep the translator that handles them. This page exists because most suppliers run both channels, and the second one is where the manual keying happens.
PO number, order date, requested ship date, ship to, vendor, then one row per item with quantity, unit of measure, unit price and part number. Line those up with what your translator writes and both channels land in one sheet.
No template to build per vendor and no coordinate mapping. A new customer can send a completely different looking order and the same fields still come back, which is the practical difference from a per partner EDI map.
An 850 carries buyer part and vendor part as qualifier and value pairs from PO106 onward. Orders 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 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 order reports its line count, so you can run the same sanity check against a document that CTT01 gives you inside an 850.
Long orders that run over several pages stay as one order, and a folder of mixed customers can be processed in a single pass.
An 850 is built from segments. Each segment starts with a two or three character identifier, its elements are separated by a delimiter (commonly an asterisk), and the segment ends with a terminator (commonly a tilde). The delimiters are declared in the ISA header, so read them from the file rather than assuming.
| Segment | What it carries | Spreadsheet column it becomes |
|---|---|---|
| ISA / GS / ST | Interchange, functional group and transaction set envelope. ST01 is 850. | Usually dropped, but keep ISA13 for traceability |
| BEG | BEG01 purpose (00 original, 01 cancellation, 05 replace), BEG02 order type (SA stand alone, BK blanket, DS drop ship), BEG03 the PO number, BEG05 the PO date as CCYYMMDD. | PO number, order date, order type |
| REF | Reference numbers qualified by a code, for example a department or contract number. | One column per qualifier you care about |
| DTM | Dates by qualifier: 002 delivery requested, 010 requested ship, 001 cancel after, 037 and 038 ship not before and not after. | Requested ship date, cancel date |
| N1 loop | Parties, keyed by N101: ST ship to, BT bill to, SF ship from, BY buying party, VN vendor. N3 and N4 carry street, city, state and ZIP. | Ship to name and address, bill to, vendor |
| PO1 | One per ordered item. PO101 line number, PO102 quantity, PO103 unit of measure (EA each, CA case, LB pound), PO104 unit price, then repeating qualifier and value pairs from PO106 onward: UP for UPC, VN or VP for vendor part, BP for buyer part, SK for SKU. | One spreadsheet row per line item |
| PID | Free form product description tied to the PO1 above it. | Item description |
| CTT | CTT01 is the count of PO1 segments and CTT02 an optional hash total of quantities. | Not a column. Use it to check your parse |
CTT01 is the single most useful validation you get for free. If your spreadsheet has a different number of item rows than CTT01 says, the parse dropped or duplicated a line and everything downstream is wrong.
The awkward part is not splitting the file. It is that an 850 describes one order with many items, while a spreadsheet wants one fact per row. The usual answer is to denormalize: repeat the PO number, order date, requested ship date and ship to on every item row, so each row stands on its own and the sheet can be sorted, filtered and imported. A second common layout keeps two sheets, one header row per order and one line sheet joined on the PO number, which is closer to what most ERP import routines expect anyway. Decide which one before you parse, because rebuilding the loop afterwards is the expensive step.
Most suppliers do not run one order channel, they run two. The large accounts send true 850s through a VAN or an AS2 connection. Everyone else emails a PDF, and that second stream is the one that gets keyed by hand. Pointing both at the same column layout is what makes the order book complete. If you want the reverse direction, where a PDF order has to be turned into data your EDI flow can send, see the PDF purchase order to EDI page. For a plain spreadsheet, the PO PDF to Excel converter and the CSV export produce it directly, and a backlog clears in one pass with bulk purchase order upload. Because the whole point is line level accuracy, purchase order line item extraction is the part that has to be right. Distributors working high order volume tend to start at purchase order extraction for wholesale distribution.
If you are newer to X12, what an EDI 850 purchase order is and how to read one walks the segments in order. EDI vs PDF purchase orders covers when each channel is worth the setup, cXML vs EDI compares the two formats large buyers use, and the EDI 856 advance ship notice is the document you send back once the order ships.
Which one is right depends on whether this is a one time read or a channel you have to run every day.
| Route | Best for | What it takes | Watch out for |
|---|---|---|---|
| EDI translator export | Ongoing 850 volume | Your existing translator writing a CSV or a database drop | Licensing plus a mapping step per trading partner, which is the usual reason people go looking for something lighter |
| Online EDI viewer | A single file you need to read today | Pasting or uploading the file into a web tool | You are sending a live customer order, with prices and addresses, to a third party site |
| Parse it yourself | A few predictable partners | Split on the terminator, split on the element separator, then walk the PO1 loop and look up the qualifiers | The loop handling 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 rebuild the item loop at all |
| Extract from the document | Orders that arrive as PDF or email | Uploading the order 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 orders that do not arrive as X12, which for most suppliers is the majority of their customer list.
Drop in the PDF, the scan or the email attachment. Multi page orders and a batch of mixed customers are both fine.
Tip: Start with two or three orders from your highest volume customer.
PO number, dates, ship to and every item line come back together, so you can confirm the line count and spot a misread quantity or price before anything moves downstream.
Tip: Compare the item count to the order the same way CTT01 checks an 850.
Take the columns in whatever shape the next system wants, matching the layout your EDI drop already writes so both channels merge cleanly.
Tip: Agree the column layout once, then both order channels can share it.
Split the file on its segment terminator, split each segment on its element separator, then walk the PO1 loop and write one row per item while repeating the BEG and N1 header values on every row. Translate the qualifier codes as you go, and check your row count against CTT01. An EDI translator does this for you if you have one.
Not usefully. Excel can split an 850 on the element separator with Text to Columns, but the result is one very wide row per segment rather than a table. Excel has no way to rebuild the repeating PO1 item loop or to repeat the header values down the rows, which is the part that makes the data usable.
BEG carries the purpose code, order type, PO number and date. REF carries qualified reference numbers, DTM carries the dates, and the N1 loop carries ship to, bill to and vendor. PO1 repeats once per item with quantity, unit of measure, price and part numbers, PID gives the description, and CTT totals the lines.
The purchase order number is in BEG03, the third element of the BEG segment. BEG01 before it is the transaction purpose code and BEG02 is the order type, so in a segment reading BEG*00*SA*4500123456**20260715 the PO number is 4500123456 and the order date is 15 July 2026.
CTT01 holds the number of PO1 segments in the transaction, which makes it a free correctness check. After converting an 850 to a spreadsheet, count your item rows and compare. If the two numbers differ, the parse dropped or duplicated a line and the sheet cannot be trusted downstream.
The 850 is the purchase order the buyer sends. The 855 is the purchase order acknowledgment the supplier sends back to confirm, change or reject the order line by line. The 856 advance ship notice follows when the goods ship, and the 810 invoice comes after that.
No. PurchaseOrders reads purchase orders that arrive as PDFs, scans or email attachments and returns the header and line items as columns. True X12 850 files still need an EDI translator. The two are complementary: most suppliers receive 850s from large accounts and documents from everyone else.
X12 defines a large superset of optional segments and qualifiers, and each buyer publishes an implementation guide choosing which ones it sends. That is why one partner includes REF and PID segments another omits, and why a parser built against one guide usually needs work before it handles the next.
Yes, and it is the practical reason to standardize the columns. Decide on a header and line layout once, have your EDI translator write to it, and extract the PDF and emailed orders into the same shape. The order book is then complete regardless of which channel a customer uses.
The reverse direction, PDF order to EDI ready data.
Turn a PO document 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 an order backlog in one pass.
Built for high order volume distributors.
The general ERP load pattern.
