EDI Order Parser

Turn EDI purchase orders into a spreadsheet, and check their structure.

Open on Apify Store Free from us. Apify bills its own small platform usage to your Apify account. Cost and how to start

What it does

Give it your EDI files by pasting them, linking to them or uploading them to Apify storage. It works out whether each file is X12 or EDIFACT and reads every order in it: order number, dates, parties, references and each line with its product codes, description, quantity, unit and price. You get one CSV row per order line, ready for a spreadsheet or an import. It also checks each message's structure: envelope and trailer counts, dates, numbers and a list of basic rules, and marks each message pass, pass with warnings, or fail.

For suppliers and small teams who receive purchase orders as ANSI X12 850 or UN/EDIFACT ORDERS files and want the order lines without buying EDI software. It runs on Apify, so you need an Apify account (the free plan works).

What you get

orders.csv: one row per order line, with the order number, date, buyer, currency, product codes, description, quantity, unit and price. A message with no order lines gets one row with only its header fields.
One result row per message with the whole order as JSON, its errors and warnings, and where each one is (segment, position and element).
A short report per file listing each message's problems.
Several orders and groups in one file are fine. Other message types, such as invoices, get their envelopes checked but aren't mapped.
A clear row for a file it can't read, so one bad file doesn't stop the rest.

Example: problems found in published sample files

Where	Message
UNT	UNT says 38 segments; the message has 72 (UNH to UNT inclusive).
CTT	CTT01 says 10 line items; the order has 1 PO1 segments.
SE	SE01 says 15 segments; the transaction set has 14 (ST to SE inclusive).

Messages from our test run.

Best for

Getting the lines of incoming purchase orders into a spreadsheet or another system.
Checking EDI files you produce or receive for broken envelopes and counts before they cause a rejection.

Not for

Checking your trading partner's own rules. Their required segments, codes and business rules aren't checked, and code lists aren't validated.
Sending or receiving EDI. It doesn't connect over AS2, a VAN or SFTP, and doesn't create acknowledgements.
A single message without its envelope. A file that starts at UNH or ST, with no UNB or ISA header, gets one row saying it isn't recognised.
Invoices, ship notices and other documents. Only X12 850 and EDIFACT ORDERS are turned into order lines.

Cost and how to start

Open it on Apify Store and sign in, or create a free Apify account.
Give it your EDI files, pasted, as links, or uploaded to Apify storage and start the run.
Download orders.csv, the result rows, or the report for each file.

Free from us. Apify bills its own small platform usage to your Apify account. Apify charges its own small usage fee to your account: about US$0.002 for our test run of 28 files when we tested it.

If we start charging, the price is shown on the Store page and existing users get notice first.

Questions

Does a pass mean my partner will accept the file?: No. A pass means the file passed the checks listed on the Apify page. Your partner may have extra rules, and the checks can miss problems. Look over the mapped data before you ship goods or send invoices based on it.
How big can my files be?: Up to 10 MB each by default, and up to 20 MB if you raise the limit and set the run memory to 512 MB. You can give up to 1,000 files in one run.
Where are my orders kept?: The actor reads only the files you give it and saves the results in your own run's storage in your Apify account. Nothing is sent anywhere else. Apify deletes run storage automatically under your plan's data-retention rules, or you can delete it sooner in the Apify Console.

How we tested it

Sample orders from other people's projects. We ran 28 X12 and EDIFACT files published in open-source projects on GitHub, including book orders from a library system and the sample files of two EDI libraries. For every order that our own simple count of the file could also read, both gave the same number of order lines and the same total quantity: 49 lines and 358 copies in the largest book order.
Real problems in published files. It found trailer counts that don't match the message, an interchange with no closing segment, an order with no line items, a line count that says 10 when there is one line, a header field padded to the wrong width, and a date in the wrong format for its version. We checked each one in the file by hand, and each was really there. Files that their authors broke on purpose were caught too: two with a damaged file header were reported as unreadable, and two with a damaged message header got an error for every segment left outside a message.