EDI File Documentation

---

Technical details

Feature	Value
Full name	Electronic Data Interchange Document
File extension	.edi (also .x12, .txt, none)
MIME type	application/edi-x12, application/EDIFACT
Format type	Structured plain-text business document
Main standards	ANSI ASC X12 (North America); UN/EDIFACT (international)
Other variants	TRADACOMS (UK retail); XML-based cXML, ebXML
Introduced	ANSI X12 since 1979; UN/EDIFACT since 1987
Open standard	Yes — published by standards bodies
Encoding	Plain text (ASCII / EBCDIC historically); no binary signature
X12 start segment	ISA (interchange envelope header)
EDIFACT start	UNA (service string) and/or UNB
Building blocks	Interchange → functional group → transaction → segments → elements
Delimiters (X12)	Element *, segment terminator ~ (configurable)
X12 examples	850 = Purchase Order, 810 = Invoice, 856 = Ship Notice
EDIFACT examples	ORDERS, INVOIC, DESADV
Opened with	Notepad++, EDI Notepad, Stylus Studio; EDI translators
Related extensions	.x12, .edifact, .xml, .csv
Standards body	x12.org, unece.org (UN/EDIFACT)

What is an EDI file?

An .edi file is a single Electronic Data Interchange document: a routine business document — a purchase order, an invoice, a shipping notice — encoded in a standard machine-readable format so one company’s computer can send it directly to another’s without paper or re-keying. EDI predates the web: ANSI chartered its X12 standard in 1979, and the United Nations published UN/EDIFACT in 1987. Those two remain the dominant standards, X12 across North America and EDIFACT internationally.

An EDI document is plain text, but text organised into a strict, compact structure of envelopes, segments and coded elements that is meant to be parsed by software, not read comfortably by a person. That is why a raw .edi looks cryptic: dense lines of letters, numbers and delimiters. The sections below decode that structure — the envelope hierarchy, the anatomy of a segment, how delimiters are declared, and how a numeric transaction code tells you whether you are holding an order or an invoice.

The envelope hierarchy: interchange, group, transaction

EDI wraps its data in nested envelopes so that many documents can travel together and be routed and acknowledged reliably. In X12 the three levels are the interchange, the functional group, and the transaction set, each with a header segment and a matching trailer:

ISA ...              interchange header (sender, receiver, control #)
  GS ...             functional group header (groups like documents)
    ST*850*0001~     transaction set header  (850 = purchase order)
      ... segments of the actual document ...
    SE*12*0001~      transaction set trailer (segment count)
  GE*1*000000905~    functional group trailer
IEA*1*000000905~     interchange trailer

The ISA/IEA pair is the outermost interchange, naming who sent the file and who receives it and carrying a control number that ties header to trailer. Inside, one or more GS/GE functional groups gather transactions of the same type. Inside each group, one or more ST/SE transaction sets are the individual documents. EDIFACT uses the same idea with different tags: UNB/UNZ for the interchange, UNG/UNE for the group, and UNH/UNT for the message. Every trailer echoes a count or control number from its header, which is how a receiver detects a truncated or reordered file.

The ISA segment: a fixed-width header, field by field

The X12 ISA segment is unusual and worth knowing in detail, because unlike every other segment it is fixed length: exactly 106 characters, with each element occupying a defined width. This lets a receiver read the delimiters and envelope routing before it knows anything else about the file.

ISA*00*          *00*          *ZZ*SENDERID       *ZZ*RECEIVERID     *
    250722*1200*U*00401*000000905*0*P*>~
     |      |    |  |     |         | | |  |
     date   time |  ver   control  | | |  component separator (>)
                 repetition sep     | | usage indicator (P=production, T=test)
                                    | ack requested
                                    interchange control number

The two authorisation and security qualifier pairs come first, then sender and receiver IDs with their qualifiers (ZZ = mutually defined), the interchange date and time, the version number (00401), the interchange control number that must match the IEA trailer, an acknowledgement-requested flag, and a usage indicator (P for production, T for test). The very last character before the terminator is the component element separator. Because ISA is fixed-width, a parser reads the element separator from a known position and the segment terminator from the character right after ISA’s final field, so it learns the file’s own delimiters from the file itself.

Segments, data elements and delimiters

Below the envelopes, the document body is a sequence of segments, one logical line each, and every segment is a segment ID followed by data elements separated by a delimiter. A segment ends with a terminator character. In X12 the conventional element separator is * and the segment terminator is ~, though both are configurable and are taken from the ISA segment rather than assumed.

BEG*00*NE*PO-4521**20250722~     beginning of purchase order
N1*ST*ACME WAREHOUSE~            name: ship-to party
PO1*1*100*EA*9.99**BP*012345~    line item: 100 each @ 9.99

EDIFACT differs in its default punctuation — element separator +, component separator :, segment terminator ' — and it declares these explicitly in an optional UNA service-string advice at the very start of the interchange. That is the one place a format literally tells you its own delimiters before any data. Within an element, composite sub-elements are split by the component separator, so a single element can carry structured sub-fields. This compactness is deliberate: EDI was designed when bandwidth and storage were expensive, so it favours short coded values over verbose labels.

Transaction codes: what kind of document is this?

The single most useful thing to read out of an EDI file is its transaction type, because that tells you what the document is. In X12 the type is the number right after ST; in EDIFACT it is the message type in the UNH segment. A small vocabulary covers most everyday supply-chain traffic:

X12	EDIFACT	Document
850	ORDERS	Purchase order
810	INVOIC	Invoice
856	DESADV	Advance ship notice
855	ORDRSP	Purchase order acknowledgement
997	CONTRL	Functional acknowledgement

So a file whose header reads ST*850 is a purchase order, and one reading UNH...INVOIC is an invoice. The 997/CONTRL acknowledgement is EDI’s built-in receipt: after receiving a document, a partner returns one of these to confirm it arrived and parsed, which is how automated EDI pipelines detect failures without a human watching.

X12 and EDIFACT are not interchangeable

X12 and EDIFACT encode the same kinds of business documents but are separate standards with different tags, delimiters and code lists, and a translator configured for one does not read the other. X12 dominates North American trade; EDIFACT is the international and European norm; some sectors add their own (TRADACOMS in UK retail, HIPAA-mandated X12 subsets in US healthcare). This is why “open an EDI file” has no single answer: the meaning depends on the standard and the transaction type, and a viewer must know both to map the codes to labelled fields. Free text editors (Notepad++, VS Code with an X12 extension) show the raw segments; dedicated EDI viewers such as EDI Notepad or Stylus Studio decode them into readable transaction trees and can translate to XML or CSV.

The extension is a convention, and the data is sensitive

The .edi extension itself is not standardised. The same content is routinely sent as .txt, .x12, .edifact, or with no extension at all, because EDI is usually moved over AS2, SFTP or a value-added network where the filename is irrelevant; what identifies the document is the ISA or UNB header inside, not the name. If you need to know what a file is, read its first segment, not its extension.

The file is plain text with no executable content, so opening one is safe in the sense that it cannot run code. The genuine concern is confidentiality: EDI documents carry real business and sometimes personal data — prices, addresses, order histories, and in healthcare EDI, patient and claim information governed by HIPAA. That makes it a mistake to paste a real .edi into an arbitrary online “EDI viewer” site; for anything containing live partner or patient data, use an offline editor or a desktop EDI viewer and keep sample data for the web tools.

References

• X12 — ANSI ASC X12 standards body
• UNECE — introducing UN/EDIFACT
• Stylus Studio — EDI tools and EDI-to-XML

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.