How ZUGFeRD simplifies invoice exchange
Great savings potential through process automation for all companies
Many companies are currently in “digital puberty”. Their business processes are no longer analogous, but they are not yet fully digitized. ZUGFeRD helps them to innovate in the course of digitalization in the course of digitization. At the same time, however, the format also allows for the old manual processing paths. ZUGFeRD offers many other advantages. By the way, also in connection with SAP.
ZUGFeRD is a hybrid that opens all doors for companies to automate standard invoice management processes during the transformation phase. The smart format expands the options of digital processing, but also allows conventional methods. This allows companies to decide for themselves whether they want to continue processing invoices by hand or already automatically. Switching from manual to machine is so easy. You can read how this works in detail. First of all: ZUGFeRD is particularly interesting for companies that use SAP!
Table of Contents

Who is ZUGFeRD suitable for?
- Smes
- Corporations
- Public administration
- Companies with SAP systems
What is ZUGFeRD?
The unwieldy acronym ZUGFeRD stands for Zentralen User Guide des Forum elektronische Rechnungen Deutschland. Basically, it describes a dual procedure for electronic invoice exchange, in which billers and billeers can exchange structured data.
Originally, ZUGFeRD was developed for medium-sized and large enterprises as well as for public administration. Small companies also benefit significantly, as ZUGFeRD takes many steps away from them, simplifies communication between the biller and the recipient and thus saves considerable costs.
Important: For companies working for the public sector, the sending of electronic invoices is mandatory from 27.11.2020 according to EU Directive 2014/55/EU. The ZUGFeRD format is suitable for this purpose.
What are the advantages of ZUGFeRD?
The format reduces the processing time of invoices to a minimum, ensures the correct booking and saves both time and money. Technically, it expands the entrepreneurial scope, but does not contain any limitations. – Regardless of industry and size.
- Fast, convenient, easy management
- Reduced operating costs due to process automation
- Reduced manual & time spent
- No postage and paper costs
- Lower personnel costs
- Fewer errors
60% less costs – bills are paid earlier
It has been determined that the use of electronic invoice procedures such as ZUGFeRD can save around EUR 10 per invoice.
This corresponds to a cost reduction of approx. 60% per invoice.
In addition, invoices are paid on average 5.3 days earlierthan by post. (Source: computerwoche.de, https://www.computerwoche.de/a/wie-der-zugferd-standard-den-rechnungsaustausch-vereinfacht,3211062)
From paper to ZUGFeRD
The “electronic invoice” has been in the large companies for some time. For SMEs, however, the topic is also becoming more and more interesting, whether the many advantages.
As a rule, the recipient receives digital invoices in PDF format – as an attachment to an e-mail. If it is a conventional, pure PDF invoice, the accounting department needs a so-called OCR software for the transmission of the information. If it does not have this, it must manually transfer all invoice data to the invoice receipt book. Only then can the invoice be processed digitally. With ZUGFeRD, this is different. The format combines the best of both worlds.
PDF/A3 + XML = ZUGFeRD
The best of both worlds
ZUGFeRD arrives at the invoice recipient as a “PDF image”. Embedded in it, the structured file. The format therefore consists of two components:
- PDF/A3 file (unstructured)
- XML-Datei (structured)
This has the advantage that ZUGFeRD can be read with the eye by the human invoice recipient as well as by the accounting software, which reads the data by machine. The latter is, of course, much faster, simpler and more efficient, and can significantly reduce operating costs.
Comparison of ZUGFeRD profiles
| Profile | Purpose / Target Group | Description of the contents |
| 0. MINIMUM | Tax-relevant archiving | Contains only the absolute header data required to identify the invoice (reference number, date, totals). Not suitable for automated booking. |
| 1. BASIC WL | Easy booking | Contains header and footer data, as well as invoice-level tax information, but does not include line item data. (“WL” stands for Weak Layout). |
| 2. BASIC | Easy automation | Supplements the “BASIC WL” profile with essential item data (quantity, article name). Enables automated posting of invoice items. |
| 3. EN 16931 | EU standard (standard case) | Corresponds exactly to the European standard. This profile is the most commonly used because it covers all the fields needed for cross-border data exchange in the EU. |
| 4. EXTENDED | Complex business processes | Includes additional fields that go beyond the EU standard (e.g. detailed information for logistics or industry-specific data). |
| 5. XRECHNUNG | Public Contracting Authorities | Focus and key features |
Overview of ZUGFeRD versions
| Version | Status (2026) | Focus & Key Features |
| 1.0 | Obsolete | First hybrid format (PDF+XML). Based on UN/CEFACT, but is not compliant with the current EU standard EN 16931. |
| 2.0 | Replaces | Fundamental realignment to the EU standard EN 16931. Introduction of the profiles (BASIC, COMFORT, EXTENDED). |
| 2.1 | Legacy | Full technical synchronization with the French standard Factur-X. Introduction of the “XRechnung” profile. |
| 2.2 | Holdings | Detailed improvements to discount and tax logic, as well as better support for reference data in complex supply chains. |
| 2.3 | Established | Focus on the nationwide e-invoicing obligation by 2025. Introduction of technical rounding tolerances (“Slack”) in the EXTENDED profile. |
| 2.4 | Current | Today’s standard (as of 2026). Optimized validation for the B2B obligation. Resolving inconsistencies in complex tax cases. |
ZUGFeRD 2.4 – What’s New
| ID | Component | Technical Specification / Programming Note |
| 01 | Namespace / XMP | The XMP metadata entry in the PDF must reference fx:version=”1.0.07″ and zf:version=”2.4″. The XML namespace remains urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100. |
| 02 | Code Lists (EAS) | Update of the Electronic Address Scheme (BT-34, BT-49). Support for new identifiers for the Peppol network (e.g. new ISO codes for EU countries) that were missing in 2.3. |
| 03 | Rounding logic | Implementation of the “Allowance/Charge” calculation at document level (BT-92). 2.4 calls for a stricter alignment of the sum of the line item VAT with the total (avoidance of 1-cent differences). |
| 04 | Profile EXTENDED | Extension of support for “pre-payment”. The linking of final invoices with payments already made has been clarified in XML mapping (BT-93). |
| 05 | Validation Rules | Update of Schematron files (CII). On the programming side, the new XSLT files must be included for validation in order to prevent “false positives” at legal zero percent tax rates. |
| 06 | References | BT-12 (reference number) and BT-13 (order number) in 2.4 allow a longer string and stricter pattern checking in order to remain compliant with the requirements of XRechnung 3.x (B2G). |
| 07 | Payment Terms | Refinement of BT-81 (Payment Terms). When using the EXTENDED profile, cash discount scales can now be mapped more technically than was provided for in the basic standard. |
Migration factur-x.xml from version 2.0 to 2.4
| Pos. | Range | Concrete change in the XML code |
| 01 | Profile ID | The value in the field inside the ExchangedDocumentContext must be adjusted.
Old: New: |
| 02 | XMP Metadata | In the PDF container (outside of this XML), the XMP metadata must be set to zf:version="2.4" Factur-X equivalent fx:version="1.0.07" . |
| 03 | Tax Reference | Make sure that the current UNCL5305 meets the current standards. For 16% (your XML) ‘S’ (default) is correct, but the calculation must now follow the rounding rules of EN 16931 more strictly. |
| 04 | EAS Codes | If you use for the parties in the future , the Electronic Address Scheme Codes version 2.4 (Peppol compatible) must be used. In your example, you are currently only using names and addresses. |
| 05 | Payment term | In your XML, this is 02/12/2026. Check to see if there SpecifiedTradePaymentTerms is any redundancy, as version 2.4 prioritizes machine-only logic in the date fields. |
| 06 | Validation | The document must be validated against the new Schematron rules of 2.4 . In particular, the correlation between TaxTotalAmount and GrandTotalAmount is tested more strictly against rounding errors in 2.4. |
ZUGFeRD and SAP
The unstructured PDF file is for long-term storage and is better suited for viewing and printing. The structured invoice data is carried by the appendix in XML format, which the software reads out and can process automatically in a hurry. By the way, also in the already existing SAP systems of your company.
Tip: Do you work with SAP? We extend your systems to invoicing with ZUGFeRD!
Result
ZUGFeRD is a hybrid that combines two formats. Thus, it is the right choice for companies that are in some way also “hybrids” – i.e. in the transition phase from analog to digital and want to automate standard business processes.
With ZUGFeRD, they keep all paths open. In the type of processing, but also in the choice of business partners (B2B, B2G). In addition, by ZUGFeRD, they will still be able to send legal invoices to the public administration after 27/11/2020, as the format is COMPLIANT with EU directives.



