A profile does not say how good an invoice is; it says how much sits in its XML. Same visible page, same amount, same recipient — and depending on the profile the file carries either a handful of header fields or every line with its discount, tax rate and unit of measure.
The choice is not cosmetic. Two of the profiles do not count as e-invoices for VAT purposes, even though they pass every technical check. That is where this page starts.
How to tell which profile you have
The profile is written into the XML itself, in field BT-24 (in CII syntax, GuidelineSpecifiedDocumentContextParameter). It is a URN, and it is readable once you know what to look for.
| Profile | Identifier in the XML |
|---|---|
| MINIMUM | urn:factur-x.eu:1p0:minimum |
| BASIC WL | urn:factur-x.eu:1p0:basicwl |
| BASIC | urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic |
| EN 16931 | urn:cen.eu:en16931:2017 |
| EXTENDED | urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended |
| XRECHNUNG | urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 |
Three things can be read off that straight away:
urn:cen.eu:en16931:2017is either present or it is not. For MINIMUM and BASIC WL it is not. Those profiles do not themselves claim to follow the standard.#compliant#means a CIUS — a restriction of the standard. It may make fields mandatory, shorten code lists, add rules, but it may not invent new fields. BASIC and XRECHNUNG are built that way.#conformant#means an extension. Everything the standard has is there, plus additional fields on top. EXTENDED is built that way.
The six profiles at a glance
| Profile | Line items | Counts as an e-invoice? | Intended for |
|---|---|---|---|
| MINIMUM | no | no | booking data for internal processing |
| BASIC WL | no | no | header data with allowances, no individual lines |
| BASIC | yes, reduced | yes | simple invoices with no complications |
| EN 16931 | yes, complete | yes | the normal case in B2B |
| EXTENDED | yes, plus extra fields | yes | situations the standard does not model |
| XRECHNUNG | yes, complete | yes | German public-sector buyers |
MINIMUM and BASIC WL: technically valid, legally not an invoice
The German finance ministry stated in its ruling of 15 October 2024, and confirmed in 2025, that what is recognised is ZUGFeRD from version 2.0.1 excluding the MINIMUM and BASIC WL profiles. The reason is substantive rather than formal: neither carries the mandatory particulars required by German VAT law in full, in machine-readable form. MINIMUM has reduced header data only; BASIC WL has no invoice lines at all — “WL” stands for without lines.
Why this goes wrong so easily. A MINIMUM file is not shoddy work. It validates, it opens, it looks like an e-invoice — it simply does not count as one. That is exactly what makes the mistake expensive: it does not surface when you create the file, but at the recipient or in an audit. If you are looking for “the smallest profile that still passes”, you are looking for BASIC, not MINIMUM.
So what are the two good for? For cases where no invoice in the legal sense arises anyway: passing booking data internally, pre-entry, moving documents between systems. MINIMUM does not even carry the VAT breakdown — a VAT-registered business cannot issue a proper invoice with it, in Germany or in France.
BASIC — when the invoice really is simple
BASIC is a CIUS of the standard: it brings line items back, but with a reduced set of fields. For an invoice covering a few services at one tax rate, with no discount tiers, no separate delivery address and no foreign currency, it is enough, and the recipient can post it in full.
The catch is practical rather than technical: as soon as a transaction falls outside that frame, the field you need is missing from BASIC — and you notice only once the invoice exists. If you cannot be sure all your invoices will stay simple, EN 16931 is the quieter ride.
EN 16931 — the normal case
This profile is the European standard itself, with nothing restricted and nothing added. It covers the complete semantic core model: lines with quantity, unit and unit price, allowances and charges at both line and document level, the tax breakdown per rate and category, payment terms, a separate delivery address, references to order and contract.
In older ZUGFeRD releases this profile was called COMFORT. If you still find that name in a manual or a contract, EN 16931 is what is meant. It was renamed because an invented name gave no clue that this particular profile is the one that matches the standard.
In practice, EN 16931 means the recipient gets everything they need to post the invoice automatically, and the file passes the full set of business rules. That is why it is the default whenever nothing else has been explicitly demanded.
EXTENDED — and what it is not for
EXTENDED is an extension: everything in EN 16931 plus fields the standard does not provide. The typical ones are references to projects, measurements and contracts in construction, packaging and transport details in wholesale, additional party roles in multi-tier supply chains.
A widespread misconception: that EXTENDED is needed for multiple tax rates or for discounts. It is not. Several tax rates in one document, allowances and charges at line and document level, foreign currency, credit notes — EN 16931 already handles all of that. You need EXTENDED only when a recipient asks for a field the standard does not know at all.
And it has a price. Additional fields are understood only by software that knows them; a recipient validating strictly against EN 16931 will at best ignore them. On top of that: the ZUGFeRD 2.5.2 corrigendum of 4 August 2026 cleaned up inconsistencies in validation rules, rounding and tax breakdown precisely in the EXTENDED profile — a hint that this is where the tangled cases live. Use EXTENDED when you can name a reason. Not as a precaution.
The XRECHNUNG profile is not the same thing as an XRechnung
Two different things with almost the same name:
- XRechnung is a format in its own right — a plain XML file with no PDF around it, the German CIUS of the standard, required by many public-sector buyers.
- The ZUGFeRD XRECHNUNG profile is a hybrid PDF whose embedded XML follows the XRechnung rules. Visible page and structured data in one document, with the rule set the public-sector buyer expects.
If you supply public bodies, ask which of the two they want, and remember that they usually require a routing ID (BT-10). Without it the invoice fails on a German national rule rather than on the standard — see rule codes.
Which profiles E-Rechnung Pro issues
Three: BASIC, EN 16931 and EXTENDED, with EN 16931 as the default. We deliberately do not offer MINIMUM or BASIC WL — they would produce a file that looks like an e-invoice and is not one. Anyone who genuinely needs them needs them for a purpose our route would be wrong for anyway.
Incoming files are validated in every profile regardless, XRechnung included — the report names the profile it detected and checks against that rule set, not another one.
Frequently asked questions
Which profile should I pick if I know nothing else?
EN 16931. It matches the standard, it is accepted everywhere and it leaves no field missing. You pick a different profile when someone asks for it — not on your own initiative.
Can a recipient dictate a profile?
Yes, and larger recipients do. It is usually stated in the supplier documentation or the ordering portal. If EXTENDED is demanded, ask which field from it is actually needed — often it is exactly one, and sometimes it turns out EN 16931 has it too.
How do I find the profile of a file I have received?
The validation report names it. If you want to look in the XML yourself, search for GuidelineSpecifiedDocumentContextParameter — the value is the URN from the table above.
Are ZUGFeRD and Factur-X profiles the same?
Yes. Since ZUGFeRD 2.1 / Factur-X 1.0 they are the same profiles with the same identifiers; the formats themselves are two names for one thing (see What is ZUGFeRD). The XRECHNUNG addition is the German particularity; the French side has requirements of its own.
Can I change the profile afterwards?
Not in the finished file — the profile determines which fields must be present, and simply relabelling it produces a document that violates its own identifier. Generate the invoice again in the profile you want.
Is a higher profile always better?
No. EXTENDED carries fields many recipients never read, and it makes your data more valuable only if they are actually used. The value lives in the standard, not above it.
What if I already sent BASIC and the invoice had discounts on it?
Validate the file. If something the standard requires is missing, the report says so; if the file passes all three layers, it is valid. For the next invoice, change the profile — see Validate an invoice.
In short
- The profile lives in
BT-24and it is readable: ifurn:cen.eu:en16931:2017is absent, the file does not follow the standard. - MINIMUM and BASIC WL are not e-invoices — technically valid, but not for VAT. The smallest usable profile is BASIC.
- EN 16931 is the normal case, formerly called COMFORT. With no particular reason, take this one.
- EXTENDED is not a quality mark. Multiple tax rates and discounts are already covered by EN 16931; EXTENDED pays off only for fields the standard does not know.
- XRECHNUNG profile ≠ XRechnung format. Ask the public-sector buyer first, and remember the routing ID.
Want invoices in the right profile without sorting the fields by hand? Create a free account — or check an existing file without signing up and see which profile is really inside it.