ZUGFeRD packs two things into one file: a PDF that humans can read and an embedded XML under EN 16931 for machines. The idea is pragmatic, and in many B2B relationships it works. In practice, however, the dual structure frequently becomes the problem itself. A good year into the German receiving mandate, I summarized this in a field report.
I help on both sides: generating compliant ZUGFeRD invoices from the ERP, and receiving them in a way that actually uses the embedded XML instead of ignoring it.
Where ZUGFeRD fits
The hybrid format plays to its strength when recipients need both automated processing and a human-readable document for approvals or filing. Delivery works by email, with no portal or network infrastructure. For many German SMEs, ZUGFeRD is therefore the practical route into the issuing mandate from 2027, provided the profile is right.
Where it fails in practice
The findings from current projects, without exaggeration:
- The XML gets ignored. Accounting retypes the PDF view even though structured data is delivered alongside it.
- Profile confusion: ZUGFeRD comes in MINIMUM, BASIC WL, BASIC, EN 16931 (COMFORT) and EXTENDED. Sending MINIMUM formally satisfies the mandate but delivers hardly any usable data.
- There is no binding sender-side validation; broken XML files only surface during the recipient’s import.
- Many ERP imports abort on profile deviations or edge cases, offering a cryptic log entry instead of error handling.
GoBD: the XML is the original
The German GoBD rules require retaining the original digital format: for ZUGFeRD that is the embedded XML, not the PDF view. Archiving only the PDF creates a compliance problem. Both parts belong in the archive together.
In projects I test the ERP import against real supplier invoices rather than the vendor’s feature list, define profile requirements for suppliers (EN 16931/COMFORT as the minimum for automated processing) and set up validation and archiving properly. The bigger picture is on the E-Invoicing & DATEV overview.