EDIFACT Format for Germany e-Invoicing: Examples, & Specifications

EDIFACT is a long-established international standard for Electronic Data Interchange (EDI), or in simple words, for exchanging structured business documents. EDIFACT has been established as a standardised system that defines certain protocols for structuring data and enables data exchange between industries and nations. EDIFACT is relevant to the concept of e-invoicing because it permits seamless invoice data exchange among German enterprises without requiring any manual effort.

Key Takeaways

• EDIFACT was created to exchange structured data across EDI systems.
• EDIFACT ensures automated invoice processing on a large scale.
• Not all EDIFACT invoices qualify to be EN 16931 invoices.
• EDIFACT e-invoicing is permitted in Germany, provided it adheres to compliance standards.

What is EDIFACT?

The abbreviation EDIFACT stands for Electronic Data Interchange for Administration, Commerce, and Transport. EDIFACT is the EDI uniform standard for exchanging information among systems. EDIFACT offers a standardised format that lets systems exchange electronic invoices and other business documents. Since EDIFACT was approved for use in 1987 by UNECE, the United Nations Economic Commission for Europe, it still continues to be relevant for e-invoicing in Germany, especially within certain supply chain-focused sectors. This is subject to businesses using EN 16931-compliant formats.

How EDIFACT Works as an E-Invoicing Format

EDIFACT e-invoicing is nothing but structured system-to-system communication. A supplier creates invoice data. This data is then translated into an EDIFACT message. The buyer’s system receives this message and processes the invoice automatically. There are no human-readable formats like PDFs involved, or any human intervention in data entry or processing.

One of the primary benefits of using EDIFACT in e-invoicing is automation at scale. For businesses that process thousands of invoices every week, manual invoice handling becomes cumbersome and expensive very quickly. EDIFACT solved this problem long before modern compliance mandates were introduced.

EDIFACT Message Structure and Syntax

The EDIFACT format follows a segment-based structure. EDIFACT messages are hierarchical and not just random segments placed one after another. Each message is divided into segments, and they perform a specific role. Some identify the buyer, whereas others define dates, invoice amounts, currencies, tax details, payment terms, and so on. Systems read the message sequentially, and the structure is what enables automation.

An EDIFACT invoice usually contains data, such as:

• A message header
• Supplier and buyer information
• Invoice reference and dates
• Line item details
• Tax information
• Invoice and tax totals
• Payment details

However, the file looks technical because of the syntax characters such as:

• +
• :
• '

Once a user understands the logic, the structure becomes more predictable.

For example:

NAD+BY+5412345000176::9'

This segment identifies the buyer. Here is what each part means.

Due to the technical structure involved, the processing of EDIFACT invoices require businesses to have dedicated EDI teams.

EDIFACT INVOIC Message Specification 

The invoice message is called INVOIC. This is the standard EDIFACT message type used for invoice exchange between businesses. A typical INVOIC message contains supplier and buyer details, invoice references, VAT information, and payment terms, amongst other information. The INVOIC acts as a formal billing request from a seller to a buyer, and gives references to previously agreed-upon conditions.

However, different industries customise EDIFACT differently. For instance, automotive suppliers often use highly customised message structures. Retail chains may require different mapping rules. Hence, a “standard” invoice can look very different from one enterprise to another. 

This matters in the context of German e-invoicing because compliance now depends not only on structured exchange, but also on whether the invoice data aligns correctly with EN 16931 requirements. A valid EDIFACT invoice is not automatically a compliant e-invoice.

EDIFACT Invoice Example 

An EDIFACT invoice is composed of segments, separated by an apostrophe ('). Data elements within segments are separated by a plus sign (+), while component values are separated by a (:). The following is an example of an EDIFACT invoice. 

EDIFACT and Germany E-Invoicing: Legal Framework

Germany recently introduced e-invoicing for businesses, with the implementation taking place in phases. All businesses are supposed to be capable of receiving structured e-invoices for domestic transactions within the B2B context from January 2025. From January 2026 businesses with a turnover over €800,000 must issue structured e-invoices for all domestic B2B transactions, with certain exemptions. Small businesses with a turnover up to €800,000 and certain EDI systems get time until the end of 2027.

The e-invoices issued which must be in compliance with EN 16931. An invoice is considered to be EN 16931 compliant when it contains all the mandatory invoice information, follows the standard’s business validation rules, and is structured for machine processing by systems across Europe. This means that the invoice data can be automatically extracted, validated, and processed without manual intervention.

Here comes the potential use of EDIFACT. Businesses can opt for exchanging invoices by following EDI procedures, such as EDIFACT, provided both parties agree. Although EDIFACT invoices are not necessarily e-invoicing compliant, companies may undertake the  mapping or translation of invoices to guarantee compliance with EN 16931. This would enable the invoice data to be easily processed electronically. 

Hence, most companies are working towards modernising their EDI systems rather than fully replacing them to meet e-invoicing norms.

EDIFACT vs. XRechnung vs. ZUGFeRD for Germany E-Invoicing

EDIFACT, XRechnung, and ZUGFeRD are formats that support electronic invoicing in Germany, subject to compatible versions being used. However, they all work very differently. 

EDIFACT was originally designed for broad EDI communication across industries. Unlike formats that are specifically created for e-invoicing, EDIFACT was developed to support end-to-end business communication between enterprises, to exchange invoices and other business documents, in a structured format.

XRechnung was designed as a machine-readable invoice, used for automated invoice processing, without the need for any manual intervention. It is widely used when invoicing government entities; however, private businesses can also use XRechnung for B2B transactions as it provides a fully structured, EN 16931-compliant invoice format.

ZUGFeRD combines a human-readable PDF with embedded structured XML invoice data. This means that users can open and read the invoice like a regular PDF, while accounting systems can simultaneously extract and process the embedded invoice data automatically.

This table lays out the key differences between the three formats in the context of German e-invoicing:

Businesses that are already running mature EDI systems often continue with EDIFACT for e-invoicing. On the other hand, businesses that are entering e-invoicing for the first time usually lean towards ZUGFeRD.

Common Errors When Exchanging EDIFACT Invoices

EDIFACT invoicing is reliable once the system is stabilised. But getting there is not always a smooth journey. Here are some common issues that companies face when implementing EDIFACT invoicing:

Incorrect Segment Mapping

A single missing or incorrectly mapped segment can cause an invoice to be rejected during processing. For example, the supplier's VAT number gets mapped to the buyer field, the invoice date gets mapped as the delivery date, etc.

Invalid Syntax Characters

EDIFACT syntax rules are strict. A misplaced delimiter may break the entire message structure. For example, a segment has the ' sign missing at the end. Without the segment terminator, the receiving system may not know where one segment ends and the next one begins. This could cause the invoice to fail validation or be rejected altogether.

Non-Standard Customisations

Sometimes, trading parties implement their own custom fields or special messages. This may cause interoperability problems later.

Missing EN 16931 Data Elements

The older EDIFACT versions may not contain all mandatory structured invoice fields according to modern European e-invoicing requirements. Hence, if a business has not updated its EDIFACT version to an e-invoicing-compliant version, the invoices generated may fail validation or get rejected.

Master Data Mismatches

Entering incorrect data, such as supplier IDs, VAT numbers, or buyer references, can lead to validation failures, causing delays in processing or invoice rejection.

How to Implement EDIFACT E-Invoicing for Germany

If a business is considering using EDIFACT for their e-invoicing requirements, they must first check if their existing ERP already supports EDI capabilities. In cases where it does not, the enterprise will need to use a middleware translation tool or a managed EDI service. This is followed by mapping, testing, validation, onboarding, communication setup, and partner alignment.

The biggest challenge is often standardisation between trading partners. One company’s EDIFACT format specification may hugely differ from another’s implementation. This is why most enterprises rely on EDI providers, middleware platforms, or managed integration services rather than handling everything internally.

Some businesses also use conversion layers that transform EDIFACT invoice data into formats like XRechnung for compliance purposes.

Conclusion

A huge number of enterprises have been dependent on EDIFACT for invoicing and document exchange, especially across manufacturing and logistics-heavy industries. At the same time, Germany’s e-invoicing reforms are now pushing businesses towards EN 16931-aligned structured invoice frameworks. This means that EDIFACT systems now need adjustments to be made.

If your enterprise already runs a mature EDI ecosystem, assess before January 2028 whether your EDIFACT output can produce or enable extraction of EN 16931-compliant data. If it cannot, a translation or mapping middleware layer is the practical path, and not a full EDI replacement. Businesses replacing EDI entirely should evaluate XRechnung or ZUGFeRD 2.1+ as the most direct route to mandate compliance.