ZUGFeRD E-Invoice Standard

National

FeRD (Forum Elektronische Rechnung Deutschland) · Version 2.3.1 (2022)

ZUGFeRD is Germany's hybrid e-invoice format combining a human-readable PDF/A-3 document with a machine-readable XML file embedded inside it. It is based on the EN 16931 semantic data model and is one of two dominant German e-invoice formats alongside XRechnung. ZUGFeRD is widely used in B2B workflows because the PDF provides immediate human readability while the embedded XML enables automated processing.

1 Countries

52+ Data fields

Yes Structured format

Varies Delivery network

AI Summary

ZUGFeRD (Zentraler User Guide des Forums DATENBANKARCHITEKTUR) is Germany's original hybrid e-invoice format, developed by FeRD to balance human readability (via PDF) with machine-readability (via EN 16931 XML). It is based on the European semantic data model EN 16931, making it compatible with EU-wide e-invoicing frameworks. ZUGFeRD is widely adopted in German B2B supply chains because it works with standard PDF viewers while enabling automated invoice processing. It coexists with XRechnung in the German market — ZUGFeRD for B2B flexibility, XRechnung for government procurement. The format is referenced by the European standardisation organisations and is part of the EN 16931-compliant format family that includes Factur-X.

Grounded in official sources listed below. Not a substitute for legal or tax advice.

Quick Answers

01
02
03
04

Key Data Fields

The following data elements are central to the ZUGFeRD specification. Mandatory fields are required for compliance; optional fields add detail.

PDF Component

Code Field name Mandatory

Visual Human-readable invoice layout — Standard invoice appearance — no special restrictions Yes

XML Component (EN 16931 profile)

Code Field name Mandatory

BT-1 Invoice number Yes

BT-2 Issue date Yes

BT-27 Seller name + VAT Yes

BT-44 Buyer name + VAT Yes

BT-151 Item name Yes

BT-152 Item description No

Validation Requirements

Invoices using this standard must pass the following validation checks before transmission. Rejections typically occur due to missing mandatory fields or incorrect data types.

PDF must be valid PDF/A-3 format — regular PDFs are not compliant
XML must be embedded in PDF as an attached file (not visible in the visual PDF content)
XML must conform to EN 16931 semantic data model
ZUGFeRD-specific profile rules apply for the embedded XML structure
German extensions (e.g., StNr, USt-IdNr) may be required depending on recipient

Key Advantages

Human-readable (PDF) + machine-readable (XML) in one file
Based on EN 16931 — EU-compliant semantic model
Strong adoption in German B2B supply chains
No special software needed to view the invoice
Supported by major German ERP systems including SAP and DATEV

Implementation Considerations

PDF generation adds complexity to ERP integration
Not a pure structured data format — requires PDF parsing for automation
Peppol does not natively support PDF formats
Some German public authorities mandate XRechnung instead

Need implementation help?

Tell us your ERP, countries of operation, and transaction volume. We'll match you with vetted providers familiar with ZUGFeRD.

Request Provider Shortlist

Tell us about your requirements and get matched with vetted e-invoicing providers. We'll recommend options based on your country, ERP, and route preferences.

Official Sources

All information on this page is based on the sources listed below. Always verify current requirements with the issuing authorities.

ZUGFeRD 2.3.1 Specification Standard Body

FeRD (Forum Elektronische Rechnung Deutschland) Last verified: 2026-06-02

Official ZUGFeRD specification, version history, and implementation guidance
EN 16931-1:2017 — Semantic Data Model Standard Body

CEN (European Committee for Standardization) Last verified: 2026-05-01

Semantic invoice data model underlying ZUGFeRD XML structure