EDIFACT Explained: Format, Structure, SAP, EDI and E-Invoicing

EDIFACT has been one of the most important standards for the structured electronic exchange of business data between companies for decades. Purchase orders, order confirmations, despatch advices, invoices, payment information and inventory messages can be exchanged automatically between different ERP, merchandise management and logistics systems.

The abbreviation stands for Electronic Data Interchange for Administration, Commerce and Transport. UN/EDIFACT is maintained within the United Nations environment, more specifically by UN/CEFACT. Its fundamental syntax rules are standardised under ISO 9735. The aim is to provide business partners with a common structured language for electronic business messages, regardless of the hardware or software they use.

The EDIFACT format should not be confused with EDI itself. EDI – Electronic Data Interchange – generally refers to the automated electronic exchange of structured business data. EDIFACT, by contrast, is a specific international message standard within the wider EDI ecosystem.

The standard remains particularly important in established B2B processes. Retail, logistics, manufacturing, automotive and energy are among the sectors in which EDIFACT and industry-specific variants have been used for many years. Providers such as SEEBURGER, Magic Software and TrueCommerce continue to identify message types such as ORDERS, ORDRSP, DESADV and INVOIC as key EDIFACT messages.

At the same time, the integration landscape is evolving. XML-based standards, APIs, cloud integration, Peppol and statutory e-invoicing requirements complement traditional EDI architectures. For companies, the key question is therefore not whether EDIFACT is fundamentally “old” or “modern”. What matters is which format is appropriate for a specific business process, trading partner and regulatory context.

This guide therefore answers questions such as: What is EDIFACT? How does the EDIFACT format work? How are EDIFACT documents structured? What roles do ORDERS, ORDRSP, DESADV and INVOIC play? How does SAP IDoc EDIFACT work? What distinguishes EDIFACT and XML? And can an EDIFACT invoice also be used under the current German e-invoicing requirements?

---

Key Facts About EDIFACT

EDIFACT is an internationally standardised set of rules for the structured electronic exchange of business messages. Its syntax is independent of specific ERP systems and enables business partners to exchange purchase orders, deliveries and invoices, for example, without having to enter the data manually again.

The following points are particularly important:

• EDI refers to the broader concept of electronic data interchange; EDIFACT is a specific EDI message standard.
• An EDIFACT format consists of defined messages, segments, data elements, qualifiers and code lists.
• Typical EDIFACT documents include ORDERS for purchase orders, ORDRSP for order responses or confirmations, DESADV for despatch advices and INVOIC for invoices.
• An EDIFACT invoice typically uses the INVOIC message type.
• An EDIFACT order confirmation is represented by ORDRSP in many scenarios.
• SAP IDoc EDIFACT does not describe a single format: A SAP IDoc is typically mapped to EDIFACT via middleware, or vice versa.
• EDIFACT and XML are different syntax models. Middleware can nevertheless convert between the two representations.
• SAP Integration Suite supports B2B/EDI integration and provides, among other capabilities, Integration Advisor and an EDI-to-XML converter for EDIFACT.
• An EDIFACT INVOIC message is not automatically a legally compliant German e-invoice. However, the German Federal Ministry of Finance continues to permit agreed EDI procedures such as EDIFACT if the VAT-relevant information can be extracted correctly and completely.

---

Table of Contents

---

EDIFACT Definition: What Is EDIFACT?

The full EDIFACT definition is:

Electronic Data Interchange for Administration, Commerce and Transport.

UN/EDIFACT provides rules, directories and standardised message types for the electronic exchange of structured business data. UNECE refers, among other things, to standardised message types, the ISO 9735 syntax rules and implementation and message design guidelines.

In simple terms, EDIFACT answers the following question:

How must business information be structured so that two different IT systems can interpret the same message unambiguously?

A purchase order, for example, contains information about the buyer and seller, purchase order number, date, products, quantities and delivery dates.

Without a standard, every company could transmit this information using its own structure. The recipient would then need to interpret an individual format for every trading partner.

The EDIFACT format, by contrast, creates a common technical foundation. Data elements, segments, message types and code values are assigned defined meanings and positions.

EDIFACT can therefore be used regardless of whether the sender and recipient use the same ERP system.

---

What Is the Difference Between EDI and EDIFACT?

The terms EDI and EDIFACT are often used interchangeably. From a technical perspective, this is incorrect.

EDI stands for Electronic Data Interchange and generally refers to the structured electronic exchange of business information between companies or IT systems.

EDIFACT is a standardised message format or set of rules that can be used within such an EDI process.

In simple terms:

EDI = method or integration concept

EDIFACT = specific message standard within EDI

In addition to EDIFACT, there are other EDI standards and structured formats, such as ANSI ASC X12 or industry-specific standards. XML-based business documents can also form part of an EDI architecture. TrueCommerce and Magic Software likewise distinguish between EDI and EDIFACT in this way.

This distinction is important for an integration project.

If a company says:

“We need EDI”,

this does not yet define:

which message types will be used, which format applies, which version is required, which partner-specific requirements exist or which communication channel will be used to transmit the messages.

---

How Does EDIFACT Work in Electronic Data Interchange?

A typical EDIFACT process begins in the sender’s ERP system.

Consider a purchase order as an example.

A buyer creates a purchase order in the ERP system. The internal data structure initially follows the data model of the company’s own system. An EDI or integration platform then takes the relevant business data and maps it to the EDIFACT message type ORDERS.

The message is validated and subsequently transmitted to the supplier via the agreed technical communication channel.

The reverse process takes place on the recipient side:

ERP data → Mapping → EDIFACT → Transmission → EDIFACT → Mapping → Target system

This means that the recipient does not have to manually re-enter the message. The target system can take over the purchase order number, products, quantities, dates and other information in a structured manner.

Entire B2B process chains can be represented electronically in this way.

A typical sequence could, for example, be:

ORDERS → ORDRSP → DESADV → RECADV → INVOIC → REMADV

Each message represents a different business transaction.

---

How Is the EDIFACT Format Structured?

The EDIFACT format is based on a hierarchical structure consisting of data elements, segments, messages and interchanges.

The syntax follows standardised rules. In its traditional representation, EDIFACT uses delimiters rather than verbose XML tags. This makes the messages compact, but comparatively difficult for people to read at first glance.

Data Elements

Data elements are the smallest units of business information.

Examples include:

a product number, date, quantity, currency or price.

Their meaning is determined by their defined position and, where applicable, a qualifier.

Composite Data Elements

Several logically related data elements can be grouped into a composite data element.

A date, for example, may additionally include a format qualifier.

Segments

Segments group logically related business information.

Typical segment names include:

BGM for document information,

DTM for date and time,

NAD for parties involved,

RFF for references,

LIN for line items,

QTY for quantities and

MOA for monetary amounts.

SEEBURGER similarly describes segments as functional groupings of logically related data elements.

Messages

A message groups together all segments relevant to a specific business transaction.

It typically begins with UNH and ends with UNT.

One example is an ORDERS message for a purchase order.

Interchange

The entire data exchange is enclosed within an interchange envelope.

Typical segments include:

UNB for the beginning of the interchange and

UNZ for the end.

Optionally, UNA can be used to define service characters, and group structures can also be included.

---

EDIFACT Example: What Does a Message Look Like?

A deliberately simplified EDIFACT example for a purchase order could look like this:

UNA:+.? ' UNB+UNOC:3+BUYER+SUPPLIER+260915:1200+000001' UNH+1+ORDERS:D:96A:UN' BGM+220+PO12345+9' DTM+137:20260915:102' NAD+BY+123456789::9' NAD+SU+987654321::9' LIN+1++ABC123:SA' QTY+21:10:PCE' UNT+8+1' UNZ+1+000001'

This EDIFACT example is intended solely to demonstrate the structural principle. It is not a complete production-ready partner message.

UNB opens the interchange.

UNH starts the specific message and identifies it here as ORDERS.

BGM contains key document information.

DTM transports date information.

NAD identifies the parties involved.

LIN starts a line item.

QTY contains the corresponding quantity.

UNT closes the message.

UNZ closes the interchange.

A real project involves significantly more business rules. Important factors include the agreed EDIFACT version, the subset being used, partner qualifiers, code lists, mandatory and optional fields, and the specific Message Implementation Guideline.

A technically readable message is therefore not automatically correct from a business perspective for a specific trading partner.

---

Which EDIFACT Documents and Message Types Exist?

In practice, the term EDIFACT documents generally refers to standardised message types.

Some of the most widely used include:

EDIFACT Message	Meaning	Typical Business Process
ORDERS	Purchase order	Procurement / Sales
ORDRSP	Order response	Order confirmation / Response to purchase order
ORDCHG	Purchase order change	Procurement
DESADV	Despatch advice	Logistics
RECADV	Receiving advice	Logistics / Procurement
INVOIC	Invoice	Finance / Billing
REMADV	Remittance advice	Finance
PRICAT	Price list / Catalogue	Procurement / Sales
DELFOR	Delivery schedule / Forecast	Supply Chain
DELJIT	Just-in-Time delivery schedule	Automotive / Supply Chain
CONTRL	Control / acknowledgement message	Technical EDI processing

SEEBURGER, Magic Software and TrueCommerce continue to identify these message types as typical components of EDIFACT-based EDI processes.

However, the specific meaning within an individual project always depends on the agreed profile.

---

EDIFACT Order Confirmation: Which Message Is Used?

For the secondary keyword EDIFACT order confirmation, the ORDRSP message type is particularly relevant.

ORDRSP stands for Purchase Order Response or Order Response.

The message is used to respond to a previously received purchase order. Depending on the agreed implementation, a supplier can use it to confirm, amend or otherwise respond to individual elements of the order.

A typical process is:

Buyer → ORDERS → Supplier

followed by:

Supplier → ORDRSP → Buyer

It is important not to implement an EDIFACT order confirmation based solely on the name of the message.

The qualifiers used, the deviations permitted and the way in which line items are confirmed must be clearly defined between the business partners or within the relevant industry profile.

This is particularly important in automated processes. An order confirmation containing a changed quantity or delivery date should not necessarily be processed in the same way as a complete confirmation without deviations.

---

EDIFACT Invoice: How Does INVOIC Work?

An EDIFACT invoice is typically represented using the INVOIC message.

INVOIC can transport structured invoice information such as document identification, invoice date, supplier and customer, currency, references, line items, quantities, prices, taxes and totals.

This enables an invoice to be processed by a system without the information having to be manually extracted from a visual document.

The typical principle is:

ERP/Billing → Mapping → EDIFACT INVOIC → Transmission → Mapping → ERP/Accounts Payable

However, this does not mean that every INVOIC message automatically meets all statutory requirements for an e-invoice.

Regulatory assessment must be performed separately from purely technical EDIFACT compliance.

This is particularly important since the introduction of Germany’s B2B e-invoicing requirements.

---

What Role Do EDIFACT Versions, Directories and Subsets Play?

The EDIFACT format is not a static schema that looks identical for every organisation.

UN/EDIFACT works with directories or directory releases. One commonly encountered designation is, for example, D.96A.

In addition, defined subsets or implementation guidelines are used in different industries.

A well-known example is EANCOM, which adapts the extensive EDIFACT standard to the requirements of consumer goods and retail. In the German energy market, EDIFACT-based processes also exist within the Edi@Energy environment. SEEBURGER and Magic Software describe such industry-specific variants as an important aspect of practical implementation.

For a company, the statement

“We support ORDERS”

is therefore not sufficient.

For a reliable integration, at least the following should be clearly defined:

Message type + Directory/version + Subset/profile + Partner MIG + Code lists + Communication channel

A trading partner may, for example, expect ORDERS, but only in a specific directory version and with individually defined mandatory fields.

---

EDIFACT and XML: What Is the Difference?

Searches for EDIFACT XML often reveal a common misunderstanding:

EDIFACT is not XML.

Both approaches can transmit structured business information, but they use different syntax concepts.

Characteristic	EDIFACT	XML
Basic principle	Segments, positions, delimiters	Elements and tags
Representation	Compact	Comparatively verbose
Readability	More difficult for humans	Generally easier to understand
Standardisation	EDIFACT directories / messages	XML schemas and standards based on them
Typical examples	ORDERS, DESADV, INVOIC	UBL, CII, proprietary XML formats
Use cases	Traditional B2B/EDI environments	APIs, e-invoicing, B2B, modern integration

XML is a general-purpose markup language. Standards such as UBL or UN/CEFACT Cross Industry Invoice use XML as their technical syntax.

EDIFACT, by contrast, uses its own compact syntax according to the UN/EDIFACT rules.

The two worlds can be connected technically.

SAP Cloud Integration, for example, provides an EDI-to-XML converter that can transform EDIFACT messages into XML.

However, conversion alone does not automatically resolve the business mapping question.

An EDIFACT data element and an XML element can have different semantics, cardinalities or code lists. A technically correct business mapping must therefore also be defined.

Further information on the XML-based UBL business document standard:

UBL Format Explained: Structure, E-Invoicing, XML, Peppol and SAP

---

SAP IDoc EDIFACT: How Does EDIFACT Work in SAP?

For the secondary keyword SAP IDoc EDIFACT, a clear distinction is particularly important:

A SAP IDoc is not an EDIFACT document.

An IDoc is SAP’s own message format. EDIFACT, by contrast, is an external international B2B message standard.

The underlying architecture therefore typically looks as follows:

SAP → IDoc → Middleware → Mapping → EDIFACT → Business Partner

For inbound processing:

Business Partner → EDIFACT → Middleware → Mapping → SAP IDoc → SAP Application

The integration layer performs the transformation between the two data models.

An example:

A SAP system generates an internal IDoc for a business transaction. This IDoc can contain data from a purchase order, invoice or delivery process, for example.

The middleware then transforms the SAP structure into the agreed EDIFACT message type.

The same process takes place in reverse on the receiving side.

The existing Fink article on SAP IDoc explains this distinction between EDI, EDIFACT and SAP IDoc and describes IDocs as remaining relevant for established B2B and EDI scenarios.

Further information:

SAP IDoc Explained: Structure, Processing, EDI and Monitoring

---

What Role Does SAP Integration Suite Play in EDIFACT?

For modern SAP integration architectures, SAP Integration Suite can provide a central integration layer.

SAP Integration Advisor supports B2B, A2A and B2G integration and works with so-called Type Systems. SAP describes UN/EDIFACT as well as SAP IDoc as supported or modellable message environments within this B2B integration logic. Message Implementation Guidelines and Mapping Guidelines are used to document specific partner requirements and build mappings.

Cloud Integration can subsequently provide the technical runtime.

This includes, for example:

transformation, routing, validation, technical connectivity, error handling and monitoring.

This enables organisations to move traditional SAP IDoc EDIFACT scenarios into a modern cloud integration architecture without necessarily replacing the underlying EDIFACT communication with their business partners.

Further information:

SAP Integration Suite – Fink IT-Solutions

---

How Are EDIFACT Documents Technically Transmitted?

EDIFACT primarily defines the structure of the message, not automatically the transmission channel.

This is an important distinction.

Depending on the partner agreement and architecture, an EDIFACT message can be transmitted via AS2, SFTP, FTPS, a Value Added Network or other secure transmission methods. TrueCommerce identifies AS2, SFTP and FTPS as well as VANs as typical EDI transmission mechanisms.

An integration project must therefore answer two separate questions:

What does the message look like?

and

How does the message securely get from A to B?

The EDIFACT format primarily answers the first question.

The communication channel answers the second.

---

Is an EDIFACT Invoice an E-Invoice in Germany?

A differentiated answer is required.

Since 1 January 2025, new VAT rules for electronic invoices between domestic businesses have applied in Germany. The German Federal Ministry of Finance describes an e-invoice in particular as an invoice in a structured electronic format that enables electronic processing. XRechnung and suitable ZUGFeRD profiles are typical examples.

However, the Ministry explicitly states that invoice issuers and recipients may also agree on another format.

The prerequisite is that the format allows the correct and complete extraction of the information required under German VAT law.

In this context, the Ministry expressly identifies EDI procedures such as EDIFACT as continuing to be usable if these requirements are met.

This means:

An EDIFACT INVOIC can qualify as a valid e-invoice in Germany – but not simply because it uses EDIFACT.

The specific implementation, the invoice data contained in the message and the statutory requirements are decisive.

Further information:

E-Invoicing with SAP – Fink IT-Solutions

---

Is EDIFACT Compatible with EN 16931?

A precise distinction is also required here.

For the European e-invoicing standard EN 16931, two syntax formats are primarily listed as mandatory for public procurement:

UBL 2.1 and UN/CEFACT Cross Industry Invoice (CII).

The European Commission additionally lists a syntax binding for UN/EDIFACT INVOIC D16B in CEN/TS 16931-3-4:2017. However, EDIFACT is not one of the two syntax formats that public contracting authorities are required to support under the Directive.

The distinction is important:

EDIFACT has a defined EN 16931 syntax binding.

However:

EDIFACT is not one of the two standard syntaxes that public contracting authorities are required to accept.

In addition, a new version, EN 16931-1:2026, was published in May 2026. The previous 2017 version was formally withdrawn but, according to the European Commission, remains compliant during a migration period. The transition of technical components and national implementations is taking place gradually.

For a current project, this means:

An existing EDIFACT invoice should not automatically be described as “EN 16931 compliant”. The specific syntax binding, version, profile, recipient requirements and national regulations must be assessed.

---

What Are the Benefits of EDIFACT?

Automated Data Exchange

Business information can be transmitted and processed directly between IT systems.

Less Manual Data Entry

Purchase orders, despatch advices and invoices do not need to be entered manually again.

Standardised Communication

Business partners can use a common structure even if they operate different ERP systems.

High Process Speed

Electronic messages can be transmitted and processed immediately after they are generated.

Fewer Data Entry Errors

End-to-end electronic processing reduces common errors associated with manual data entry.

Established B2B Processes

EDIFACT has been established in many industries for decades. As a result, extensive partner networks, industry profiles and operational experience already exist.

Compact Message Structure

Compared with verbose XML documents, EDIFACT syntax can be very compact.

These benefits explain why EDIFACT continues to be used in many productive supply chains despite APIs, XML and cloud integration.

---

What Challenges Exist with EDIFACT?

Standardisation does not automatically mean that two EDIFACT systems can communicate with each other without coordination.

This is one of the main challenges.

Different Versions

Business partners may use different EDIFACT directories.

Industry-Specific Subsets

A retail company may, for example, use different requirements from an energy or automotive company.

Partner-Specific Guidelines

Even within the same message type, companies can require different mandatory fields, qualifiers and code values.

Complex Mapping

ERP data must be mapped correctly to segments and data elements from a business perspective.

Error Analysis Across Multiple Systems

An issue can occur in the source system, mapping, transmission, EDIFACT parser or target system.

Regulatory Requirements

For an EDIFACT invoice in particular, technical message compliance is not sufficient. The applicable tax and e-invoicing requirements must also be met.

Legacy Dependencies

EDI landscapes that have grown over many years often contain numerous partner-specific mappings. A change to an ERP system can therefore have significant effects on existing integrations.

---

Where Is EDIFACT Used?

EDIFACT is particularly suitable for high-volume, recurring and structured B2B processes.

Typical areas include:

Retail: Purchase orders, order confirmations, price catalogues, despatch advices and invoices.

Automotive: Delivery schedules, Just-in-Time calls, shipping information and supply chain communication.

Logistics: Transport orders, shipping and receiving information.

Manufacturing: Material supply and supply chain integration.

Energy: Master data, meter and market communication in EDIFACT-based industry processes.

Finance: Invoices and remittance advices.

EDIFACT therefore supports both Procure-to-Pay and Order-to-Cash processes.

---

EDIFACT or API – Which Approach Is Better?

There is no universal answer.

EDIFACT is particularly suitable for:

established asynchronous B2B messages, high transaction volumes and business processes with clearly defined documents.

APIs are often better suited to:

targeted synchronous communication, real-time queries or digital services.

A company can therefore use APIs and EDIFACT at the same time.

For example:

An online shop queries current inventory via an API.

The resulting purchase order is then transmitted to a supplier through an established EDIFACT ORDERS process.

SAP Integration Suite supports exactly these hybrid integration patterns involving APIs, EDI and events.

---

Best Practices for EDIFACT

Define the Message Type and Business Purpose First

Do not begin with mapping until it is clear which business transaction needs to be represented.

Clearly Document the Version and Partner Profile

Document the directory, message type, subset and partner MIG.

Standard Before Customisation

Use established segments, qualifiers and industry profiles before introducing proprietary extensions.

Validate Inbound and Outbound Messages

A message should be technically and functionally validated both before transmission and after receipt.

Establish End-to-End Monitoring

Do not monitor the middleware alone. SAP IDoc statuses, transmission and business processing should also be part of process monitoring.

Consider Business Acknowledgements

A technically successful transmission does not automatically mean that the business transaction has been accepted.

Assess E-Invoicing Separately

Evaluate an EDIFACT invoice separately against the regulatory requirements of the relevant country and recipient.

---

Do’s & Don’ts for EDIFACT

Do

Clearly define business partners, message types, versions and implementation guidelines. Document and version-control mappings. Test not only standard cases, but also changes, rejections and faulty messages. Establish monitoring across the complete data flow and additionally assess invoice processes for e-invoicing compliance.

Don’t

Do not treat EDI and EDIFACT as the same thing. Do not assume that two ORDERS messages are automatically structured identically. Do not use a newer directory version without checking whether the partner expects another version. Do not automatically describe INVOIC as a legally compliant e-invoice, and do not treat technically successful mapping as proof of a successful business process.

---

Step by Step: Introducing EDIFACT in Your Organisation

Step 1 – Select the Business Process

First determine whether the purchase order, order confirmation, delivery, invoice or another process is to be digitalised.

Step 2 – Coordinate with the Business Partner

Clarify which messages the partner can send or receive.

Step 3 – Define the Message Type and Version

Specify ORDERS, ORDRSP, DESADV or INVOIC, for example, as well as the relevant directory.

Step 4 – Define the Subset and MIG

Define mandatory business fields, code lists, qualifiers and partner-specific rules.

Step 5 – Analyse the Internal Data Model

Review how the required data is represented in the ERP system.

In SAP, this may, for example, involve an IDoc-based structure.

Step 6 – Develop the Mapping

Map source fields correctly to EDIFACT segments and data elements from a business perspective.

Step 7 – Set Up the Communication Channel

Define AS2, SFTP or the agreed EDI service, for example.

Step 8 – Perform Validation and Testing

Test syntax, mapping, business rules and partner requirements.

Also consider faulty and incomplete messages.

Step 9 – Define Monitoring

Establish responsibilities, alerts, error handling and restart procedures.

Step 10 – Maintain Continuously

EDIFACT interfaces are not a one-time development project.

New business partners, changed code lists, ERP migrations, e-invoicing regulations or new partner guidelines require continuous governance.

---

Conclusion – Why EDIFACT Remains Relevant

EDIFACT is one of the most established standards for automated B2B data exchange.

Its strength lies in the clear, standardised and machine-readable representation of business messages. ORDERS, ORDRSP, DESADV, INVOIC and numerous other message types can electronically connect complete supply chains.

At the same time, EDIFACT should not be viewed in isolation.

EDI is the overarching integration concept. EDIFACT is one possible message standard within it. SAP IDoc EDIFACT generally requires mapping between SAP’s internal structure and the external format. XML-based standards use a different syntax model, but can be connected to EDIFACT through modern middleware.

For SAP organisations, this means that existing EDIFACT processes do not automatically need to be replaced when SAP S/4HANA or SAP Integration Suite is introduced.

Instead, SAP Integration Suite can be used to embed established EDI partner processes into a more modern integration architecture.

The EDIFACT invoice currently deserves particular attention.

Under Germany’s B2B e-invoicing requirements, agreed EDI procedures such as EDIFACT can remain permissible if the required invoice information can be extracted correctly and completely. However, an EDIFACT INVOIC is therefore not automatically a legally compliant e-invoice.

The European EN 16931 standard must also be considered carefully. For public contracting authorities, UBL and CII are the mandatory supported syntaxes; while a CEN syntax binding exists for EDIFACT INVOIC, EDIFACT is not part of the mandatory syntax list. At the same time, the EN 16931 ecosystem has been in a transition phase since the publication of EN 16931-1:2026.

The decisive question for organisations is therefore not:

“Is EDIFACT still modern?”

Instead:

“Is EDIFACT still the right integration format for this business partner, this process, this ERP system and this regulatory requirement?”

In many established B2B scenarios, the answer in 2026 remains: Yes – provided that architecture, mapping, monitoring and compliance are implemented professionally.

---

Frequently Asked Questions About EDIFACT