# EDIFACT Explained: Format, Envelope and X12 Mapping

> What UN/EDIFACT is, how its syntax and UNB/UNH envelope work, how to read an interchange, D96A vs D01B, EANCOM, every message family, and EDIFACT vs X12.

<QuickAnswer>
EDIFACT (UN/EDIFACT) is the United Nations standard for electronic data interchange, used across Europe, the UK and most trade outside North America. It sends business documents such as ORDERS, DESADV and INVOIC as delimited text segments inside a UNB/UNZ envelope. It does the same job as ANSI X12 with different syntax and message names.
</QuickAnswer>

If you already run X12 with US retailers, EDIFACT will feel familiar within an hour. The documents are the same ones you already exchange: purchase order, acknowledgment, ship notice, invoice. What changes is the punctuation, the envelope, the names, and the way versions are labelled.

This guide covers the history, the syntax, the envelope, how to read an interchange step by step, directory versions, the GS1 EANCOM subset most retail partners use, every message family, and a detailed comparison with X12 and with the UK's older TRADACOMS standard. The live example below is a complete, valid interchange you can open in the free [EDIFACT inspector](/edifact-inspector).

<EDIGuideCTA
  badge="For EDIFACT"
  transactionType="850"
  headline="Check an EDIFACT file in seconds"
  body="The free EDIFACT inspector reads UN/EDIFACT, EANCOM and TRADACOMS files, explains every segment, and checks envelopes, segment counts and GS1 check digits. OrderSync processes EDIFACT, EANCOM and TRADACOMS orders alongside X12, PDF, CSV and email, straight into your ERP."
  secondaryHref="/edifact-inspector"
  secondaryLabel="Try the free EDIFACT inspector"
/>

## What is EDIFACT?

**UN/EDIFACT (United Nations/Electronic Data Interchange for Administration, Commerce and Transport) is an international EDI standard developed under the United Nations and published by [UNECE](https://unece.org/trade/uncefact/introducing-unedifact).** It defines three things: syntax rules for structuring data, a library of standard messages (ORDERS, INVOIC, DESADV and about two hundred more), and the data elements and code lists those messages draw on.

In practice, "EDIFACT" covers three layers:

| Layer | What it is | Who maintains it |
|---|---|---|
| Syntax rules | How segments, elements and envelopes are written | UN/CEFACT, published as ISO 9735 |
| Directories | Dated releases of every message, segment and code list (D.96A, D.01B) | UN/CEFACT |
| Subsets and guides | Cut-down versions for one industry, plus each partner's own rules | GS1 (EANCOM), industry bodies, trading partners |

When a UK grocer or a European distributor says "we send EDIFACT", they almost always mean a specific subset plus their own implementation guide on top of it, the same way Walmart's 850 is X12 plus Walmart's rules.

## A short history of EDIFACT

| Year | Milestone |
|---|---|
| Early 1980s | National and UN syntaxes compete. The UK's [TRADACOMS](/guides/edi/tradacoms), launched in 1982, is built on the UN/GTDI syntax, a precursor of EDIFACT |
| 1987 | After the UN and US/ANSI syntax proposals converge, the UN/EDIFACT syntax rules are approved as ISO 9735, according to UNECE's [syntax implementation guidelines](https://unece.org/fileadmin/DAM/trade/edifact/untdid/d4231_s1.htm) |
| 1997 | GS1's retail subset, EANCOM 1997, is published on directory D.96A |
| 2001 | UN/CEFACT releases directory D.01B, the basis of EANCOM 2002 |
| 2017 | GS1 UK ends support for TRADACOMS and backs EANCOM and GS1 XML instead |

Maintenance and development sit with UN/CEFACT, the UN Centre for Trade Facilitation and Electronic Business, under UNECE. New directories are still published, but retail and logistics partners mostly stay on the older ones their systems were built for.

## How to read an EDIFACT interchange, step by step

Faced with a raw file from a new partner, work through it in this order. The live example further down follows the same steps.

1. **Find the separators.** If the file starts with `UNA`, the next six characters declare the separators. If not, assume the defaults: `:` `+` `.` `?` space `'`.
2. **Read the UNB.** It tells you the character set (`UNOA`, `UNOC`), syntax version, sender, recipient, date and the interchange control reference.
3. **Split the messages.** Each `UNH` starts a message and names its type and version, for example `ORDERS:D:01B:UN:EAN010`. Each `UNT` ends it.
4. **Read the BGM.** It gives the document code (`220` order, `380` invoice, `351` despatch advice), the document number, and whether it is an original (`9`), a replacement (`5`) or a cancellation (`1`).
5. **Decode the qualifiers.** Most segments are generic. `DTM+137` is the document date, `DTM+2` the requested delivery date. `NAD+BY` is the buyer, `NAD+SU` the supplier, `NAD+DP` the delivery point.
6. **Walk the lines.** Each `LIN` starts an item. The segments after it (`PIA`, `IMD`, `QTY`, `PRI`, `MOA`, `TAX`) belong to that line until the next `LIN` or the `UNS` section control.
7. **Check the controls.** `CNT` totals in the summary, the segment count in `UNT`, and the message count and reference in `UNZ` must all match what is in the file.

## EDIFACT syntax: segments, elements and separators

An EDIFACT file is plain text made of **segments**, each starting with a three-letter tag. Segments contain **data elements**, and some data elements are **composites** made of several **component elements**.

```
NAD + BY + 5012345000008 :  : 9 '
 |     |         |        |  |  |  |
 |     |         |        |  |  |  segment terminator
 |     |         |        |  |  code list agency: 9 = GS1
 |     |         |        |  empty component (code list)
 |     |         |        component separator
 |     |         party identifier: the buyer's GLN
 |     party qualifier: BY = buyer
 segment tag: NAD = name and address
```

The same pattern, a tag followed by a qualifier and a value, runs through the whole standard:

```
DTM + 137 : 20261011 : 102 '
      |     |          |
      |     |          format: 102 = CCYYMMDD
      |     the date
      qualifier: 137 = document date
```

### The service characters

| Character | Role | Default |
|---|---|---|
| Component data element separator | Splits parts of a composite | `:` |
| Data element separator | Splits elements within a segment | `+` |
| Decimal mark | Separates whole and fractional numbers | `.` in EANCOM |
| Release character | Escapes the next character so it is read as text | `?` |
| Segment terminator | Ends a segment | `'` |

### The UNA service string advice

A file can open with a `UNA` segment that declares which characters it uses. It is always exactly nine characters: `UNA` plus six service characters in a fixed order.

```
UNA:+.? '
```

Position by position: `:` component separator, `+` element separator, `.` decimal mark, `?` release character, a space (reserved in syntax version 3), and `'` segment terminator. GS1 adds that the same character must not be used in more than one position.

UNA is optional when a file uses the defaults with character set level A. The EANCOM manual says it must be sent when partners use a character set from B to F with the default separators, which covers the common `UNOC` case in European retail. In syntax version 4, the reserved fifth position becomes the repetition separator.

### The release character

The release character `?` lets a separator appear inside data. A product description of "Salt + Pepper Mill Set" has to be written:

```
IMD+F++:::SALT ?+ PEPPER MILL SET'
```

Without the `?`, a parser would split the description at the `+`. The same applies to `:`, `'` and `?` itself (`??` is a literal question mark). Unescaped apostrophes in names such as "O'Neill" are the most common cause of broken EDIFACT files in UK trade, because the `'` ends the segment mid-name.

### Empty and missing data

The EANCOM manual sets out how empty data is left out:

- **Empty conditional segments are omitted** entirely, tag and all.
- **An empty element in the middle keeps its separator**, so position is preserved: `NAD+BY+5012345000008::9'` has an empty code list component between the two colons.
- **Trailing empty elements are truncated.** The segment ends at the last element with data. Parsers must not assume a fixed element count.
- **Line breaks are not part of the format.** Real files are often one continuous line. Examples on this page put one segment per line for readability, and the inspector accepts both.

### Numbers

EANCOM uses the point as the decimal mark, with at least one digit either side when a decimal is sent. Thousands separators are not allowed: `2500000`, never `2,500,000`. Values are treated as positive. A credit note carries positive amounts and the document code tells the receiver to treat them as negative. Where a negative value is needed, a minus sign goes immediately before the number.

The underlying UN/EDIFACT syntax versions 1 to 3 define the comma as the default decimal mark, which is why `UNA` declares it explicitly. If your partner sends `UNA:+.? '`, the dot is the decimal mark and `1406.40` means what it looks like.

### Character sets

The first part of the UNB syntax identifier names the character set. GS1 recommends level A for EANCOM and asks partners to agree anything else first.

| Identifier | Character set | Covers |
|---|---|---|
| `UNOA` | Level A, ISO 646 subset | Upper case letters, digits, space and basic punctuation |
| `UNOB` | Level B, ISO 646 subset | Level A plus lower case letters |
| `UNOC` | Level C, ISO 8859-1 | Western European languages, including accented letters |
| `UNOD` | Level D, ISO 8859-2 | Central European languages |
| `UNOE` | Level E, ISO 8859-5 | Cyrillic |
| `UNOF` | Level F, ISO 8859-7 | Greek |

## The EDIFACT envelope: UNB, UNG, UNH

EDIFACT nests data in three levels, like X12. The interchange is the outer envelope, an optional functional group sits inside it, and each business document is a message.

```
UNA                      Service string advice (optional)
UNB                      Interchange header
  UNG                    Functional group header (optional, rarely used)
    UNH                  Message header
      BGM, DTM, NAD, LIN ...   the business document
    UNT                  Message trailer: segment count
  UNE                    Functional group trailer
UNZ                      Interchange trailer: message count
```

### UNB: interchange header

```
UNB+UNOC:3+5012345000008:14+5098765000002:14+261011:0915+HLS000451++ORDERS'
```

| Element | Value | Meaning |
|---|---|---|
| Syntax identifier | `UNOC:3` | Character set level C (Latin-1), syntax version 3 |
| Sender | `5012345000008:14` | Sender ID, qualifier `14` = GS1 GLN |
| Recipient | `5098765000002:14` | Recipient ID, also a GLN |
| Date and time | `261011:0915` | YYMMDD:HHMM in syntax version 3 |
| Control reference | `HLS000451` | Unique interchange number, repeated in UNZ |
| Application reference | `ORDERS` | Optional, often the message type inside |

### UNH and UNT: message header and trailer

```
UNH+1+ORDERS:D:01B:UN:EAN010'
...
UNT+26+1'
```

The UNH carries a message reference (`1`) and the message identifier: type `ORDERS`, version `D` (the code for a UN/EDIFACT directory), release `01B`, controlling agency `UN`, and an association code. `EAN010` identifies the EANCOM 2002 version of ORDERS. UNT carries the number of segments in the message **including UNH and UNT themselves**, plus the same message reference.

### UNZ: interchange trailer

```
UNZ+1+HLS000451'
```

The count of messages (or groups, if UNG is used) and the control reference, which must match the UNB. A mismatch here, or a wrong UNT count, is the most common reason a partner rejects an interchange outright.

### UNG and UNE

UNG/UNE functional groups exist in the standard but are optional and uncommon in retail EDIFACT. Most partners send messages directly inside UNB/UNZ. This is a real difference from X12, where GS/GE is mandatory.

## A complete EDIFACT interchange

This is a valid EANCOM purchase order from the fictional UK retailer Harbour Lane Stores to the fictional supplier Kestrel Valley Homeware, with three order lines. GLNs and GTINs are made up, with valid GS1 check digits.

<EdifactSample
  title="EANCOM purchase order, three lines"
  description="UNA, UNB, one ORDERS message with header, three LIN groups and a summary, then UNZ."
  label="EANCOM D01B"
  raw="UNA:+.? '
UNB+UNOC:3+5012345000008:14+5098765000002:14+261011:0915+HLS000451++ORDERS'
UNH+1+ORDERS:D:01B:UN:EAN010'
BGM+220+HL-PO-88231+9'
DTM+137:20261011:102'
DTM+2:20261016:102'
NAD+BY+5012345000008::9'
NAD+SU+5098765000002::9'
NAD+DP+5012345000107::9'
CUX+2:GBP:9'
LIN+1++5098765100016:SRV'
PIA+1+KV-1001:SA'
IMD+F++:::BAMBOO CHOPPING BOARD LARGE'
QTY+21:120'
PRI+AAA:6.50'
LIN+2++5098765100023:SRV'
PIA+1+KV-1002:SA'
IMD+F++:::SALT ?+ PEPPER MILL SET'
QTY+21:60'
PRI+AAA:9.80'
LIN+3++5098765100030:SRV'
PIA+1+KV-1003:SA'
IMD+F++:::COTTON TEA TOWEL 3 PACK'
QTY+21:48'
PRI+AAA:2.25'
UNS+S'
CNT+2:3'
UNT+26+1'
UNZ+1+HLS000451'"
/>

Read it with the seven steps above. The separators are the defaults, declared in `UNA`. The `UNB` says Latin-1, syntax 3, from one GLN to another. The single `UNH` is an EANCOM 2002 ORDERS. `BGM+220` is an original purchase order, `DTM+137` its date and `DTM+2` the delivery date requested. Three `LIN` groups each carry a GTIN, the supplier's own code (`PIA+1`), a description, the ordered quantity (`QTY+21`) and a net price. `CNT+2:3` confirms three lines, `UNT+26` counts 26 segments, and `UNZ+1` closes one message with the same reference as the `UNB`.

The [EDIFACT ORDERS guide](/guides/edi/edifact-orders) walks through every segment in this message.

## EDIFACT directories: D96A, D01B and the rest

EDIFACT messages are versioned by **directory**. A directory is a dated release of every message, segment, data element and code list, named by year and release letter: `D.96A`, `D.01B`, `D.21A`.

| | D.96A | D.01B |
|---|---|---|
| Released | 1996 | 2001 |
| EANCOM edition | EANCOM 1997 | EANCOM 2002 (syntax 3 and 4 editions) |
| UNH example | `ORDERS:D:96A:UN:EAN008` | `ORDERS:D:01B:UN:EAN010` |
| Status in GS1 | Replaced by EANCOM 2002 | The current EANCOM standard |
| Where you meet it | Long-running retail links that never upgraded | Most current retail and FMCG partners |

What this means in practice:

- **Your partner picks the directory.** It appears in every UNH. You map to what they send, not to the newest release.
- **Old directories stay in production for decades.** D.96A and D.01B are the two you will see most in retail, because the two main EANCOM editions are built on them.
- **Differences between directories are usually small** for core messages, but code lists and segment groups do move. A map built for D.96A ORDERS will not always read D.01B cleanly.

## EANCOM and GS1

[GS1 EANCOM](https://www.gs1.org/edi/eancom/s3) is GS1's subset of UN/EDIFACT for retail and consumer goods supply chains. GS1 describes EANCOM 2002 as a subset of selected messages from directory D.01B, including only the parts that are mandatory or relevant to GS1 users. It requires GS1 identifiers throughout: GLNs for parties and locations, GTINs for products, SSCCs for pallets and cartons.

EANCOM 2002 replaced EANCOM 1997 (built on D.96A) and exists in a syntax version 3 and a syntax version 4 edition. Each EANCOM message carries its own subset version number, `EAN` plus three digits, at the end of the UNH message identifier. In EANCOM 2002 syntax 3:

| Message | EANCOM version | Message | EANCOM version |
|---|---|---|---|
| ORDERS | `EAN010` | INVOIC | `EAN011` |
| ORDRSP | `EAN009` | RECADV | `EAN008` |
| ORDCHG | `EAN007` | PRICAT | `EAN009` |
| DESADV | `EAN007` | INVRPT | `EAN007` |
| APERAK | `EAN003` | SLSRPT | `EAN007` |

If a UK or European retailer sends you an "EDIFACT spec", expect an EANCOM-based guide with their own mandatory segments and codes layered on top.

## EDIFACT message families

The EANCOM 2002 syntax 3 edition alone has 46 messages. These are the ones a retail or wholesale supplier meets most, grouped by the job they do. The [EDIFACT message types reference](/guides/edi/edifact-message-types) lists every message by business flow.

| Flow | Message | What it does | Direction | X12 |
|---|---|---|---|---|
| Ordering | [ORDERS](/guides/edi/edifact-orders) | Purchase order | Buyer to supplier | [850](/guides/edi/850-purchase-order) |
| Ordering | [ORDRSP](/guides/edi/edifact-ordrsp) | Order response: accept, change or reject | Supplier to buyer | [855](/guides/edi/855-purchase-order-acknowledgment) |
| Ordering | [ORDCHG](/guides/edi/edifact-ordchg) | Change to an order already sent | Buyer to supplier | [860](/guides/edi/860-purchase-order-change) |
| Delivery | [DESADV](/guides/edi/edifact-desadv) | Despatch advice: what is on the lorry | Supplier to buyer | [856](/guides/edi/856-ship-notice) |
| Delivery | [RECADV](/guides/edi/edifact-recadv) | Receiving advice: what arrived | Buyer to supplier | [861](/guides/edi/861-receiving-advice) |
| Invoicing | [INVOIC](/guides/edi/edifact-invoic) | Invoice, credit note, debit note | Supplier to buyer | [810](/guides/edi/810-invoice) |
| Acknowledgement | [CONTRL](/guides/edi/edifact-contrl) | Syntax and service report | Either | [997](/guides/edi/997-functional-acknowledgment) |
| Acknowledgement | [APERAK](/guides/edi/edifact-aperak) | Application error and acknowledgement | Either | [824](/guides/edi/824-application-advice) |
| Product | [PRICAT](/guides/edi/edifact-pricat) | Price and sales catalogue | Supplier to buyer | [832](/guides/edi/832-price-sales-catalog) |
| Reporting | [INVRPT](/guides/edi/edifact-invrpt) | Inventory report | Either | [846](/guides/edi/846-inventory-inquiry) |
| Reporting | [SLSRPT](/guides/edi/edifact-slsrpt) | Sales data report | Buyer to supplier | [852](/guides/edi/852-product-activity-data) |
| Payment | REMADV | Remittance advice | Buyer to supplier | [820](/guides/edi/820-payment-order) |
| Planning | DELFOR | Delivery schedule | Buyer to supplier | [830](/guides/edi/830-planning-schedule) |

The mapping to X12 is at the document level. Field-level mapping is never one-to-one: an X12 `PO1` line carries quantity, price and product IDs in one segment, while EDIFACT spreads the same data across `LIN`, `PIA`, `QTY` and `PRI`.

## EDIFACT vs X12

The two standards solve the same problem. The differences are syntax, governance and geography.

| | EDIFACT | X12 |
|---|---|---|
| Governed by | UN/CEFACT (UNECE); syntax is ISO 9735 | ASC X12 (ANSI accredited) |
| Main regions | Europe, UK, Asia, Middle East, global logistics and customs | United States, Canada, Mexico |
| Document names | Six-letter codes: ORDERS, INVOIC | Three-digit numbers: 850, 810 |
| Default separators | `+` element, `:` component, `'` terminator | Set in the ISA, commonly `*`, `>`, `~` |
| Separator declaration | Optional UNA segment | Fixed positions in the ISA |
| Escape character | Release character `?` | None |
| Character set | Declared in UNB (`UNOA`, `UNOC`) | Not declared in the envelope |
| Versioning | Directory (D.96A, D.01B) plus subset version (EAN010) | Version/release (004010, 005010) |
| Functional group | Optional (UNG/UNE) | Mandatory (GS/GE) |
| Segment style | Generic segments with qualifiers (`DTM+137`, `NAD+BY`) | More purpose-built segments (`BEG`, `PO1`, `N1`) |
| Dates | `DTM` with a format code (`102` = CCYYMMDD) | Fixed formats per element (CCYYMMDD) |
| Decimals | Explicit decimal mark | Explicit in `R` fields, implied in `N2` fields such as `TDS01` |
| Credit notes | Same INVOIC message, `BGM+381`, positive amounts | 810 with a credit code, or a separate 812 |
| Syntax acknowledgement | CONTRL | 997 or 999 |
| Business acknowledgement | APERAK, or a response message such as ORDRSP | 824, or 855 |
| Retail identifiers | GLN for parties, GTIN for items (via EANCOM) | Partner-assigned codes, DUNS or GLN for parties, UPC/GTIN for items |
| Typical transport | AS2, SFTP, VAN, and OFTP2 in automotive | AS2, SFTP, VAN |

### Envelope mapping

| Level | EDIFACT | X12 |
|---|---|---|
| Interchange header | UNB | ISA |
| Functional group header | UNG (optional) | GS |
| Message / transaction set header | UNH | ST |
| Message / transaction set trailer | UNT | SE |
| Functional group trailer | UNE (optional) | GE |
| Interchange trailer | UNZ | IEA |

### Same order, both syntaxes

The header of the order above, side by side:

```
X12:      BEG*00*SA*HL-PO-88231**20261011~
EDIFACT:  BGM+220+HL-PO-88231+9'
          DTM+137:20261011:102'
```

X12 packs purpose, type, PO number and date into one `BEG`. EDIFACT splits it: `BGM` for document type (`220` order), number and function (`9` original), and a separate `DTM` for the date with a qualifier (`137` document date) and a format code (`102` CCYYMMDD). Our [UBL vs X12 vs EDIFACT comparison](/guides/e-invoicing/ubl-vs-x12-vs-edifact) adds the Peppol UBL column if you also deal with e-invoicing.

## EDIFACT vs TRADACOMS

UK suppliers sometimes meet both. [TRADACOMS](/guides/edi/tradacoms) is the UK retail standard from 1982 that EANCOM is replacing.

| | EDIFACT / EANCOM | TRADACOMS |
|---|---|---|
| Scope | International | UK only, sterling and UK VAT |
| Status | Actively maintained | No longer developed; GS1 UK support ended 2017 |
| Envelope | `UNB` / `UNZ`, messages in `UNH` / `UNT` | `STX` / `END`, messages in `MHD` / `MTR` |
| Tag separator | `+` (`NAD+BY`) | `=` (`CDT=`) |
| Structure | Each message stands alone | Files of header, detail and trailer messages |
| Numbers | Explicit decimal point | Implied decimals set per field |

The free [EDIFACT inspector](/edifact-inspector) reads both, and the [TRADACOMS file types reference](/guides/edi/tradacoms-file-types) lists every TRADACOMS file.

## Other standards you may meet

GS1 UK's [EDI guidance for new users](https://www.gs1uk.org/sites/default/files/EDI_guidance_for_new_users.pdf) lists the standards around EDIFACT that UK companies run into. Two matter outside retail:

- **ODETTE**, a regional standard for Europe's automotive industry.
- **VDA**, an automotive standard used mainly in Germany.

If an automotive customer asks for EDI, ask which of these it means before assuming EANCOM.

## Who uses EDIFACT

- **UK retail and consumer goods.** UK grocers and retailers trade in EANCOM, and some still run TRADACOMS alongside it. Each publishes its own requirements: see our pages for [Tesco](/edi-compliance/tesco), [Sainsbury's](/edi-compliance/sainsburys), [Asda](/edi-compliance/asda), [Morrisons](/edi-compliance/morrisons), [Ocado](/edi-compliance/ocado), [Waitrose](/edi-compliance/waitrose), [Marks & Spencer](/edi-compliance/marks-and-spencer), [Boots](/edi-compliance/boots) and the [Co-op](/edi-compliance/co-op).
- **Continental Europe.** EDIFACT is the usual EDI syntax for retail, wholesale and manufacturing across the EU, supported by national GS1 organisations.
- **Global logistics, customs and transport.** Carriers, ports and customs authorities use EDIFACT messages such as IFTMIN and IFTSTA, wherever their customers are based.
- **Multinationals.** A US company with European subsidiaries often runs X12 with US customers and EDIFACT with European ones from the same ERP.

## How to start trading EDIFACT

1. **Get the partner's implementation guide.** Confirm the subset (usually EANCOM), the directory (D.96A or D.01B), the syntax identifier (`UNOA`, `UNOC`) and the message list.
2. **Get GS1 identifiers in place.** Most EANCOM partners require your GLN in the UNB and NAD segments and GTINs on every line. A UK supplier gets these from GS1 UK.
3. **Agree the transport.** AS2 and SFTP are common; some partners still use a [VAN](/glossary/value-added-network-van).
4. **Map once to your ERP data model**, not per message. Customer, product and unit-of-measure mapping is the expensive part, and it is shared with your X12 flows. See [ERP EDI integration](/guides/edi/erp-edi-integration).
5. **Test with real files.** Paste the partner's samples into the [EDIFACT inspector](/edifact-inspector) to check envelopes, counts and escapes before you go live.

## Frequently Asked Questions

### What does EDIFACT stand for?

EDIFACT stands for Electronic Data Interchange for Administration, Commerce and Transport. The full name of the standard is UN/EDIFACT because it is developed under the United Nations and published by UNECE. Its syntax rules are the international standard ISO 9735.

### Is EDIFACT the same as EANCOM?

No. EANCOM is a subset of EDIFACT maintained by GS1 for retail and consumer goods. Every EANCOM message is a valid UN/EDIFACT message, but EANCOM removes segments that retail does not use, restricts code lists, and requires GS1 identifiers (GLN, GTIN, SSCC). Most European retail partners trade EANCOM, not raw UN/EDIFACT.

### What is the difference between D96A and D01B?

They are two releases of the UN/EDIFACT directories, from 1996 and 2001. EANCOM 1997 is built on D.96A and EANCOM 2002, the current GS1 edition, on D.01B. Your partner's UNH tells you which one they use.

### Is EDIFACT harder than X12?

No, once you know the separators. EDIFACT uses more generic, qualifier-driven segments (one `DTM` segment for every kind of date), so messages have more segments than the X12 equivalent. The optional UNA, the release character and the dropped trailing elements are the parts X12 teams most often get wrong.

### Can one EDI system handle both EDIFACT and X12?

Yes. Both standards carry the same business documents, so the work splits into a syntax layer (parsing and generating each format) and a business layer (orders, products, customers) that is shared. OrderSync supports EDIFACT, EANCOM and TRADACOMS alongside X12, PDF, CSV and email, through the same pipeline into your ERP.

### What is the EDIFACT equivalent of the 997?

CONTRL, the syntax and service report message. Like the 997, it reports whether an interchange or message was received and parsed, not whether the business content was accepted. Business-level rejections in EDIFACT usually travel as APERAK or as a response message such as ORDRSP.

### Which EDIFACT version should I use?

The one your trading partner specifies. Retail partners mostly use EANCOM 2002 (D.01B) or EANCOM 1997 (D.96A). The version is in the UNH segment of every message they send, so a sample file tells you the answer.

### Why does my EDIFACT file fail with an apostrophe in a name?

The apostrophe is the default segment terminator, so "O'Neill" ends the segment after the O. Escape it with the release character: `O?'NEILL`. The same goes for `+`, `:` and `?` inside data.

## Related guides

- **[EDIFACT message types](/guides/edi/edifact-message-types)**: every EDIFACT message, grouped by business flow
- **[EDIFACT ORDERS](/guides/edi/edifact-orders)**: the purchase order message, segment by segment
- **[EDIFACT ORDRSP](/guides/edi/edifact-ordrsp)** and **[ORDCHG](/guides/edi/edifact-ordchg)**: responses and changes
- **[EDIFACT DESADV](/guides/edi/edifact-desadv)** and **[RECADV](/guides/edi/edifact-recadv)**: despatch and receipt
- **[EDIFACT INVOIC](/guides/edi/edifact-invoic)**: the invoice, including VAT
- **[EDIFACT CONTRL](/guides/edi/edifact-contrl)** and **[APERAK](/guides/edi/edifact-aperak)**: acknowledgements
- **[TRADACOMS](/guides/edi/tradacoms)**: the older UK retail standard still in use
- **[EDI order lifecycle](/guides/edi/edi-order-lifecycle)**: how the X12 documents connect, which maps directly onto EDIFACT

## Sources

- [Introducing UN/EDIFACT](https://unece.org/trade/uncefact/introducing-unedifact), UNECE
- [UN/EDIFACT syntax implementation guidelines](https://unece.org/fileadmin/DAM/trade/edifact/untdid/d4231_s1.htm), UNECE
- [UN/EDIFACT syntax rules (ISO 9735)](https://unece.org/trade/uncefact/unedifact/part-4-chapter-22-syntax-rules), UNECE
- [EANCOM 2002 syntax 3 manual](https://www.gs1.org/edi/eancom/s3), including [Part 1 syntax rules](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part1/part1_05.htm) and the [message list](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/part2toc.htm), GS1
- [GS1 EDI standards](https://www.gs1.org/standards/edi), GS1
- [EDI guidance for new users](https://www.gs1uk.org/sites/default/files/EDI_guidance_for_new_users.pdf), GS1 UK

Paste any EDIFACT file into the free [EDIFACT inspector](/edifact-inspector) to check its envelope and segment counts, or use the [X12 EDI inspector](/edi-inspector) for your US partners.