Which ZUGFeRD profile satisfies the e-invoicing obligation?

EN 16931 at minimum. MINIMUM and BASIC WL explicitly do not meet the standard — they carry too few structured fields. BASIC sits in between and is only enough for simple cases with no special requirements.

What is the difference between BASIC and BASIC WL?

BASIC WL stands for 'without lines' and carries no invoice lines, only header data and totals. BASIC carries the lines. The WL profile is therefore meant for bookkeeping, not for issuing invoices.

Then what is MINIMUM for?

As a booking aid. It carries barely more than issuer, amount and date, and was created so an existing PDF could gain a machine-readable core without much effort. It was never intended as an invoice.

What does EXTENDED add over EN 16931?

It adds fields the core does not know — more detailed supply-chain or line-level data. That leaves the zone of guaranteed European interoperability: the recipient has to know the extra fields, otherwise they are ignored.

What is the XRECHNUNG profile inside ZUGFeRD?

A profile that satisfies the additional German rules of XRechnung. Such a file is simultaneously ZUGFeRD and XRechnung-conformant, which suits anyone who wants one output for both public authorities and companies.

ZUGFeRD profiles: which one counts as a real e-invoice?

Why profiles exist at all

ZUGFeRD is a hybrid format: a PDF carrying an embedded XML invoice. The PDF always looks equally complete. How much of it is also available as data is the question the profile answers.

The reason for the tiering is historical. When ZUGFeRD was created, the goal was to let people join in without rebuilding their PDF pipeline — hence the small profiles. The e-invoicing obligation shifted the point: the interesting question is no longer "what is the minimum that works" but "what actually counts".

The profiles at a glance

Profile	Lines	Scope	Full e-invoice?
MINIMUM	no	issuer, totals, date	🔴 no
BASIC WL	no	header data + tax breakdown	🔴 no
BASIC	yes	simple line set	🟡 limited
EN 16931	yes	the complete core of the standard	🟢 yes
EXTENDED	yes	core + additional fields	🟢 yes, with caveats
XRECHNUNG	yes	core + German add-on rules	🟢 yes

The line that matters

Between BASIC WL and BASIC runs the border between "booking aid" and "invoice". Between BASIC and EN 16931 runs the border between "works for simple cases" and "meets the standard".

🔴 The most expensive mistake in practice is treating a MINIMUM ZUGFeRD as an e-invoice. The file looks like one — it is a PDF with XML inside, it carries the ZUGFeRD marque, it opens normally. But it has no lines and no complete tax breakdown, and a recipient who validates will reject it.

How to read a file's profile

The profile is stated in the XML itself, in the specification identifier (BT-24). In a CII file you will find it here:

xml

1<rsm:ExchangedDocumentContext>
2  <ram:GuidelineSpecifiedDocumentContextParameter>
3    <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
4  </ram:GuidelineSpecifiedDocumentContextParameter>
5</rsm:ExchangedDocumentContext>

The identifier ends differently per profile — ...:minimum, ...:basicwl, ...:basic, or, as above, the bare identifier of the standard for the EN 16931 profile. What is written there is the binding answer. The filename says nothing; the logo in the PDF says nothing.

💡 You do not have to open the XML for this: a validator reads the identifier out and reports the detected profile in its result.

Which profile for which recipient

To a German public authority. Either an XRechnung as pure XML, or a ZUGFeRD in the XRECHNUNG profile. The smaller profiles fail the German add-on rules regardless of the standard.

To a company at home. EN 16931 is the right instruction. It meets the standard while staying inside the interoperable zone — any recipient that processes e-invoices at all can read it.

Across Europe. EN 16931 as well. Use EXTENDED only where you have agreed with the recipient that they evaluate the extra fields; otherwise you are sending data nobody looks at.

To private customers. The obligation does not apply here. ZUGFeRD is still worthwhile, because the one file is both readable and processable — the customer sees a PDF, their accountant gets data.

A profile is a floor, not a ceiling

A common misunderstanding: that you must choose a profile and then use only its fields. In fact a profile describes which fields must be supported at minimum. A recipient that processes EN 16931 handles a BASIC file without trouble — it simply contains less.

The direction that does bind is the other one. Sending EXTENDED gives you no assurance that the extra fields arrive. They are not lost; they are ignored. That is the difference between "the file is rejected" and "the information does not land" — and the second one surfaces much later.