Shopify
WooCommerce
Shopware
JTL-Shop
Magento
PrestaShop
n8n
Zapier
Make
Airtable
HubSpotWarum es überhaupt Profile gibt
ZUGFeRD ist ein Hybridformat: ein PDF, das eine XML-Rechnung eingebettet trägt. Das PDF sieht immer gleich vollständig aus. Wie viel davon auch als Datenfeld vorliegt, ist die Frage, die das Profil beantwortet.
Der Grund für die Staffelung ist historisch. Als ZUGFeRD entstand, sollte auch derjenige mitmachen können, der sein PDF nicht umbauen wollte — daher die kleinen Profile. Mit der E-Rechnungspflicht hat sich der Zweck verschoben: Heute ist die interessante Frage nicht mehr „was geht mindestens", sondern „was zählt".
Die Profile im Überblick
| Profil | Positionen | Umfang | Vollwertige E-Rechnung? |
|---|---|---|---|
| MINIMUM | nein | Rechnungssteller, Summen, Datum | 🔴 nein |
| BASIC WL | nein | Kopfdaten + Steueraufschlüsselung | 🔴 nein |
| BASIC | ja | einfacher Positionssatz | 🟡 eingeschränkt |
| EN 16931 | ja | vollständiger Kern der Norm | 🟢 ja |
| EXTENDED | ja | Kern + zusätzliche Felder | 🟢 ja, mit Vorbehalt |
| XRECHNUNG | ja | Kern + deutsche Zusatzregeln | 🟢 ja |
Die Linie, auf die es ankommt
Zwischen BASIC WL und BASIC verläuft die Grenze zwischen „Buchungshilfe" und „Rechnung". Zwischen BASIC und EN 16931 verläuft die Grenze zwischen „geht für einfache Fälle" und „erfüllt die Norm".
🔴 Der teuerste Irrtum in der Praxis ist, ein MINIMUM-ZUGFeRD für eine E-Rechnung zu halten. Die Datei sieht aus wie eine — sie ist ein PDF mit XML darin, sie trägt das ZUGFeRD-Logo, sie öffnet sich normal. Sie enthält aber keine Positionen und keine vollständige Steueraufschlüsselung, und ein Empfänger, der die Norm prüft, weist sie zurück.
Woran Sie das Profil einer Datei erkennen
Das Profil steht im XML selbst, in der Spezifikationskennung (BT-24). Bei einer CII-Datei finden Sie sie hier:
1<rsm:ExchangedDocumentContext>2 <ram:GuidelineSpecifiedDocumentContextParameter>3 <ram:ID>urn:cen.eu:en16931:2017</ram:ID>4 </ram:GuidelineSpecifiedDocumentContextParameter>5</rsm:ExchangedDocumentContext>Die Kennung endet je nach Profil unterschiedlich — ...:minimum, ...:basicwl,
...:basic oder, wie oben, die reine Kennung der Norm für das Profil EN 16931.
Was dort steht, ist die verbindliche Auskunft. Der Dateiname sagt nichts, das
Logo im PDF sagt nichts.
💡 Sie müssen dafür nicht ins XML greifen: Ein Validator liest die Kennung aus und nennt Ihnen das erkannte Profil im Ergebnis.
Welches Profil wofür
An eine deutsche Behörde. Entweder eine XRechnung als reines XML oder ein ZUGFeRD im Profil XRECHNUNG. Die kleineren Profile scheitern an den deutschen Zusatzregeln, unabhängig von der Norm.
An ein Unternehmen im Inland. EN 16931 ist die richtige Vorgabe. Es erfüllt die Norm, bleibt aber im interoperablen Bereich — jeder Empfänger, der überhaupt E-Rechnungen verarbeitet, kann es lesen.
Ins europäische Ausland. Ebenfalls EN 16931. EXTENDED nur dann, wenn Sie mit dem Empfänger ausdrücklich vereinbart haben, dass er die Zusatzfelder auswertet; sonst schicken Sie Daten, die niemand ansieht.
An Privatkunden. Hier greift die Pflicht nicht. ZUGFeRD ist trotzdem sinnvoll, weil dieselbe Datei lesbar und auswertbar ist — der Kunde sieht ein PDF, sein Steuerberater bekommt Daten.
Ein Profil ist eine Untergrenze, keine Obergrenze
Ein häufiges Missverständnis: Man müsse sich für ein Profil entscheiden und dürfe dann nur dessen Felder benutzen. Tatsächlich beschreibt ein Profil, welche Felder mindestens unterstützt werden müssen. Ein Empfänger, der EN 16931 verarbeitet, kommt mit einer BASIC-Datei problemlos zurecht — sie enthält schlicht weniger.
Die Richtung, in der es klemmt, ist die andere: Wer EXTENDED schickt, kann nicht davon ausgehen, dass die Zusatzfelder ankommen. Sie gehen nicht verloren, sie werden ignoriert. Das ist der Unterschied zwischen „die Datei wird abgelehnt" und „die Information kommt nicht an" — und der zweite Fall fällt später auf.