XRechnung, ZUGFeRD and Peppol Explained
XRechnung, ZUGFeRD, Factur-X and Peppol explained simply
E-invoicing sounds like one topic.
In daily business, it is usually at least five different questions:
What invoice data model is required?
Which country profile or national rule applies?
Does the invoice need a readable PDF view?
How does the invoice travel from sender to receiver?
What happens if the real process still starts with a PDF?
That is why terms like XRechnung, ZUGFeRD, Factur-X and Peppol often get mixed up. They all belong to the same e-invoicing world. But they do not solve the same problem.
The simple memory aid:
- EN 16931 answers: “What shared European invoice meaning do systems need to understand?”
- XRechnung answers: “Which German structured XML invoice profile is required?”
- ZUGFeRD / Factur-X answers: “Can we combine a readable PDF with structured invoice XML?”
- Peppol answers: “Through which network can structured invoices be exchanged?”
- PEDIF answers: “What if an important process still starts with recurring PDFs?”
This article is a European version of the topic. Germany remains an important example because XRechnung and ZUGFeRD are central there. But the European reality is broader: Belgium is a strong Peppol example, France uses Factur-X alongside UBL and CII in its reform, and other countries have their own models, platforms and timelines.
If your next question is not “What do these terms mean?” but “How do we get from existing PDF invoices to structured e-invoice outputs?”, the related pillar article is the logical next step:
/en/blog/e-invoicing-xrechnung-zugferd-from-pdf
A simple analogy: the European airport for invoices
Imagine European e-invoicing as an airport.
EN 16931 is the shared travel vocabulary. It defines what “passenger name”, “flight number” and “destination” mean so different systems do not guess.
XRechnung is like a German machine-readable QR Code boarding pass for a specific route. It is not designed to be read by a human. It is designed for systems to read and process.
ZUGFeRD / Factur-X is like a boarding pass with two layers: a readable paper version for people and the machine-readable embedded QR Code.
Peppol is not the boarding pass. Peppol is the secure route through the airport network: access points, directories and exchange rules that help structured documents travel between organisations.
And PEDIF? PEDIF is the desk that helps when a partner still arrives with recurring PDF paperwork. The PDF may be visible to a human, but your ERP, EDI or accounting system needs structured data. PEDIF helps attach the digital label so the document can move into the right data flow, depending on layout, fields, validation, target format and system scope.
First: e-invoicing in Europe is not one single switch
The European e-invoicing landscape is moving in the same general direction: structured invoice data, machine processing, validation and digital reporting.
But it is not one identical implementation everywhere.
There is a shared European foundation. Directive 2014/55/EU called for a common European semantic standard for electronic invoices in public procurement. That foundation is EN 16931. It helps ensure that key invoice information has a common meaning across systems.
At the same time, each country can add national rules, profiles, platforms, transmission channels and implementation timelines.
That is the practical reality for businesses operating across Europe:
- In Germany, teams often deal with XRechnung, ZUGFeRD and public-sector requirements.
- In Belgium, Peppol plays a very prominent role in B2B e-invoicing.
- In France, the reform is strongly platform-based and uses formats such as Factur-X, UBL and CII.
- In other markets, companies may see national portals, clearance systems, Peppol variants, local CIUS profiles or additional reporting obligations.
So the question is rarely: “Which single e-invoice standard does Europe use?”
The better question is:
Which invoice data, format profile, transmission route and validation logic apply to this country, this customer and this process?
What is EN 16931?
EN 16931 is the European semantic foundation for electronic invoices.
In plain English, it describes the meaning of core invoice information.
It is not just about seeing a number on a document. It is about knowing whether that number is:
- the invoice total,
- the VAT amount,
- the net line amount,
- the payment amount,
- the quantity,
- the unit price,
- or something else.
A human can often understand this from context. Software cannot rely on intuition. It needs structured fields and clear meaning.
That is why EN 16931 is best understood as a shared grammar for invoice data.
It is important, but it is not the whole story. A country may still define a national usage specification, additional validation rules, accepted syntaxes, transmission channels or platform obligations. In Germany, XRechnung is a national implementation. In France, the reform adds platform logic and accepted formats. In Belgium, Peppol becomes especially important for transmission.
XRechnung explained simply
XRechnung is a structured XML invoice standard used in Germany, especially for invoicing public authorities.
It is not a nice-looking PDF invoice. It is structured data.
That is the point.
A human may need a viewer to inspect an XRechnung comfortably. But software can process it because the invoice information is not just placed somewhere on a page. It is encoded as structured XML.
When is XRechnung typically relevant?
XRechnung is typically relevant when:
- a German public-sector customer is involved,
- a recipient explicitly asks for XRechnung,
- structured XML data is more important than a built-in human-readable view,
- automated validation and software processing are required,
- the process can handle visualisation separately from the data file.
In one sentence:
XRechnung is the “system-first” invoice format in the German context.
ZUGFeRD explained simply
ZUGFeRD is a hybrid e-invoice format that combines a readable PDF/A-3 document with embedded structured XML invoice data.
For many businesses, that feels intuitive.
The finance team can still open a PDF-like document. The software can read the embedded XML. The human and the system each get the layer they need.
But ZUGFeRD is not “just a better PDF”.
The structured XML part is essential. Without it, the document would only be a visual invoice, not a structured e-invoice workflow.
When is ZUGFeRD typically relevant?
ZUGFeRD is worth considering when:
- the recipient wants or accepts a readable PDF view,
- structured XML invoice data is still required,
- existing teams are used to PDF-based processes,
- the correct version and profile are accepted for the use case,
- validation rules and recipient expectations are clear.
In one sentence:
ZUGFeRD is the “human plus system” invoice format.
Factur-X explained simply
Factur-X is the French-German name for the hybrid invoice standard that is technically aligned with ZUGFeRD in current joint releases.
This point matters for European content.
In Germany, people often say ZUGFeRD.
In France, people usually say Factur-X.
In practice, both refer to the same Franco-German hybrid idea: PDF for humans, XML for process automation.
A small naming note: the official term is Factur-X, not “XFacture”. If internal stakeholders use “XFacture”, they probably mean Factur-X or a Factur-X-like hybrid invoice. In published content, use Factur-X.
Why Factur-X matters in France
France is not simply copying the German XRechnung model.
The French reform is built around approved platforms and a set of accepted formats. Factur-X is important because it gives companies a hybrid option: a readable PDF representation with structured XML data.
France also recognises structured formats such as UBL and CII in the reform context. This means teams working across Germany and France should not only ask: “Can we produce an e-invoice?” They should ask:
Which profile, platform, format and exchange route does this French customer or supplier require?
In one sentence:
Factur-X is the French market name you should know when German teams say ZUGFeRD.
Peppol explained simply
Peppol is not an invoice format.
Peppol is a network and interoperability framework for exchanging structured electronic business documents. In practice, companies connect through service providers / access points. The network helps the sender and receiver exchange structured documents without every pair of partners building a separate direct connection.
A simple distinction:
- XRechnung, ZUGFeRD, Factur-X, UBL and CII describe what the invoice data looks like.
- Peppol describes how structured documents can be exchanged.
That distinction is essential.
A company may need a structured invoice format and a Peppol transmission route. But Peppol itself is not the invoice content.
In one sentence:
Peppol is the route, not the invoice.
Belgium as a Peppol example
Belgium is one of the clearest examples of why Peppol matters in Europe.
From 1 January 2026, structured electronic invoicing between Belgian VAT-registered businesses is mandatory. Belgian official sources explain that these invoices must be exchanged directly between the software of the businesses and that invoices have to be sent via the Peppol network.
That is a different practical emphasis from Germany.
In Germany, many discussions start with: “XRechnung or ZUGFeRD?”
In Belgium, many discussions quickly become: “Are you ready to send and receive structured invoices through Peppol?”
This does not mean “Peppol is the Belgian invoice format”. It means Peppol is central to the exchange model.
For companies selling into Belgium, buying from Belgian suppliers or managing shared European finance processes, the practical questions are:
- Is the accounting or invoicing software Peppol-ready?
- Which Peppol participant ID is used?
- Which document type and business process apply?
- How are supplier master data and routing data maintained?
- What happens to suppliers that still send PDFs?
That last question is where PDF-first reality comes back into the story.
France as a Factur-X and platform example
France shows another European pattern.
The French B2B e-invoicing reform is platform-based. Companies will need to transmit and receive invoices through state-approved platforms, directly or via compatible solutions. The rollout starts from 1 September 2026, with issuing obligations phased by company size into 2027.
France also illustrates why format names matter. The reform context includes structured formats such as CII and UBL, and the hybrid Factur-X format.
So a European e-invoicing team should not say:
“We need the French version of XRechnung.”
A better formulation is:
“For France, we need to understand the approved platform model, the accepted invoice formats such as Factur-X, UBL or CII, the lifecycle status logic, and the specific requirements for the customer or supplier process.”
In one sentence:
France is not just a format question; it is a platform, format, lifecycle and reporting question.
Germany as an XRechnung and ZUGFeRD example
Germany remains one of the most important examples for this topic because XRechnung and ZUGFeRD are both widely discussed there.
Since 1 January 2025, Germany has moved into mandatory domestic B2B e-invoicing with transition rules. A simple PDF is not the same as a structured e-invoice under the new German definition. XRechnung and suitable EN-16931-compatible ZUGFeRD profiles are central examples in the German discussion.
In practice, German teams often face three different situations:
- Public-sector customer: XRechnung may be required.
- B2B customer with PDF-friendly workflow: ZUGFeRD may be attractive if the accepted profile fits.
- Existing PDF-first process: the company may need a bridge from PDF invoice layouts to structured data.
That is the point where e-invoicing meets real operational workflows.
The core comparison
Term | Simple explanation | Main question | Human-readable? | Structured for systems? | Typical European example |
EN 16931 | European semantic invoice model | “What should invoice data mean?” | Not a document view | Yes, semantic foundation | EU-wide foundation behind many national implementations |
XRechnung | German XML invoice standard | “Which German structured XML profile?” | Not directly; viewer useful | Yes | Germany, especially public-sector invoicing |
ZUGFeRD | Hybrid PDF/XML invoice standard | “Can we combine PDF view and XML data?” | Yes | Yes | Germany, B2B and PDF-near workflows where accepted |
Factur-X | Franco-German hybrid invoice standard aligned with ZUGFeRD | “What is the French name / context for this hybrid model?” | Yes | Yes | France, platform-based reform context, hybrid invoice option |
Peppol | Exchange network / infrastructure | “How do structured documents travel?” | Not the relevant layer | Depends on the document being transmitted | Belgium as strong Peppol example; also used across public-sector and B2B contexts in Europe |
PEDIF | PDF-to-structured-data bridge for recurring, approved document layouts | “What if the process still starts with PDF?” | PDF can remain the starting point | Target is structured output | PDF-first invoices and recurring supply-chain documents in defined scope |
Why PDFs still matter in a structured e-invoicing world
At first glance, e-invoicing sounds like the end of PDF invoices.
In reality, PDFs remain everywhere.
Suppliers send PDF invoices by email. Legacy systems generate PDF output. Subsidiaries use older billing tools. Smaller partners are not always ready for direct EDI or Peppol workflows. International customers may demand different country formats. ERP migrations take time.
The problem is not that a PDF is “not digital”.
A PDF is digital. It is visible. It can be emailed, archived and opened.
The problem is that a PDF is often not directly usable by ERP, EDI, AP automation or accounting systems as structured data.
A PDF invoice is like a photo of a shipping label. A human can read the address. But an automated sorting system needs a barcode and structured routing data.
That is why structured e-invoicing is not just about replacing paper. It is about replacing visual information with processable data.
Where PEDIF fits
PEDIF sits at the point where the European e-invoicing map meets operational reality.
PEDIF does not replace EDI. PEDIF closes the gap where EDI does not reach.
The partner may still start with PDF. Your system needs structured, validated data.
PEDIF is not simply OCR. OCR reads characters. PEDIF recognises recurring business documents and layout patterns in a defined scope.
In a suitable project, PEDIF can process recurring, approved PDF invoice layouts, extract relevant data, structure it, validate it and hand it over to a target system or target format. Depending on the project, that target may be:
- ERP,
- EDI,
- XML,
- CSV,
- API,
- XRechnung,
- ZUGFeRD / Factur-X,
- or another structured handover format.
The careful wording is important:
PEDIF can support the bridge from PDF-first processes to structured e-invoicing data flows when layout, data quality, mandatory fields, validation rules, target profile and destination system are defined.
The unsafe wording would be:
“PEDIF turns every PDF into a compliant e-invoice automatically.”
That is not the right claim.
Practical example: one supplier, three European customers
Imagine a mid-sized supplier selling industrial components across Europe.
The operational reality looks like this:
- A German public-sector customer expects XRechnung.
- A German B2B customer accepts ZUGFeRD.
- A Belgian customer expects structured invoicing through Peppol.
- A French customer prepares for platform-based e-invoicing and may accept Factur-X, UBL or CII depending on the setup.
- Several smaller partners still send or receive PDF invoices because their systems have not changed yet.
- The finance team wants fewer manual checks, but the ERP environment cannot be replaced overnight.
Without a clear model, this becomes confusing fast:
“Is Peppol a format?”
“Is Factur-X the same as ZUGFeRD?”
“Do we need XRechnung everywhere?”
“Is a PDF still allowed?”
“What do we do with suppliers who are not ready?”
With the layers separated, the discussion becomes practical:
- EN 16931 gives the European semantic foundation.
- XRechnung covers a German XML profile need.
- ZUGFeRD / Factur-X covers the hybrid PDF plus XML scenario.
- Peppol covers an exchange route, especially important in Belgium.
- PEDIF covers the PDF-first bridge where recurring layouts need to become structured data.
That does not remove every implementation detail. But it gives the team the right questions.
Decision guide: what do you really need?
Your situation | Most relevant layer | Key question |
You invoice German public authorities | XRechnung | Which current XRechnung version, transmission route and buyer reference are required? |
A German B2B customer wants a readable invoice plus structured data | ZUGFeRD | Which profile and validation rules does the customer accept? |
A French customer mentions Factur-X | Factur-X / platform model | Which approved platform, format and lifecycle process applies? |
A Belgian customer asks for Peppol readiness | Peppol | Which Access Point, participant ID and Peppol business process are needed? |
Your ERP creates only PDF invoices | PEDIF / PDF-first bridge | Can recurring PDF layouts be mapped, validated and handed over as structured data? |
Suppliers still send PDF invoices | PEDIF / PDF-to-structured-data | Are the layouts stable enough and are all mandatory fields available? |
You already use EDI for large partners but have a long PDF tail | EDI plus PEDIF | Where does EDI coverage end and where can PDF-to-data close the gap? |
You operate in several EU countries | Country-specific e-invoicing architecture | Which national formats, platforms and transmission routes apply per market? |
Checklist before implementation
Before choosing a tool, format or integration route, answer these questions:
- Which countries are in scope?
- Is the process about invoice sending, invoice receiving or both?
- Which customers or suppliers define the requirement?
- Is the invoice data model EN-16931-based?
- Is there a national profile, such as XRechnung?
- Is a hybrid PDF/XML format, such as ZUGFeRD or Factur-X, accepted?
- Is Peppol required or simply one possible transmission route?
- Is a national platform model involved, as in France?
- Which system currently creates or receives the invoice?
- Does the process still start with PDF?
- Are the PDF layouts recurring and stable enough for layout activation?
- Are all mandatory invoice fields present and reliable?
- Which validation rules apply?
- What happens when a layout, field or tax logic does not match?
- Which ERP, EDI, DMS, archive, accounting or access-point process receives the structured data?
- Who signs off the legal, tax, IT and process implications?
Common misunderstandings
“Peppol is an invoice format.”
No. Peppol is an exchange network / infrastructure. The invoice data format still has to be defined.
“ZUGFeRD is only a German topic.”
Not quite. ZUGFeRD is closely aligned with Factur-X, the Franco-German hybrid standard. In France, the term Factur-X is the relevant published term.
“Factur-X is a different idea from ZUGFeRD.”
In current joint releases, Factur-X and ZUGFeRD are technically aligned names for the same hybrid standard family. The market context differs: Germany tends to say ZUGFeRD, France tends to say Factur-X.
“XRechnung is the European standard.”
No. XRechnung is a German implementation / profile context. The broader European semantic foundation is EN 16931.
“If we have Peppol, we are done.”
Not automatically. Peppol is the route. You still need the right document format, business process, participant data, validation logic and backend handover.
“A PDF is useless now.”
Not exactly. PDFs may remain part of real-world workflows, especially in legacy and partner processes. The key question is whether the required data can be transformed into a structured, validated target flow.
“PEDIF makes every PDF automatically compliant.”
No. PEDIF works in defined scopes with recurring, approved layouts, mapping, validation and clear target systems. This scope discipline is what makes the approach operationally credible.
Where to place the interactive element
Recommended placement: after the first comparison table and before the section “Why PDFs still matter in a structured e-invoicing world.”
The component should help readers identify whether they are dealing with a format question, a hybrid-PDF question, a transmission-network question, a country-platform question or a PDF-first workflow question.
Suggested component name: EuropeanEInvoiceNavigator.
FAQ
What is the difference between XRechnung, ZUGFeRD, Factur-X and Peppol?
XRechnung is a German structured XML invoice standard. ZUGFeRD and Factur-X are hybrid PDF/XML invoice standards. Peppol is not a format; it is a network and infrastructure for exchanging structured electronic business documents.
Is Factur-X the same as ZUGFeRD?
In current joint releases, Factur-X and ZUGFeRD are technically aligned names for the same Franco-German hybrid invoice standard. Germany commonly uses the name ZUGFeRD, while France commonly uses Factur-X.
Is Peppol mandatory everywhere in Europe?
No. Peppol is important across Europe, but its legal and practical role differs by country and use case. Belgium is a strong example where Peppol is central for structured B2B e-invoicing. Other countries may use Peppol, national platforms, clearance systems or several routes.
Is XRechnung only relevant in Germany?
XRechnung is a German standard and is especially relevant for invoicing German public-sector customers. It is connected to the European EN 16931 foundation, but it is not the universal European invoice format.
What is EN 16931 in simple terms?
EN 16931 is the European semantic model for electronic invoices. It defines the meaning of core invoice information so systems can process invoice data consistently.
What is the difference between ZUGFeRD and a normal PDF?
A normal PDF is mainly a visual document. ZUGFeRD combines a readable PDF/A-3 view with embedded structured XML invoice data. The XML data is what enables software processing.
Why does Belgium matter in this article?
Belgium is a practical example of a Peppol-focused e-invoicing model. From 1 January 2026, structured B2B invoices between Belgian VAT-registered businesses have to be exchanged electronically, with Peppol as the systematic network route.
Why does France matter in this article?
France shows that European e-invoicing is not only about formats. The French reform is platform-based and includes formats such as Factur-X, UBL and CII, with phased obligations from 2026 and 2027.
Can PEDIF turn a PDF invoice into XRechnung, ZUGFeRD or Factur-X?
PEDIF can support the conversion of recurring, approved PDF layouts into structured data flows in defined project scopes. Whether the output can become XRechnung, ZUGFeRD, Factur-X or another target structure depends on the source data, mandatory fields, validation rules, profile requirements and destination system.
Does PEDIF replace EDI or Peppol?
No. PEDIF does not replace EDI or Peppol. PEDIF complements structured exchange models by helping with PDF-first or non-EDI partner processes where recurring documents need to become structured, validated data.
Conclusion
XRechnung, ZUGFeRD, Factur-X and Peppol belong to the same European e-invoicing conversation. But they do not mean the same thing.
EN 16931 is the shared European semantic foundation.
XRechnung is a German structured XML invoice standard.
ZUGFeRD is the German name for a hybrid PDF/XML invoice model.
Factur-X is the French-German hybrid standard name used in France and aligned with ZUGFeRD.
Peppol is an exchange network, not the invoice format itself.
PEDIF helps where the real process still starts with recurring PDFs and the target system needs structured data.
The best e-invoicing question is therefore not:
“Which buzzword do we need?”
The better question is:
Which data exists today, which country and customer rules apply, and how do we get from the current document process to structured, validated data in the right target system?