What is EDI and What Does it Stand For?

In our global business world, smooth communication between business partners is one of the most important criteria for conducting worldwide trade in its current form. To achieve this, EDI (Electronic Data Interchange) was introduced with the goal of electronically exchanging business documents such as product master data, orders, delivery notes, and invoices.

Edward Guilbert is considered the father of electronic data exchange, having implemented EDI in the supply chains of the U.S. transportation industry as early as the 1960s. To enhance the global reach of the technology, UN/EDIFACT EDI was created by the United Nations in 1985. These documents are exchanged as structured data without manual intervention.

Compared to paper-based processes, EDI has the key advantage of automated processing with a very low error rate and the ability to automatically import EDI messages into the company’s ERP system (Enterprise Resource Planning).

What is EDIFACT?

UN/EDIFACT stands for United Nations rules for Electronic Data Interchange for Administration, Commerce, and Transport. It includes internationally agreed standards, directories, and guidelines for the electronic exchange of structured data between independent computerized information systems worldwide.

EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) consists of a hierarchical structure, with the top level referred to as an interchange. An EDIFACT message is a complete, structured sequence of data representing a single business transaction, such as an order. The UN/EDIFACT syntax is defined in the ISO 9735 standard. It includes more than 200 different message types and is now used by over 300,000 companies worldwide.

EANCOM – A Subset of EDIFACT

EANCOM® (EAN + Communication) is a globally valid message standard that allows for the electronic exchange of business data across industries and countries. It is the most widely used global standard for EDI. A special feature of EANCOM® is its use of global GS1 identification standards, such as:

GLN – uniquely identifies companies or company units such as locations or warehouses.

GTIN – uniquely identifies articles, products, or variants worldwide.

SSCC/NVE – an 18-digit number for transport units like pallets or shipping cartons. In Germany, it's also known as NVE (shipment unit number).

More information can be found on the GS1 Germany website: www.gs1-germany.de

In the EANCOM subset, only the required segments from the underlying UN/EDIFACT standard are used. The particular features of a subset are the industry-specific qualifiers. These extend the standard with the common and necessary specifications used in the respective industry.

The EANCOM® standard was originally designed to meet the needs of the consumer goods industry. Today, however, the EDI standard is cross-industry. Examples include healthcare, logistics, fashion, eCommerce, or cash logistics. 

EANCOM (EAN + Communication) stands for detailed descriptions of simplified EDIFACT messages that users can easily understand and implement in practice. GS1 is responsible for the ongoing development of the EDIFACT subset EANCOM®.

• EANCOM includes all GS1 identification standards (e.g., GLN & GTIN), making it highly valuable for standardizing electronic data exchange.
• It enables direct electronic processing upon receipt of the data, with immediate access to the transmitted information in the shortest processing time.
• Advantages of international corporate communication using a standardized data structure.
• The electronic transmission ensures high data consistency compared to manual entries in ERP systems and eliminates the need for extensive control processes to approve the data. 
• Noticeable reduction in administrative and personnel effort as well as postage and shipping costs.

Structure of a Transmission File

A simple transmission file consists of a payload header segment and the payload data. These can be roughly interpreted as an envelope with sender and recipient, along with the actual content.

These segments always begin with “UN” and are called service segments. Each segment, similar to an XML structure, defines a start and end for logically grouped data.

UNB as the start and UNZ as the end (this is the envelope)

UNH as the start and UNT as the end (this is the full message)

Additionally, UNS within the UNH–UNT range serves as a section control segment. Depending on the message type, there may be control segments or not.

Within UNH–UNT, the message is divided depending on the message type into three parts:

• A header section, which relates to the entire message.

• A line item section, where the data applies only to the specific item.

• A summary section, which includes segments such as total number of order lines or total invoice amount.

Additionally, there is the possibility to use an extended character set. Most trading partners do this and indicate it by placing a UNA segment in front of the actual message. This explicitly indicates the use of standard separators within the message.

Payload Segments

There are many identifiers for payload segments that provide general information, and qualifiers that define the specific meaning or association of the transmitted data. In addition, there are code values that describe the function of the message.

Two example segments for clarification:

DTM+137:20250502:102‘
DTM		= Bezeichner für das Segment – Datum/Uhrzeit/Zeitspanne-
+		= Trennzeichen
137		= Qualifier der festlegt, dass es sich um das Dokumentendatum handelt
:		= Trennzeichen
20250502	= Datum, wann der Beleg erstellt wurde
: 		= Trennzeichen
102		= Code der festlegt, wie das Format des Datums anzugeben ist.
‚		= Segmentende Kennzeichen

BGM+220+2334583161+9'
BGM		= Bezeichner für das Segment – Beginn der Nachricht-
+		= Trennzeichen
220		= Qualifier der festlegt, dass es sich um eine Bestellung handelt
+		= Trennzeichen
2334583161	= Auftragsnummer der Bestellung oder Bestellnummer
+		= Trennzeichen
9		= Code für Original
‚		= Segmentende Kennzeichen

Example of a Simple EANCOM ORDERS Message with Two Items

UNA:+.? '	  
UNB+UNOC:3+4888885550836:14+9898999999999:14+250424:1312+16984+++++EANCOM'
UNH+001+ORDERS:D:96A:UN:EAN008'		Referenznummer der ORDERS lautet 001 und Versionsangaben
BGM+220+4700483161+9'			Die Bestellnummer lautet 4700483161
DTM+137:20250424:102'			Das Belegdatum ist der 24.04.2025
DTM+2:20250429:102'				Der Liefertermin soll der 29.04.2025 sein
NAD+BY+4888885550836::9'			Die eindeutige GLN des Bestellers
NAD+SU+9898999999999::9'			Die eindeutige GLN des Lieferanten
NAD+DP+4888885551234::9'			Die eindeutige GLN des Warenempfängers (z.B. ein Lager)
NAD+IV+4888885550001::9'			Die eindeutige GLN an dem die Rechnung zu Auszustellen ist
CUX+2:EUR:9'					Währungsangabe
LIN+1++9898942116455:EN'			Erste Position mit der eindeutigen Artikel GTIN 9898942116455
PIA+1+77315-705:SA'				Interne Artikelnummer des Lieferanten 77315-705
IMD+F++:::BLUSE/BLOUSES'			Artikelbeschreibung
QTY+21:36:PCE'					Menge der Bestellten Artikel ist 36
PAC++1'					Packstück/Verpackung
LIN+2++9898912548068:EN'			Zweite Position mit der eindeutigen Artikel GTIN 9898912548068
PIA+1+77315-732:SA'				Interne Artikelnummer des Lieferanten 77315-732
IMD+F++:::HOSE/PANTS'			Artikelbeschreibung
QTY+21:60:PCE'					Menge der Bestellten Artikel ist 60
PAC++1'					Packstück/Verpackung
UNS+S'						Abschnitts Kontrollsegment
UNT+21+001'					Nachrichtenende, es gibt 21 Segmente inkl. UNH-UNT  
UNZ+1+16984'					Ende, es befindet sich eine Nachricht im Umschlag 16984 

Data Transmission

There are various ways to transmit EDI data. The most commonly used are: AS2 (Applicability Statement 2) – an HTTP-based protocol X.400 (BusinessMail) – a message transfer system from Deutsche Telekom Secure connections like SFTP, SCP, OFTP, etc., are also used based on bilateral agreements.

EDI Internally or Externally?

A company can build its own EDI department that, in cooperation with the internal IT department, defines interfaces from internal systems and develops corresponding mappings. These mappings generate EDI messages on output, which are then sent to partners using an agreed-upon communication method. Incoming EDI messages from partners are converted via mappings into the company’s internal format so they can be automatically read and processed. As businesses constantly adapt to market conditions or change internal processes or systems, there are often ongoing EDI projects that require updates to these interfaces. How many employees are needed to build such an internal department (handling customer contact, support, and IT services) is a key factor in deciding whether to pursue this option.

An external solution, which many companies choose, has the advantage of not requiring internal infrastructure. The EDI service provider takes over all tasks necessary for electronic data exchange with partners. Through analysis, the provider identifies the company’s internal interfaces without requiring changes. They usually have their own converter systems, which translate the captured data into the agreed EDI formats and send them to the appropriate partners. The receipt of partner data is processed in reverse, and the converted data is handed off to the internal interface. The provider handles communication between the company and its partners, as well as support services.

Conclusion:

This brief explanation of EDI, EDIFACT, and EANCOM represents only a small part of the entire topic and provides a quick overview of the world of electronic data exchange. It shows the potential for simple and secure data exchange between customers and suppliers, allowing companies to process received data without manual handling. EDI offers highly efficient and diverse use cases and can lead to significant cost savings in data processing. Comprehensive consulting by EDI specialists and a follow-up analysis of internal company workflows, current data handling, and systems is highly recommended before implementation. There are many key factors to consider when introducing EDI, such as: how many partners will exchange data, which message types will be used, the number of messages exchanged per day or month, how many interfaces are needed, etc. This analysis can also help determine whether an internal or external solution will achieve the best efficiency.