EDIFACT
EDIFACT is an international UN standard that defines how companies exchange structured business documents such as orders, dispatch advices and invoices electronically and machine-readably between their systems, without manual data entry.
EDIFACT is an international, vendor-neutral standard that defines the structure and syntax of electronic business documents, so that companies can exchange orders, order confirmations, dispatch advices and invoices between their IT systems without media breaks. The name is an acronym for "Electronic Data Interchange For Administration, Commerce and Transport". The standard is developed and maintained under the umbrella of the United Nations (UNECE, or UN/CEFACT), which is why it is also referred to as UN/EDIFACT. The underlying syntax is laid down in the international standard ISO 9735.
EDIFACT is therefore the most widespread form of electronic data interchange (EDI): instead of emailing an order as a PDF or typing it into a portal, the sender system generates a strictly structured message that the receiver system can read in and post automatically. Because both sides use the same set of rules, the recipient interprets every field unambiguously – from the article and the quantity to the price. EDIFACT describes the document format and its structure, not the transmission path; for transport, protocols such as AS2, OFTP2 or SFTP are used.
At a glance
- International UN standard for the structured, electronic exchange of business documents (EDI)
- Acronym for "Electronic Data Interchange For Administration, Commerce and Transport"; syntax per ISO 9735
- Built from segments, data elements and delimiters; documents are called message types such as ORDERS or INVOIC
- Industry subsets such as EANCOM (retail) and VDA/ODETTE (automotive) make the standard more specific
- Format of the document, not the transport path – transmitted via AS2, OFTP2, X.400 or SFTP
How does EDIFACT work?
An EDIFACT message is not a file to be read, but a compact character string following fixed rules. It is structured hierarchically: the outer wrapper is the interchange (UNB/UNZ), which carries one or more messages; each individual message is enclosed by a header segment (UNH) and a trailer segment (UNT). In between sits the actual content. Because everything is processed purely by machine, the format dispenses with any graphical presentation – readability is handled by the software, not by a human.
Segments, data elements and delimiters
The smallest building block is the data element, for example an article number or an amount. Several data elements form a segment with a fixed meaning – for instance BGM (document header with document type and number), NAD (name and address of a party), LIN (line item) or MOA (monetary amount). The parts are separated by defined delimiters: the plus sign separates data elements, the colon separates components within an element, and an apostrophe terminates the segment. A question mark serves as a release character to mark a delimiter as ordinary text by way of exception. Which segments are permitted in which order is specified by the respective message type from a semi-annually updated directory (for example D.96A).
Message types such as ORDERS and INVOIC
For every business transaction there is a dedicated message type with a self-explanatory abbreviation. The most important are ORDERS (purchase order), ORDRSP (order confirmation), DESADV (dispatch advice), INVOIC (invoice) and PRICAT (price and article catalogue); in retail, DELFOR (delivery schedule) and RECADV (receiving advice) are added. Each type defines exactly which fields are mandatory and which are optional. In this way, a chain of ORDERS, ORDRSP, DESADV and INVOIC maps the complete ordering, delivery and invoicing process between two partners purely electronically.
Why EDIFACT matters
The central benefit of EDIFACT lies in automating recurring document processes. Where a clerk used to type in orders and check invoices manually, the data now travels straight from the supplier's ERP into the customer's ERP without re-entry. That reduces processing costs, speeds up throughput time and avoids typing errors. Especially in high-volume business – for example retail chains with thousands of order lines per day – a paperless, automated workflow is hard to justify economically without EDI.
On top of this comes the reliability of a globally recognised standard that has been established since the late 1980s. Large retail, automotive and logistics companies often make EDIFACT a condition for doing business: anyone who wants to be listed as a supplier must be able to exchange orders and invoices electronically. EDIFACT is therefore not only an efficiency lever, but in many industries a de facto ticket into the supply chain.
EDIFACT in the ERP system
For an ERP system, EDIFACT is an inbound and outbound channel that connects to the existing document processing. On the outbound side, the data already maintained in the system – supplier, line items, quantities, prices, tax codes – is translated via a mapping into the required EDIFACT structure and handed over to the partner as a message. On the inbound side it works the other way round: an incoming ORDERS message is read in and automatically created as a customer order, and an INVOIC is matched to the open purchase order.
Because almost every partner implements the standard slightly differently, the field mapping is the most demanding part of an integration. In practice, this translation is rarely handled by the ERP alone, but by an EDI converter or an EDI service provider (value-added network) that sits as middleware between the systems. It converts the internal format into EDIFACT and back, checks the syntax and manages the transport protocols. The ERP itself only needs to provide an open interface through which documents are handed over and received in a structured way.
Distinctions: EDIFACT, EDI and modern formats
EDI is the umbrella term for the electronic exchange of structured documents; EDIFACT is the standard that dominates for this in Europe and internationally. Alongside it there are other EDI standards, for example ANSI ASC X12, which is widespread mainly in North America. It is also important to separate format from transport: EDIFACT defines what the document looks like, while protocols such as AS2 or OFTP2 and networks such as Peppol govern how it gets from A to B.
Compared with modern XML- or JSON-based formats, EDIFACT looks technically old-fashioned, but it is extremely compact and in use millions of times over. E-invoicing formats such as XRechnung and ZUGFeRD, or catalogue formats, do not replace EDIFACT but complement it for specific use cases – for instance the legally compliant invoice to public-sector clients. In many companies, EDIFACT for retail logistics and newer formats for compliance therefore run side by side in parallel.
Subsets: EANCOM, ODETTE and VDA
Because the full EDIFACT standard is very extensive and open to ambiguous interpretation, industries have defined their own subsets. The best known is EANCOM from GS1, which is used in retail and integrates numbering systems such as GTIN and GLN for the unambiguous identification of articles and locations. In the automotive industry, ODETTE and the recommendations of the VDA are widespread, and in the electronics sector EDIFICE. A subset sensibly narrows down the standard and makes an integration between partners in the same industry considerably easier.
DACH specifics
In the German-speaking region, EDIFACT is firmly anchored above all in the food and consumer-goods retail sector and in the automotive industry. Retail chains regularly require suppliers to handle transactions via EANCOM, while automotive suppliers exchange delivery schedules and advices via VDA and ODETTE messages. For many mid-sized suppliers, EDI capability is therefore not a nice-to-have but a prerequisite for the contract.
Note the distinction from the e-invoicing obligation: since 2025, new rules for B2B e-invoicing under the EN 16931 standard have applied in Germany: companies must be able to receive structured e-invoices, while the obligation to issue them is phased in from 2027 and 2028 respectively. A plain EDIFACT INVOIC does not automatically meet the requirements for an e-invoice – a compliant format such as XRechnung or ZUGFeRD is required. EDIFACT processes nevertheless remain permissible and customary for logistics; for the invoice itself, companies may need to additionally provide a standard-compliant format. In addition, the GoBD and audit-proof archiving in the original format apply to all documents. This article provides a general overview and does not replace individual tax advice.
Example
Example: beverage wholesaler supplies a supermarket chain
A mid-sized beverage wholesaler is listed as a supplier to a large supermarket chain. The trading partner requires the entire process to be handled via EDIFACT in the EANCOM subset. The wholesaler connects its ERP system through an EDI service provider: a converter translates between the internal document format and the required message types and handles transport via AS2.
When the chain orders goods, an ORDERS message arrives from which the ERP automatically creates a customer order – with the correct articles, addressed via GTIN and GLN. The wholesaler confirms with ORDRSP, announces the delivery via DESADV and issues the invoice as INVOIC. No document is typed by hand, matching happens automatically, and throughput time drops from days to minutes. For a legally compliant invoice to a public-sector customer, the wholesaler additionally provides the XRechnung format.
Frequently asked questions
Matching ERP systems
Related services
Questions about EDIFACT in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.