# 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. ## 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](https://edi-service.eu/en/knowledge/vda-4905-4913-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](https://edi-service.eu/en/knowledge/edi-implementation-guide-checklist/). ## 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](https://edi-service.eu/en/knowledge/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](https://edi-service.eu/en/#preis). ## 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?](https://edi-service.eu/en/knowledge/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](https://edi-service.eu/en/enquiry/). ## Sources - UNECE: “Introducing UN/EDIFACT”, archived version of 11 July 2025, (retrieved 16 October 2026) - UNECE: “UN/EDIFACT Syntax Implementation Guidelines” (UNTDID part 4, chapter 2.3), archived version of 15 September 2024, (retrieved 16 October 2026) - UNECE: “UN/EDIFACT Message DESADV, Release 01B”, archived version of 14 June 2026, (retrieved 16 October 2026) - UNECE: “UN/EDIFACT Message ORDERS, Release 96A”, archived version of 16 June 2021, (retrieved 16 October 2026) - UNECE: code lists D.01B, data elements 1001, 1225, 2005, 2379, 3035, 3055, 6063, 6069, 7143, archived versions, e.g. (retrieved 16 October 2026) - ISO: “ISO 9735-4:2002, EDIFACT, Application level syntax rules, Part 4: Syntax and service report message for batch EDI (message type CONTRL)”, archived version of 21 August 2026, (retrieved 16 October 2026) - GS1 Germany: “EANCOM®: EDI-Standard Nr. 1”, (retrieved 16 October 2026) - GS1: “GS1 Company Prefix” (prefix 952 for examples), archived version of 10 February 2025, (retrieved 16 October 2026) - GEFEG: “EDIFICE, European B2B Forum for the Electronics Industry” (as of July 2023), (retrieved 16 October 2026) - VDA: “Liste der Empfehlungen zum Datenaustausch in der Lieferkette und zu warenbegleitenden Papieren”, as of August 2024, (retrieved 16 October 2026) - X12: “About X12”, (retrieved 16 October 2026) - X12: “Supply Chain Transaction Flow”, (retrieved 16 October 2026)