An EDI file is a machine to machine format that arrives as one unbroken run of coded segments, and no delimiter setting in Excel will turn it into a usable sheet. This page explains how to read the delimiters out of the ISA header, how one file can hold forty orders, which columns each transaction set actually gives you, and where the PDF orders from your smaller accounts fit into the same columns.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
EDI was designed to be parsed by software, not read by a person. Every property that makes it efficient on the wire is the reason a spreadsheet cannot make sense of it.
Segments end with a terminator character rather than a newline, and plenty of partners send the entire interchange as a single unbroken line. Open that in Excel and you get one very wide row, or one cell holding the whole file.
Asterisk and tilde are common, not required. The actual characters are declared inside the ISA header, so any tool that hard codes them works on your test file and then fails on the first trading partner who chose something else.
One document has a header, party loops, then a repeating detail loop with an entry per item. Turning that into rows means repeating the header on every line, which Excel will not do for you, and on an 856 it means carrying a whole hierarchy down.
Qualifiers say SA, ST, UP, EA. None of it reads as English, so a sheet full of raw codes is barely more useful than the file it came from. Translating the codes is part of the conversion, not a tidy up afterwards.
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, it does not parse X12 or EDIFACT files, and it does not send acknowledgments. If your large partners send true EDI, keep the translator that handles it. This page exists because almost every buying desk and supplier runs both channels, and the document channel is where the manual keying actually happens.
Purchase order number, order date, requested 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.
EDI carries buyer part and vendor part as qualifier and value pairs. 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 a document gets the same sanity check that CTT01 gives you inside an X12 document.
Long orders that run across pages stay one order, and a mixed batch of customers can go through in a single pass.
Nothing about an X12 file is safe to assume, including the characters that separate the data. The ISA interchange header is the only fixed length segment in X12, and it is fixed precisely so a parser can read the delimiters out of it by position before it understands anything else. Read them from the file rather than hard coding an asterisk and a tilde, because trading partners genuinely do use other characters and a hard coded splitter fails silently on the first one that does.
| What it sets | Where to read it | Common value |
|---|---|---|
| Element separator | The character immediately after the letters ISA, that is the 4th character of the file | Asterisk |
| Component (sub element) separator | ISA16, the last element of the ISA segment | Colon |
| Segment terminator | The character immediately after ISA16 | Tilde |
| Repetition separator | ISA11 in version 00501 and later | Caret |
The practical rule: read the first 106 characters, pull the three delimiters out by position, then parse the rest of the file with them. That single step is what separates a converter that works across trading partners from one that works only on the file you tested with.
People expect a file to hold a document. An EDI file holds an interchange, and an interchange can carry dozens of documents from several different transaction sets at once. That is why converting one file rarely gives you one tidy sheet.
| Envelope | Opens and closes with | What it contains |
|---|---|---|
| Interchange | ISA and IEA | The whole transmission between two trading partners. One file, one ISA. |
| Functional group | GS and GE | All documents of one type. GS01 carries the group code, for example PO for purchase orders. |
| Transaction set | ST and SE | One actual business document. ST01 carries the transaction set code, for example 850. |
So a single file might be one ISA holding one GS holding forty ST blocks, which is forty separate purchase orders. Decide up front whether you want one sheet per order, one sheet per file with an order column, or one row per line item with the order number repeated. Most downstream jobs want the third, and it is the one Excel will never produce for you on its own.
There is no single EDI to Excel mapping, because EDI is not one format. Each transaction set has its own detail loop, and the loop is what becomes your rows. Converting an 850 and converting an 856 are different jobs that happen to share an envelope.
| Set | Document | Detail loop | What one row means |
|---|---|---|---|
| 850 | Purchase order | PO1 | One ordered line: quantity, unit of measure, price, part numbers |
| 855 | Purchase order acknowledgment | PO1 with ACK underneath | One status per line, and a line can carry several |
| 860 | Purchase order change | POC | One changed line, with the change reason code |
| 856 | Advance ship notice | HL hierarchy | Genuinely nested: shipment, order, pack, item |
| 810 | Invoice | IT1 | One invoiced line |
| 997 | Functional acknowledgment | AK2 and AK3 | One accepted or rejected document, no business data at all |
The 856 is the one that catches people out. Its HL segments describe a tree, and flattening a tree into rows without carrying the parent identifiers down each level destroys the pack to item relationship that the document exists to communicate. If you only need the item list, flatten it. If you need to know which carton an item is in, do not.
Most US trading partners send ANSI X12. If you also buy from or sell into Europe or Asia you will meet EDIFACT, and a converter built for one will not read the other. The envelope, the delimiters and the segment names are all different.
| ANSI X12 | EDIFACT | |
|---|---|---|
| Where it dominates | North America | Europe and much of Asia |
| Interchange envelope | ISA and IEA | UNB and UNZ |
| Document envelope | ST and SE | UNH and UNT |
| Delimiters declared in | ISA, by fixed position | The optional UNA service string advice |
| Default delimiters | Asterisk, colon, tilde | Plus, colon, apostrophe |
| Purchase order is called | 850 | ORDERS |
When EDIFACT has no UNA segment the defaults apply. When it does have one, the six characters after the letters UNA are the delimiters, which is the same idea as reading them out of ISA and a good reason to write the delimiter detection once for both.
The most valuable thing about converting EDI rather than a PDF is that the file grades its own conversion. Three counters let you prove nothing was dropped, and checking them takes seconds.
| Element | Counts | Check it against |
|---|---|---|
| SE01 | Segments in the transaction set, including ST and SE | The segments you actually parsed for that document |
| GE01 | Transaction sets in the functional group | The number of documents you produced |
| IEA01 | Functional groups in the interchange | The groups you walked |
| CTT01 | Line items in the document (850, 855 and others) | Your row count for that order |
One caveat worth knowing before you trust CTT01 as a row check. CTT01 counts detail lines, not output rows. On an 855 where a supplier splits a line into a shipped quantity and a backordered quantity, one line legitimately produces two rows, so your sheet will have more rows than CTT01 and nothing is wrong. Compare CTT01 to distinct line numbers rather than to raw row count.
Flattening is lossy by nature. These are the losses that matter, in the order they tend to bite.
Almost no buying desk or supplier runs one channel. The large accounts send X12 and the rest send a PDF attached to an email, and the second group is where the manual keying actually happens. The reason to line the two up is that the columns can be identical: purchase order number, order date, requested date, ship to, vendor, then one row per item with quantity, unit of measure, price and part number. Agree that layout once and both channels can write into the same sheet, the same import file and the same report. That is the job PurchaseOrders does, and it is deliberately the half of the problem an EDI translator does not solve.
Which one is right depends on whether this is a file you need to read today or a channel you have to run every day.
| Route | Best for | What it takes | Watch out for |
|---|---|---|---|
| EDI translator export | Ongoing EDI volume | The translator you already license, writing a CSV or database drop | 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 live customer orders, with prices and addresses, to a third party site |
| A parsing script | Repeatable conversion you control | Reading delimiters from ISA, walking the detail loop, mapping codes | It is real work per transaction set, and partner variation is what breaks it later |
| Manual retyping | One short order and nothing else | A person and the file printed out | Slow and error prone, and it does not scale past a handful of lines |
| PurchaseOrders | The PDF and emailed orders EDI never covered | Uploading the document, no template per vendor | It does not read X12 or EDIFACT files, by design. It handles the other channel. |
Most teams end up with two of these running side by side: a translator for the partners on EDI, and something lighter for everyone else.
This is the path for the orders that never arrive as EDI, which for most businesses is the majority of the 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 account.
Order number, dates, ship to and every item line come back together, so you can confirm the line count and catch a misread quantity or price before anything moves downstream.
Tip: Check the item count the same way CTT01 checks an X12 document.
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.
Read the delimiters out of the ISA header first, split the file into segments on the segment terminator, then split each segment on the element separator. Walk the detail loop for that transaction set and write one row per line item, repeating the header values on every row. Translate the qualifier codes as you go, then check your row count against CTT01.
Excel can open it, but not usefully. Text to Columns will split an EDI file on the element separator and give you one very wide row, or one enormous cell if the file has no line breaks. It cannot repeat header values down the line items or turn the codes into readable labels, which is the part of the conversion that has any value.
Because line breaks are not part of the standard. Segments end with a terminator character, commonly a tilde, and many partners send the whole interchange with no newlines at all. The file is not corrupt. Replace the segment terminator with a line break and it becomes readable immediately.
The same way as to Excel, and CSV is usually the better target. Flatten to one row per line item with the header repeated, write it delimited, and keep every identifier as text so leading zeros survive. CSV also avoids the silent number formatting that Excel applies to part numbers and long GTINs on open.
Whatever the file declares. In X12 the element separator is the character right after the letters ISA, the component separator is ISA16, and the segment terminator is the character after ISA16. Asterisk, colon and tilde are common but not guaranteed. In EDIFACT the optional UNA segment declares them and the defaults are plus, colon and apostrophe.
Yes, and it usually does. One ISA interchange can hold several GS functional groups, and each group can hold many ST transaction sets. Each ST block is one document, so a single file can easily carry forty purchase orders. Decide whether you want a sheet per order or one sheet with an order number column before you start.
That is the opposite direction and a different job. Going out to EDI means building a valid envelope with correct control numbers and meeting the trading partner implementation guide, which is what an EDI translator is for. Going in is just parsing. If your orders start as documents rather than spreadsheets, the PDF to EDI ready data route is the closer fit.
They are two separate standards for the same idea. X12 is the North American one and wraps documents in ISA and ST envelopes with numeric codes like 850. EDIFACT is the international one and uses UNB and UNH envelopes with named messages like ORDERS. A parser written for one will not read the other.
No, and it is worth being clear about that. PurchaseOrders reads purchase orders that arrive as PDFs, scans or email attachments and returns the header and every line item as clean columns. True X12 files still need an EDI translator. The two solve different halves of the same problem, which is why most teams end up running both.
The purchase order itself, segment by segment.
The acknowledgment, with all 26 ACK01 status codes.
The reverse direction, document 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.
