EN

Home / Knowledge / EDIFACT explained

How is EDIFACT structured?

UN/EDIFACT is the United Nations' international standard for the electronic exchange of structured business data such as purchase orders, despatch advices and invoices. An EDIFACT file consists of segments built with fixed separators, which is why programs can read it reliably. The syntax is defined in ISO 9735, the content of the messages in UNECE directories. This page explains the structure of EDIFACT using an annotated example.

Last updated 18 October 2026 · fokus it solutions, Jens Musleh

Who is behind EDIFACT?

The name stands for “Electronic Data Interchange for Administration, Commerce and Transport”. UNECE, the United Nations Economic Commission for Europe, describes UN/EDIFACT as a set of internationally agreed standards, directories and guidelines for the exchange of structured data between independent computerised information systems. The rules are published in the UNTDID, the “United Nations Trade Data Interchange Directory”. EDIFACT is maintained by UN/CEFACT, the United Nations Centre for Trade Facilitation and Electronic Business.

There are two levels you should keep apart:

  • The syntax governs how a file is built: separators, header and trailer segments, counting rules. It is set out in ISO 9735.
  • The directories govern which messages exist, which segments they contain and what the codes mean. GS1 Germany states that UN/EDIFACT has “over 200 different message types” (our translation).

What the directories D.96A and D.01B mean

An EDIFACT directory is a release of the rule set. UNECE publishes new releases on an ongoing basis; the oldest in the archive date from the 1990s. They are identified by version and release, for example D.96A or D.01B. UNECE lists the despatch advice message DESADV in directory D.01B with “Version: D”, “Release: 01B” and “Contr. Agency: UN”, for instance.

You will find exactly this information in every message, in the UNH segment. If it says ORDERS:D:96A:UN, the message is a purchase order based on directory D.96A. As a recipient, you should pay attention to this, because an ORDERS message based on D.96A and one based on D.01B can differ in segments and codes. Which directory applies is stated in your partner's EDI implementation guide.

The structure of an EDIFACT file

An EDIFACT interchange is like an envelope with one or more letters inside. From the outside in:

Segment Name Purpose
UNA Service String Advice optional; defines the separators if they differ from the default
UNB Interchange Header header of the interchange: character set and syntax version, sender, recipient, date, reference
UNG / UNE Functional Group optional; groups messages of the same type
UNH Message Header start of a message: sequence number and message identifier
BGM, DTM, NAD, LIN, QTY … user data content of the message
UNS Section Control optional; separates header, line item and summary sections
UNT Message Trailer end of the message: number of segments including UNH and UNT, same number as in UNH
UNZ Interchange Trailer end of the interchange: number of messages, same reference as in UNB

The count fields in UNT and UNZ provide a simple completeness check. If the count is wrong, the file is corrupted or truncated, and the recipient's software rejects it.

Separators and release character

EDIFACT makes do with just a few control characters. The UNECE syntax guidelines list these characters for the usual level A:

Character Meaning
' (apostrophe) segment terminator
+ (plus) separates the segment tag and data elements
: (colon) separates parts within a composite data element
? (question mark) release character: the next character is treated as normal text

An example of the release character: the company name “Smith + Sons” is written as Smith ?+ Sons, otherwise the plus sign would be read as a separator.

According to UNECE, the UNA line is always nine characters long: “UNA” followed by six characters for the control characters. Partners often send it even when it only contains the usual characters. Your software should be able to handle both.

An annotated EDIFACT example

The following purchase order is entirely made up. The GLNs (Global Location Numbers, identifiers for companies and locations) begin with the prefix 952, which GS1 has reserved for examples. Each line is a segment; the line breaks are only there for readability.

UNA:+.? '
UNB+UNOC:3+9520000000011+9520000000028+261016:1430+00001'
UNH+1+ORDERS:D:96A:UN'
BGM+220+B-4711+9'
DTM+137:20261016:102'
NAD+BY+9520000000011::9'
NAD+SU+9520000000028::9'
LIN+1++9520000000035:SRV'
QTY+21:240'
DTM+2:20261030:102'
UNS+S'
CNT+2:1'
UNT+11+1'
UNZ+1+00001'

Read line by line:

  • UNA:+.? ' defines the six control characters, here the usual ones, including colon, plus, question mark and apostrophe.
  • UNB gives the character set and syntax version (UNOC:3), sender, recipient, date and time (16 October 2026, 14:30) and the interchange reference 00001. Whether a qualifier for the type of identifier follows the identifier is set out in the implementation guide.
  • UNH+1+ORDERS:D:96A:UN starts message number 1: a purchase order based on directory D.96A.
  • BGM+220+B-4711+9 is the beginning of the message. Code 220 stands for “Order”, B-4711 is the order number, 9 means “Original”.
  • DTM+137:20261016:102 is the document date (code 137) in the format CCYYMMDD (code 102).
  • NAD+BY and NAD+SU name the buyer and the supplier with their GLNs. The 9 refers to GS1 (formerly EAN) as the issuing agency.
  • LIN+1++9520000000035:SRV is line 1 with a GTIN (Global Trade Item Number, the GS1 item number).
  • QTY+21:240 is the ordered quantity (code 21), here 240 pieces.
  • DTM+2:20261030:102 is the requested delivery date (code 2).
  • UNS+S separates the line items from the summary section, and CNT+2:1 reports one line item.
  • UNT+11+1 counts eleven segments from UNH to UNT and repeats message number 1.
  • UNZ+1+00001 reports one message in this interchange and repeats the reference from UNB.

What the codes (220, 137, 21 and so on) mean is set out in the code lists of the relevant directory. Your partner can specify additional mandatory fields and its own rules in its implementation guide.

Industry subsets: EANCOM, ODETTE and EDIFICE

A complete EDIFACT directory is very extensive. Industries have therefore created subsets, meaning binding selections of messages, segments and codes. UNECE defines a subset as a message that is directly derived from a UN standard message, has the same function and keeps its mandatory parts unchanged.

  • EANCOM is maintained by GS1 and, according to GS1 Germany, is “a subset of the UN/EDIFACT standard” (our translation). The current release is called EANCOM 2002. Originally developed for consumer goods, it is now also used in healthcare, logistics and fashion.
  • ODETTE stands for the European automotive industry. The VDA list of EDI recommendations includes earlier Odette messages, such as “Odette EDIFACT INVOIC”, which have since been replaced by the VDA Global recommendations (see VDA and Global standards).
  • EDIFICE is the European B2B forum of the electronics industry. Its implementation guidelines are a subset of UN/EDIFACT based on directory D.97A.

What this means for you: “We work with EDIFACT” is not enough information. What matters is the subset, the directory and your partner's implementation guide. You will find a checklist under Reading an EDI implementation guide.

EDIFACT and X12 compared

X12 is the other major EDI standard. It is maintained by X12, an organisation accredited by the American National Standards Institute (ANSI). In principle, X12 works the same way: segments, separators, header and trailer. Its messages, however, are not called ORDERS or INVOIC but carry numbers. According to X12, these include 850 for the purchase order, 856 for the despatch advice (“Ship Notice/Manifest”) and 810 for the invoice. If you supply customers in North America, you will often come across X12; German and other European implementation guides usually require EDIFACT or an EDIFACT subset.

The overview of EDI message types shows which EDIFACT messages you will meet in practice.

EDIFACT with edi-service.eu

edi-service.eu processes EDIFACT including EANCOM; the AI reads the directory and the requirements from your partner's implementation guide and generates the mapping from them, in test mode first, for inbound messages as well as for despatch advice and invoice to the partner. X12 is not part of the scope. You will find the price on the home page.

Frequently asked questions

What is the difference between EDI and EDIFACT?

EDI is the method of electronic data interchange; EDIFACT is one format for it. Besides EDIFACT, there are for example VDA formats, X12, XML or CSV. For an introduction, see What is EDI?.

Which EDIFACT version do I need?

Your partner sets the version, not you. It is stated in the EDI implementation guide and in the UNH segment of every message, for example ORDERS:D:96A:UN. Industry subsets often fix the directory; EDIFICE, for instance, is based on D.97A.

Can you read EDIFACT files in a text editor?

Yes, EDIFACT is plain text. Without knowing the code lists, though, the content is hard to interpret, because the meaning is in the codes: 220 means order, 137 means document date. If there are no line breaks, the whole interchange sits on a single line.

Is EANCOM the same as EDIFACT?

EANCOM is a subset of EDIFACT defined by GS1 for retail and other sectors. Every EANCOM message is a valid EDIFACT message, but not the other way round. EANCOM requires GS1 identifiers such as the GLN and GTIN, for example.

What is a CONTRL message?

CONTRL is the syntax and service report message in EDIFACT. It tells the sender whether its interchange arrived syntactically correct; it is defined in ISO 9735 part 4. Whether CONTRL is required is stated in the implementation guide.

If you would like to check whether your EDIFACT requirements are a good fit for edi-service.eu, you can send an enquiry.

Sources

Send an enquiry · FAQ · All knowledge pages