ZUGFeRD profiles explained: why MINIMUM and BASIC WL don't count in Germany

By evoicely · Last checked 19 October 2026

A ZUGFeRD file is only an e-invoice in Germany if its profile is BASIC or higher. The Federal Ministry of Finance accepts ZUGFeRD from version 2.0.1, except the MINIMUM and BASIC WL profiles, because those two don't carry a complete invoice as structured data. If you're unsure which profile to use, choose EN 16931 (formerly COMFORT). It contains everything the European standard defines and nothing beyond it.

The six profiles at a glance

The specification defines five profiles, each containing the previous one, plus the XRECHNUNG reference profile for Germany. The profile is named in the embedded XML as the specification identifier (business term BT-24, element ram:GuidelineSpecifiedDocumentContextParameter/ram:ID).

Sources: profile descriptions and identifiers from the Factur-X/ZUGFeRD specification 1.07.2 (FNFE-MPE and FeRD, 15 November 2024; download from FeRD or FNFE-MPE). The XRECHNUNG identifier is from the XRechnung 3.0.2 specification (KoSIT). The same values appear in the Mustang project's profile list, an open-source ZUGFeRD library and validator. In the PDF's XMP metadata, the profile appears again as fx:ConformanceLevel, with plain names such as EN 16931.

Why MINIMUM and BASIC WL don't count

Since 2025, a German e-invoice must follow EN 16931 or a format the two parties agreed on. The Federal Ministry of Finance's administrative guidance (UStAE section 14.1 (14)) puts it like this: "Beispielsweise das hybride Format ZUGFeRD ab der Version 2.0.1 – ausgenommen die Profile MINIMUM und BASIC-WL – beruht auf der Normenreihe EN 16931 und fällt somit unter die zulässigen E-Rechnungs-Formate." In short: ZUGFeRD from 2.0.1 qualifies, except MINIMUM and BASIC WL. (BMF letter of 15 October 2025)

The specification gives the reason. Neither profile carries what a German invoice must contain under § 14 UStG, so the specification calls them only a booking aid ("Buchungshilfe"). BASIC WL has no invoice lines at all, so it can't describe what was supplied. MINIMUM has even less. A PDF with one of these profiles is still a PDF invoice, the kind that stops being enough for domestic B2B in Germany once the transition ends (see Germany's e-invoicing mandate).

BASIC, EN 16931 or EXTENDED?

• BASIC follows all EN 16931 rules but leaves out some of its optional fields, so it's a smaller file with the same core.
• EN 16931 covers the full standard, optional fields included, and nothing beyond it. That makes it the safe default.
• EXTENDED adds data that EN 16931 doesn't define. The specification marks it as "conformant" rather than "compliant": it extends EN 16931 with data and code values the standard doesn't define. Use it only if a customer asks for that data.

The XRECHNUNG profile

ZUGFeRD can also carry an XRechnung: a PDF whose embedded XML follows the German XRechnung rules, such as a mandatory buyer reference (BT-10, where a Leitweg-ID goes). According to FeRD, the embedded file is named factur-x.xml for the regular profiles and xrechnung.xml for this one, and each PDF may contain only one of them (ZUGFeRD FAQ). Some buyers, public authorities in particular, may want a plain XRechnung XML file instead, so check what the buyer accepts before you send either.

ZUGFeRD and Factur-X are the same format

ZUGFeRD is the German name, Factur-X the French one. FeRD and the French FNFE-MPE publish one joint specification, and FNFE-MPE says: "Technically, both Factur-X and ZUGFeRD are identical." The current joint release is Factur-X 1.09.2 / ZUGFeRD 2.5.2, published on 4 August 2026 (FNFE-MPE, FeRD). The version numbers differ, but the profile names and identifiers in the table above are shared.

How to tell which profile a file uses

Extract the embedded XML from the PDF and look at the start of the document. This excerpt is from an EN 16931 file generated by evoicely's converter from fictional data. The Mustang validator in our test suite accepts the full file as EN 16931. The <!-- --> comments were added for this page.

<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100" ...>
  <rsm:ExchangedDocumentContext>
    <ram:BusinessProcessSpecifiedDocumentContextParameter>   <!-- BT-23 business process -->
      <ram:ID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</ram:ID>
    </ram:BusinessProcessSpecifiedDocumentContextParameter>
    <ram:GuidelineSpecifiedDocumentContextParameter>         <!-- BT-24: the profile -->
      <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  ...

If BT-24 says minimum or basicwl, ask the sender for a new invoice with a qualifying profile. The XMP metadata in the PDF should name the same profile.

Related guides

• XRechnung vs ZUGFeRD: which format to send.
• Germany's e-invoicing mandate for Stripe users: who has to send e-invoices, and from when.
• Mapping a Stripe invoice to EN 16931: the fields behind an EN 16931 file.

Where evoicely fits

evoicely is being built to turn your Stripe invoices into ZUGFeRD files with the EN 16931 profile: a PDF/A-3 that people can read, with the XML embedded as factur-x.xml, checked with the Mustang validator. It doesn't produce MINIMUM, BASIC WL or EXTENDED. XRechnung for buyers who need it is planned as well. It's not available yet. Join the waitlist.

This is general information, not legal or tax advice. Check what applies to your business with your tax advisor.