# ZUGFeRD-Profile erklärt

> https://billhorse.com/leitfaeden/zugferd-profile/

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.

## Die Profile im Überblick

**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.

## MINIMUM und BASIC WL sind keine vollwertigen Rechnungen

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.

## Woran das Profil technisch erkannt wird

Das Profil steht in der Spezifikationskennung [BT-24](/begriffe/bt-24/). Im CII-XML von ZUGFeRD/Factur-X ist das der `GuidelineSpecifiedDocumentContextParameter` am Anfang der Datei:

```xml
<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.

## Was der Validator pro Profil meldet

Bei MINIMUM und BASIC WL meldet Billhorse [BH-PROFILE-01](/regeln/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](/regeln/bh-profile-02/): konform zur EN 16931, aber nicht „compliant" — der Empfänger muss das Profil unterstützen. [BH-PROFILE-03](/regeln/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](/regeln/bh-zf1-01/): Das Altformat ist nicht EN-16931-konform und erfüllt die E-Rechnungspflicht nicht.

Alle Prüfungen laufen im [Browser-Validator](/zugferd-validator/) direkt auf Ihrem Rechner; dieselbe Engine steht über die API (validate/parse, private Beta) bereit.

## Welches Profil beim Erzeugen wählen?

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.