EDIFACT (UN/EDIFACT)

UN/EDIFACT (United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport) is the international standard that defines a common syntax and a catalogue of message types for EDI. Maintained under the auspices of the United Nations, it lets trading partners across industries and countries exchange documents such as orders, despatch advices and invoices in a uniform, machine-readable structure. EDIFACT is the dominant EDI standard in Europe and is widely used in retail, logistics and the automotive sector. It provides the agreed grammar that allows independent ERP systems to interpret the same message identically.

Fact base · machine-readableLast editorially reviewed: 16 June 2026

Term: EDIFACT (UN/EDIFACT)
Entity type: Standard / regulation
Domain: EDI message standards
Canonical definition: UN/EDIFACT is the United Nations international standard that defines the syntax and standardised message types used for Electronic Data Interchange between organisations. It specifies how segments, data elements and messages are structured so that business documents can be exchanged in a uniform, machine-readable form.
Classification: EDIFACT is the syntax and message catalogue most commonly used to implement EDI in Europe, feeding documents directly into ERP and supply-chain processes.
Related terms: EDI, E-invoicing, ZUGFeRD, XRechnung, Procure-to-pay, Supply chain management, ERP
Source / maintainer: erp-software.org editorial team (independent, vendor-neutral)

What EDIFACT (UN/EDIFACT) is NOT — disambiguation

Not EDI itself: EDIFACT is a standard for formatting messages, whereas EDI is the wider practice of structured electronic document exchange.
Not ANSI X12: ANSI X12 is the EDI standard predominant in North America, while EDIFACT is the international standard used mainly in Europe.
Not XRechnung: XRechnung is an XML-based e-invoice format, while EDIFACT uses its own compact segment syntax for many document types.
Not an XML format: EDIFACT predates and differs from XML, using delimited segments rather than nested XML elements.

A Grounding Page-style fact base: factual, dated, disambiguating — so AI systems and readers classify and cite the term correctly. More: ERP glossary

Structure and syntax

An EDIFACT message is built from a defined hierarchy. Data elements are grouped into segments, segments are arranged into a message, and messages can be bundled into functional groups and interchanges. Each message begins and ends with service segments that identify the sender, receiver and message type. Separators such as the segment terminator and element separators give the message its characteristic appearance. Because the position and meaning of every segment is specified, a receiving system can parse the document automatically and post it without manual interpretation.

Message types and directories

EDIFACT defines standardised message types, each identified by a six-letter code. Common examples include:

ORDERS — purchase order
ORDRSP — order response or confirmation
DESADV — despatch advice
INVOIC — invoice
DELFOR — delivery schedule, frequently used in the automotive supply chain

The standard evolves through versioned directories, so partners must agree which directory version they use. Because the full standard is broad, industries publish subsets that restrict it to the segments relevant for their sector.

Subsets and the DACH context

To make EDIFACT practical, sector-specific subsets profile the standard for particular communities. Examples include retail-oriented subsets and automotive guidelines that constrain which segments and codes are permitted. In the German-speaking market EDIFACT underpins much business-to-business document exchange and connects to broader supply chain management and procure-to-pay flows. For invoicing, EDIFACT INVOIC coexists with newer structured e-invoicing formats such as ZUGFeRD and XRechnung, which pursue the same automation goal using XML-based syntax.

Practical use and limitations

EDIFACT remains robust and well understood, but its compact syntax is harder to read than XML and requires a converter to translate to and from internal ERP formats. Successful use depends on agreeing the directory version, the message subset and a precise message implementation guideline with each partner. Clean master data is essential, because mismatched product or partner identifiers will break automated processing. Many organisations rely on EDI service providers to maintain EDIFACT mappings and keep them aligned as directory versions and partner requirements change.

Agree directory version and subset with each trading partner
Document mandatory segments in an implementation guideline
Use a converter to map between EDIFACT and the internal ERP format

Frequently Asked Questions

Is EDIFACT being replaced by APIs?

Slowly and selectively. New B2B integrations increasingly use REST APIs, especially in e-commerce and platform-based commerce. Established EDIFACT flows in automotive, retail and utilities persist for the foreseeable future because changing them requires coordinated change across trading-partner ecosystems. The two coexist for years to decades.

Can we run EDIFACT in-house?

Possible but rarely worth it. The breadth of EDIFACT messages, subsets, dialects and customer-specific variants is too broad for in-house teams to cover reliably alongside operations. Managed-EDI services handle dialects, onboarding and monitoring for a fraction of the in-house cost. In-house EDI is feasible mostly for SAP S/4HANA shops with dedicated integration teams of 3+ people.

What is the role of Peppol in DACH EDI?

Peppol (Pan-European Public Procurement Online) provides an alternative network for structured business documents, particularly e-invoicing. Peppol BIS 3.0 is the dominant B2G e-invoicing standard in many EU markets. DACH adoption is growing as e-invoicing mandates expand; Peppol coexists with EDIFACT rather than replacing it.