Von MINIMUM bis EXTENDED: was die Profile enthalten, wie sie an BT-24 erkannt werden — und warum MINIMUM und BASIC WL keine vollwertigen E-Rechnungen sind.
ZUGFeRD 2.x und Factur-X sind derselbe Standard: ein PDF/A-3, in das ein CII-XML (meist factur-x.xml) eingebettet ist. Der deutsche Herausgeber heißt FeRD, der französische FNFE-MPE — technisch gibt es keinen Unterschied. Was Rechnungen dieses Formats tatsächlich unterscheidet, ist das Profil: der Datenumfang, den das XML abdeckt. Und das Profil entscheidet darüber, ob eine Datei überhaupt als E-Rechnung gilt.
MINIMUM enthält nur Eckdaten: Verkäufer, Käufer, Rechnungsnummer, Datum, Gesamtbeträge und die USt-Summe. Keine Positionen, keine USt-Aufschlüsselung. BASIC WL („without lines”) ergänzt vollständige Kopf- und Fußdaten — Parteien, Zahlungsangaben, USt-Aufschlüsselung nach Kategorien — bleibt aber ebenfalls ohne Positionsdaten. BASIC ist eine Teilmenge der EN 16931 mit Positionsdaten und damit das kleinste vollwertige Profil; es reicht für strukturell einfache Rechnungen. EN 16931 (früher COMFORT) bildet den vollen Datenumfang der Norm ab und ist der Standardfall. EXTENDED geht darüber hinaus — etwa mehrere Lieferorte oder komplexe Zu- und Abschlagskaskaden. Es ist konform zur Norm („conformant”), aber keine Teilmenge mehr.
Daneben existiert XRECHNUNG als Referenzprofil: ein ZUGFeRD-XML, das zugleich die deutsche CIUS XRechnung erfüllt — gedacht für Behördenrechnungen im hybriden PDF-Umschlag. Billhorse erkennt solche Dateien an der XRechnung-URN und prüft sie mit den XRechnung-Regeln.
Die EN 16931 verlangt Positionsdaten. MINIMUM und BASIC WL lassen sie weg und sind damit keine E-Rechnungen im Sinne der Norm — die ZUGFeRD-Spezifikation selbst stuft sie als bloße Buchungshilfe ein. Praktisch heißt das für die Eingangsverarbeitung: Positionen lassen sich nicht gegen Bestellungen abgleichen, die Summenarithmetik ist nicht vollständig prüfbar, und der Empfänger muss auf das PDF-Sichtbild zurückgreifen.
In Deutschland hat das seit 2025 direkte Folgen: Die Empfangspflicht für E-Rechnungen im B2B gilt seit dem 1. Januar 2025, die Ausstellungspflicht folgt gestaffelt ab 2027. Maßgeblich ist eine EN-16931-konforme Rechnung — MINIMUM und BASIC WL erfüllen das nicht. Wer sie verschickt, verschickt formal keine E-Rechnung. In Frankreich zieht die Réforme dieselbe Grenze: Dort ist BASIC das Mindestprofil des verpflichtenden Sockels.
Das Profil steht in der Spezifikationskennung BT-24. Im CII-XML von ZUGFeRD/Factur-X ist das der GuidelineSpecifiedDocumentContextParameter am Anfang der Datei:
<rsm:ExchangedDocumentContext>
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>Die URN-Werte der Profile:
| URN (BT-24) | Profil |
|---|---|
urn:factur-x.eu:1p0:minimum | MINIMUM |
urn:factur-x.eu:1p0:basicwl | BASIC WL |
urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic | BASIC |
urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931 | EN 16931 (Comfort) |
urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended | EXTENDED |
urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 | XRECHNUNG (Referenzprofil) |
Billhorse wertet die Kennung case-insensitiv aus und prüft basicwl vor basic — die Reihenfolge ist wichtig, weil die BASIC-WL-URN die Zeichenkette „basic” enthält. Ein bloßes urn:cen.eu:en16931:2017 in einem CII-XML oder PDF wird ebenfalls als EN 16931 (Comfort) eingeordnet; eine XRechnung-URN mit #conformant#…extension markiert die XRechnung Extension.
Bei MINIMUM und BASIC WL meldet Billhorse BH-PROFILE-01: keine EN-16931-konforme E-Rechnung, nur Buchungshilfe — für die Pflicht mindestens BASIC, besser EN 16931 (Comfort) erzeugen. Bei EXTENDED greift BH-PROFILE-02: konform zur EN 16931, aber nicht „compliant” — der Empfänger muss das Profil unterstützen. BH-PROFILE-03 betrifft die XRechnung Extension: Sie erlaubt Unterrechnungspositionen, Summen-Abweichungen werden dort deshalb nur als Warnung gemeldet. Und taucht noch ein CrossIndustryDocument aus ZUGFeRD 1.0 auf, gibt es den Migrationshinweis BH-ZF1-01: Das Altformat ist nicht EN-16931-konform und erfüllt die E-Rechnungspflicht nicht.
Alle Prüfungen laufen im Browser-Validator direkt auf Ihrem Rechner; dieselbe Engine steht über die API (validate/parse, private Beta) bereit.
Kurz: EN 16931 (Comfort). Es deckt den vollen Datenumfang der Norm ab, jeder pflichtkonforme Empfänger muss es verarbeiten können, und es lässt sich aus denselben Daten erzeugen wie eine XRechnung. BASIC ist vertretbar, wenn Ihre Rechnungen einfach bleiben — der Abstand zu EN 16931 ist aber klein genug, dass sich die Einschränkung selten lohnt. EXTENDED nur, wenn Sie Felder brauchen, die die Norm nicht kennt, und der Empfänger das Profil ausdrücklich akzeptiert. Für deutsche Behörden nehmen Sie das XRECHNUNG-Referenzprofil oder gleich reines XRechnung-XML. MINIMUM und BASIC WL sollten Sie nicht mehr erzeugen — als Buchungshilfe erlaubt, als Rechnung nicht genug.
Der Billhorse-Validator prüft XRechnung, ZUGFeRD und Factur-X direkt im Browser — Ihre Datei wird nicht hochgeladen.
Zum Validator← Alle Guides · Stand: 2026-07-04