EANCOM

EANCOM is a GS1-maintained subset of the EDIFACT standard (UN/EDIFACT), retaining only the message elements required by the retail and consumer goods community while mandating GS1 identifiers for unambiguous trading partner and product identification. It is the dominant EDI (Electronic Data Interchange) standard in European and international retail — the equivalent of ANSI X12 in North America.

What EANCOM is

EANCOM derives its name from EAN (European Article Numbering) plus Communication; it was created by GS1 (then EAN International) in 1987 to serve consumer goods trade transactions. (ecosio.com, accessed 2026-07-30)

As opposed to the very extensive UN/EDIFACT standard, EANCOM reduces the various EDI messages to essential fields that are mandatory for specific business processes or for specific message types, including only components that are mandatory and those relevant for the GS1 user community. (support.gs1.org, accessed 2026-07-30)

The key differentiator over plain EDIFACT is that GS1 identifiers are mandatory in every message:

GTIN (Global Trade Item Number) — product identification
GLN (Global Location Number) — sender and recipient identification
SSCC (Serial Shipping Container Code) — package identification

Every sender and recipient will be uniquely identified by its GLN, excluding confusion caused by proprietary identifiers. (support.gs1.org, accessed 2026-07-30) EANCOM also restricts the allowed code lists to those relevant for GS1 users, further constraining the open-ended code sets in full UN/EDIFACT.

Versions

EANCOM is derived from specific UN/EDIFACT directory releases. Three versions are in live use, primarily distinguished by the EDIFACT directory they are based on:

Version	EDIFACT directory	Status
D93A	UN/EDIFACT 1993A	Occasionally encountered; largely superseded
D96A	UN/EDIFACT 1996A	Widely deployed in EU retail (as-of 2026-07-30)
D01B	UN/EDIFACT 2001B	Most recent version; the current GS1 standard base (as-of 2026-07-30)

The two most widely used versions in EU retail are D96A and D01B. D93A may occasionally still occur. (ecosio.com, accessed 2026-07-30)

EANCOM is also published in two syntax variants: Syntax Version 3 (S3) and Syntax Version 4 (S4). S4 adds security features — digital signatures and digital certificates — that are not available in S3. (GS1, EANCOM 2002 Syntax Version 4 Edition 2016; gs1.org/sites/default/files, 2016)

The EANCOM 2002 Manual (the definitive reference, based on UN/EDIFACT directory D.01B) is published by GS1 in a new edition every two years; code lists can be updated up to four times per year. (gs1.org/standards/eancom, accessed 2026-07-30)

Message structure

An EANCOM/EDIFACT transmission is structured hierarchically:

Interchange (UNB / UNZ)          ← outer envelope; identifies sender and recipient
  └── Functional Group (UNG / UNE)  ← optional grouping layer
        └── Message (UNH / UNT)  ← individual business document
              ├── Header section
              ├── Detail section
              └── Summary section

The UNA segment (optional) defines the service characters used in the interchange. The UNB segment is mandatory and carries the sender/recipient GLNs and interchange control reference. (GS1, EANCOM 2002 Syntax Version 4 Edition 2016 Part 1, gs1.org/sites/default/files, 2016)

Message types

EANCOM contains approximately 46–50 message types (exact count varies by edition) spanning four categories. (commport.com, accessed 2026-07-30; ecosio.com, accessed 2026-07-30)

Message type count: commport.com states "46 message types" [https://www.commport.com/eancom-edi-standard/]; ecosio.com states "approximately 50 different message types" [https://ecosio.com/en/blog/eancom-an-example-for-a-edifact-subset/]. The discrepancy likely reflects different editions being counted (some deprecated messages may be excluded in one count). The GS1 official source confirms the four-category structure without giving a single count.

Master Data

Message	Description
PRICAT	Price/Sales Catalogue — supplier communicates product catalogue and pricing to the retailer; enables master data alignment at the start of a trading relationship
PARTIN	Party Information — typically the first message exchanged; associates the GLN with location and operational/administrative/financial data for both parties

(edicomgroup.com, accessed 2026-07-30; gs1.org/standards/eancom/how-gs1-eancom-works, accessed 2026-07-30)

Commercial Transactions

Message	Description
ORDERS	Purchase Order — carries order details (items, quantities, prices); manages the full ordering process from initial proposals through changes and confirmation
ORDRSP	Order Response — supplier acknowledgement of an ORDERS message
INVOIC	Invoice — the buyer-side billing document
DESADV	Despatch Advice (Advance Shipment Notice / ASN) — sent by the supplier before delivery, enabling the customer to plan receiving and production
RECADV	Receiving Advice — sent by the buyer to confirm goods receipt; closes the physical goods-receipt loop

The three most frequently used EANCOM messages in EU retail are ORDERS, DESADV, and INVOIC. (gs1.org/standards/eancom, accessed 2026-07-30)

Large-scale retailers are increasingly mandating use of the DESADV message from their suppliers to enhance traceability of trading operations and optimize the logistics chain. (edicomgroup.com, accessed 2026-07-30) DESADV and RECADV together are described as "the most used in the supply chain" and are said to "favour good results for suppliers, distributors, and end customers." (edicomgroup.com, accessed 2026-07-30)

Transportation & Logistics

Message	Description
IFTMIN	Instruction for Transport (despatch order)
IFTSTA	International Multimodal Status Report (transport status)
IFCSUM	Forwarding and Consolidation Summary

Report & Planning

Message	Description
SLSRPT	Sales Report — commonly used in vendor-managed inventory arrangements; supplier receives sell-through data from the retailer
INVRPT	Inventory Report — daily stock-level data feed; mandatory in most Vendor-Managed Inventory (VMI) arrangements
REMADV	Remittance Advice — notifies the supplier of upcoming payment details, facilitating financial and liquidity planning

(commport.com, accessed 2026-07-30; edicomgroup.com, accessed 2026-07-30; CPFR concept page citing ECR Austria DELFOR/EANCOM data)

Adoption and scale

The following figures are from 2020 (commport.com). No updated 2025–2026 adoption count was found during this research run.

As of 2020, approximately 126,000 companies were implementing EANCOM, and billions of EANCOM messages are exchanged worldwide annually. (commport.com, accessed 2026-07-30, citing 2020 GS1 data)

By comparison, GS1 XML was implemented by approximately 47,000 companies as of a similar period — roughly one-third the EANCOM base — reflecting EANCOM's dominance via installed base. (gs1.ch, accessed 2026-07-30)

EANCOM is particularly prevalent in European consumer goods, retail, healthcare, and construction sectors. Its primary domain is retail and FMCG, where it originated. (support.gs1.org, accessed 2026-07-30; commport.com, accessed 2026-07-30)

EANCOM in EU/DACH retail practice

Christian Gerloff's March 2026 practitioner analysis identifies EANCOM/GS1 as the dominant EDI standard specifically in EU/DACH retail, naming Edeka, REWE, and Lidl as major implementers, and states that EDIFACT is to Europe what X12 is to North America — "the dominant standard for structured document exchange." (gerloff.dev, 2026-03-19)

Procuros (2025) states that without EDI capability, suppliers "cannot meaningfully supply DACH food retail," and that a listing at Edeka requires a mandatory digital EDI connection to the Edeka supplier portal. (procuros.io, 2025)

softzoll.com (unknown publication date) states that REWE Group continues to mandate the X.400 messaging network — a legacy 1980s protocol — as the required EDI transmission path, and that Edeka similarly mandates supplier EDI capability as a precondition for listing. The X.400 claim could not be confirmed by a 2025–2026 source and may be outdated.

Message Implementation Guidelines (MIGs)

Each major retailer publishes its own Message Implementation Guideline (MIG) that customises the base EANCOM standard for their specific requirements. A MIG works by setting optional fields to required — it can only tighten up a standard; no new elements may be added. (ecosio.com, accessed 2026-07-30)

Suppliers must implement per-partner MIGs rather than treating EANCOM as a single universal specification. A supplier with 20 retailer trading partners may need 20 different EANCOM configurations, despite the underlying standard being the same. This per-partner customisation overhead is one of the main implementation cost drivers in EDI. (ecosio.com, accessed 2026-07-30; commport.com, accessed 2026-07-30)

Transmission protocols

EANCOM is format-only — it defines the structure of the message, not how it is transported. The most common transport protocols for exchanging EANCOM messages are:

AS2 (Applicability Statement 2) — HTTPS-based, with encryption and digital signatures; mandated by most major European retailers for direct connections
SFTP/FTPS — widely used, especially for smaller trading partners
Value Added Network (VAN) — managed third-party intermediary acting as a mailbox, with archiving and compliance-checking services; preferred when a supplier has many trading partners with different technical requirements

(commport.com, accessed 2026-07-30)

EANCOM vs GS1 XML

GS1 publishes a parallel XML-based standard (GS1 XML) covering equivalent business processes. Key differences:

Dimension	EANCOM	GS1 XML
Syntax	EDIFACT flat-file (segments/data elements)	XML tree structure
Basis	UN/EDIFACT directory D.01B	GS1 XML schema
Age	1987	2000s onwards
Adoption	~126,000 companies (2020)	~47,000 companies (same period)
Web-native fit	Limited	Better adapted for internet-based technologies

GS1's own architectural analysis notes that the syntaxes are constructed differently and the functionalities are not fully aligned, so there is no simple 1:1 conversion between EANCOM and GS1 XML. (GS1 Compatibility document, 2011; gs1.org/docs/architecture)

The GS1 compatibility architecture document is from 2011. It is cited here as an architectural position statement; the fundamental structural incompatibility between EDIFACT and XML has not changed, but the framing and tooling around it will have evolved.

GS1 XML is described as better adapted for internet-based technologies and particularly beneficial for small and medium-sized enterprises integrating with web-native systems. (gs1.ch, accessed 2026-07-30)

GS1 strategic direction and trajectory

GS1's stated policy is that new message developments for sectors new to GS1 will by default be done only in GS1 XML; existing EANCOM messages will continue to be supported and developed based on user needs, but EANCOM will not expand into new domains. (gs1.ch, accessed 2026-07-30)

GS1 has stated it intends to continue supporting all three EDI formats — EANCOM, GS1 XML, and GS1 JSON/API — for as long as necessary, framing the relationship as complementary rather than EANCOM being deprecated. (gs1.ch, accessed 2026-07-30) No formal end-of-life or sunset timeline for EANCOM has been published.

EANCOM trajectory: GS1's official policy positions XML as the default for new domain development [gs1.ch] and GS1 has endorsed GS1 XML to new EDI implementers as the forward path [gs1.org/standards/edi]. Commport [commport.com] states EANCOM "continues to stand as a reliable and indispensable platform for B2B communications, poised to remain at the forefront of digital data exchange for decades to come." The vendor claim is aspirational marketing language; the GS1 architectural policy documents represent the standards-body's own strategic direction.

The Gerloff 2026 practitioner analysis observes that EDIFACT (and EANCOM as its retail subset) is to Europe what X12 is to North America, and that both will remain current infrastructure in European retail for the foreseeable future — coexisting with API integrations rather than being replaced by them. (gerloff.dev, 2026-03-19)

EANCOM and EU e-invoicing mandates

EANCOM's role in supply chain EDI (procurement, despatch, goods-receipt, VMI) is a distinct layer from EU fiscal e-invoicing mandates. Regulatory e-invoicing in Europe runs on Peppol (BIS Billing 3.0 / EN 16931) and national formats (XRechnung, ZUGFeRD):

Germany: all companies must be able to receive structured e-invoices from January 2025; sending mandatory from January 2027 (Wachstumschancengesetz). (gerloff.dev, 2026-03-19)
Belgium: full B2B Peppol e-invoicing mandate from 1 January 2026, no size exemptions. (comarch.com, accessed 2026-07-30) (as-of 2026-07-30)
France: receiving-mandatory from September 2026. (fiskaly.com, accessed 2026-07-30) (as-of 2026-07-30)
EU-wide: ViDA (VAT in the Digital Age) adopted March 2025 requires all intra-EU B2B invoices to be structured e-invoices via Peppol by July 2030. (fiskaly.com, accessed 2026-07-30)

These mandates require structured INVOIC-equivalent data via Peppol/EN 16931, but they sit alongside — not instead of — EANCOM's role in the broader order-to-cash supply chain (ORDERS → DESADV → RECADV → INVOIC). Many companies use EANCOM for the full supply chain flow and separately comply with Peppol e-invoicing mandates. (gerloff.dev, 2026-03-19)

Key terms

Term	Meaning
EANCOM	GS1 retail/consumer goods subset of UN/EDIFACT; name from EAN + Communication
MIG	Message Implementation Guideline — per-retailer customisation of the base EANCOM standard
GLN	Global Location Number — unique GS1 identifier for any legal/functional/physical location
GTIN	Global Trade Item Number — unique GS1 identifier for a product/item
SSCC	Serial Shipping Container Code — unique GS1 identifier for a logistic unit (pallet/carton)
D96A / D01B	EDIFACT directory releases that EANCOM versions are based on
S3 / S4	EANCOM syntax versions; S4 adds digital signatures and certificates
DESADV	Despatch Advice / ASN — pre-delivery notification from supplier to customer
RECADV	Receiving Advice — goods-receipt confirmation from buyer to supplier
PRICAT	Price/Sales Catalogue — product and pricing master data message
PARTIN	Party Information — trading partner GLN registration message
INVRPT	Inventory Report — stock-level data; core of VMI data feeds
SLSRPT	Sales Report — sell-through data; also used in VMI arrangements