What EDI Translation Means
An EDI file is a business document written for machines. A purchase order, an invoice and a ship notice all arrive as rows of short codes separated by asterisks or plus signs, with the meaning carried by position: the fourth element of a PO1 segment is a unit price, the sixth element of an N1 segment is nothing at all. Translation is the step that turns those positions back into named facts. It is what an order desk does in its head when someone forwards a raw 850 and asks what the customer wants.
This translator does that step for one document at a time. It reads the envelope (who sent the file, to whom, and when), then each transaction set or message inside it, and writes out the order number, dates, ship-to and bill-to parties, and every line with its quantity, unit, price and item numbers. Codes are expanded as it goes: SA becomes a stand-alone order, CA a case, UP a UPC.
Translator, Mapping, and Integration
People use “EDI translator” for three different jobs, and it helps to know which one you need.
- Reading: turning a file into something a person can check. That is this page, and the EDI validator when you also need to know whether the file is valid.
- Mapping: deciding which EDI element lands in which field of your ERP, per trading partner. Walmart's department number, Target's DPCI and a grocer's catch weight all need a home. Developers who build that themselves usually start from EDI converted to JSON.
- Integration: running it every day. Files arrive by AS2, SFTP or a VAN, get translated and mapped, post as sales orders, and the 997, 855, 856 and 810 go back out. That is what an EDI provider or ERP integration does.
Three Outputs, One File
Plain English is for people: forward it to a buyer, paste it into a ticket, or check a partner's file before you call them. The CSV gives one row per line item, ready for a spreadsheet or a bulk import. JSON keeps the full structure for scripts; the EDI to JSON converter documents its shape. Going the other way, from a spreadsheet to EDI, the CSV to EDI converter builds an 850 from your order lines.
X12, EDIFACT and TRADACOMS
North American partners send ANSI X12: an order is an 850 inside ISA, GS and ST envelopes. UK and European partners send UN/EDIFACT, usually the GS1 EANCOM subset, where an order is an ORDERS message inside UNB and UNH, or in UK grocery the older TRADACOMS format. The translator detects which one you pasted from its first characters and reads it with the matching parser, so an EDIFACT ORDERS message comes back as a translated order, not an empty X12 skeleton. For segment-level detail on each standard, see the EDI transaction guides and the EDIFACT guide.