ZUGFeRD erstellen: Anleitung 2026 mit Profilen BASIC, EN16931 & EXTENDED

Eine ZUGFeRD-Rechnung ist ein PDF/A-3-Dokument mit unsichtbar eingebettetem XML. Für die deutsche E-Rechnungspflicht sind laut BMF nur die Profile MINIMUM und BASIC WL ausgeschlossen; BASIC ist grundsätzlich zulässig, während EN 16931 für breite B2B-Interoperabilität die empfohlene Standardwahl bleibt. Die gute Nachricht: Ein valides ZUGFeRD-Dokument im richtigen Profil lässt sich kostenlos im Browser erstellen — in fünf klar abgegrenzten Schritten.

Diese Anleitung erklärt, welches der vier Profile für welchen Empfänger gilt, wie die Erstellung Schritt für Schritt abläuft und warum eine Validierung vor dem Versand dringend empfohlen ist.

Was ist eine ZUGFeRD-Rechnung und wie funktioniert das Format?

ZUGFeRD steht für Zentraler User Guide des Forums elektronische Rechnung Deutschland. Das Format verbindet zwei Dokumenttypen in einer einzigen Datei: ein visuell lesbares PDF/A-3 und eine im Hintergrund eingebettete XML-Datei, die Buchhaltungssysteme automatisch einlesen und verbuchen können.

Der entscheidende Vorteil gegenüber XRechnung: ZUGFeRD-Dokumente sind ohne Spezialsoftware lesbar — der Empfänger öffnet einfach das PDF mit einem normalen Viewer. Gleichzeitig lesen DATEV, SAP Business One, lexoffice und alle anderen gängigen Buchhaltungssysteme die eingebettete XML automatisch aus und buchen die Rechnung damit ohne manuelle Eingabe. XRechnung dagegen besteht ausschließlich aus XML; für die menschlich lesbare Darstellung ist ein Viewer zwingend erforderlich.

ZUGFeRD 2.5 basiert auf der europäischen Norm EN 16931 und UN/CEFACT CII D22B; die Spezifikation ist vollständig rückwärtskompatibel zu D16B. Seit dem 1. Juli 2026 ist ZUGFeRD 2.5 die aktuelle Version — ältere Versionen 2.2 und 2.3.3 bleiben rückwärtskompatibel und werden weiterhin von gängigen Buchhaltungssystemen akzeptiert. Einen vollständigen Vergleich zwischen ZUGFeRD, XRechnung und Peppol liefert der E-Rechnung Format Vergleich 2026.

ZUGFeRD-Profile MINIMUM, BASIC, EN16931 und EXTENDED: welches gilt für wen?

ZUGFeRD 2.5 definiert fünf Kernprofile plus das Referenzprofil XRECHNUNG mit unterschiedlichem Umfang an strukturierten Daten. Die Wahl des falschen Profils ist der häufigste Fehler beim ZUGFeRD erstellen — und der mit den schwerwiegendsten Folgen.

MINIMUM und BASIC WL reichen laut BMF nicht für die gesetzliche E-Rechnungspflicht. BASIC ist grundsätzlich zulässig, bildet aber weniger strukturierte Felder ab als EN 16931. Für neue B2B-Rechnungen ist EN16931 deshalb die robustere Standardwahl.

EN16931 ist das empfohlene Standardprofil für reguläre B2B-Rechnungen. Es bildet die semantischen Kerndaten der europäischen Norm strukturiert ab. Sofern keine branchenspezifischen Anforderungen bestehen, ist EN16931 die richtige Wahl für das ZUGFeRD erstellen im Geschäftsalltag.

EXTENDED erlaubt zusätzliche nationale oder branchenspezifische Felder jenseits von EN 16931 — beispielsweise separate Zolltarifnummern oder detaillierte Lieferbedingungen nach Incoterms. Für Kleinunternehmer, Freiberufler und die meisten KMU ist EXTENDED nicht notwendig.

Empfehlung für die Praxis: Wählen Sie EN16931, solange Ihr Empfänger keine abweichende Anforderung kommuniziert. Wer für öffentliche Auftraggeber (Bund, Länder, Kommunen) abrechnet, braucht stattdessen das reine XML-Format XRechnung — dazu mehr in der Gegenüberstellung ZUGFeRD vs. XRechnung.

ZUGFeRD erstellen: Schritt-für-Schritt-Anleitung mit kostenlosem Browser-Generator

Ein valides ZUGFeRD-Dokument im EN16931-Profil benötigt fünf Schritte — von der Dateneingabe bis zum Download der fertigen PDF/A-3-Datei.

Schritt 1 — Rechnungsstammdaten eintragen: Pflichtfelder nach §14 UStG: Name und vollständige Anschrift von Rechnungssteller und -empfänger, Steuernummer oder USt-IdNr. des Ausstellers, Rechnungsdatum (BT-2) und fortlaufende Rechnungsnummer (BT-1). Falls der Empfänger eine Bestellreferenz mitgeteilt hat (BT-13), wird diese hier eingetragen — das Feld ist optional und kann leer bleiben, ohne den Validator zu beeinflussen.

Schritt 2 — Leistungspositionen hinzufügen: Jede Position muss eine Artikelbezeichnung im Feld BT-153 enthalten — dieses Pflichtfeld löst den häufigsten Validierungsfehler aus, wenn es fehlt oder leer bleibt. Neben der Bezeichnung tragen Sie Menge, Einheit, Einzelpreis netto und Steuersatz ein. DATEV und SAP lesen diese Positionsfelder direkt aus; eine präzise Bezeichnung beschleunigt die Buchung beim Empfänger spürbar.

Schritt 3 — Steuersatz und Steuerkategorie wählen: Standardfall B2B Deutschland: Steuersatz 19 % (oder 7 % für ermäßigte Leistungen), Steuerkategorie-Code S. Kleinunternehmer nach §19 UStG: Steuersatz 0 %, Kategorie-Code O (not subject to VAT) und der gesetzlich vorgeschriebene §19-Hinweistext im Rechnungstext. Reverse Charge bei grenzüberschreitenden B2B-Leistungen: Steuersatz 0 %, Kategorie-Code AE, Pflichthinweis „Steuerschuldnerschaft des Leistungsempfängers gemäß Art. 196 MwStSystRL”.

Schritt 4 — Profil EN16931 wählen und ZUGFeRD erstellen: Beim Download wählen Sie explizit ZUGFeRD 2.5 / Profil EN16931. Ein guter Generator — wie der kostenlose ZUGFeRD Generator — setzt das Profil-Attribut im XML-Header automatisch korrekt auf urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931. Die XML-Struktur folgt dem CII-D22B-Datenmodell, bleibt zu D16B rückwärtskompatibel und wird lückenlos in den PDF/A-3-Container eingebettet. Die Dateigröße eines typischen ZUGFeRD-Dokuments mit drei Positionen liegt zwischen 80 und 200 KB.

Schritt 5 — Validieren (dringend empfohlen): Laden Sie die erzeugte PDF-Datei auf den KoSIT-Validator (validator.kosit.de) hoch. Ein valider Report zeigt ausschließlich grüne Statuscodes — ein einziger roter Fehlercode führt zur stillen Ablehnung im ERP-System des Empfängers, ohne automatische Rückmeldung an Sie.

ZUGFeRD validieren: KoSIT-Prüfung vor dem Versand

Der KoSIT-Validator (Koordinierungsstelle für IT-Standards) prüft E-Rechnungen anhand konfigurierter Syntax- und Geschäftsregeln. Er prüft zwei Fehlerkategorien:

Schema-Validierung: Stimmt die XML-Struktur mit dem für ZUGFeRD 2.5 verwendeten CII-D22B-Schema überein? Fehlende Pflichtfelder oder falsch typisierte Datenfelder werden als FATAL-Fehler ausgewiesen. Ein FATAL-Fehler blockiert die maschinelle Verarbeitung vollständig.

Geschäftsregel-Validierung: Verletzt die Rechnung eine der EN-16931-Kernregeln (BR-Codes) oder eine deutsche CIUS-Spezifikation (BR-DE-Codes)? Geschäftsregeln prüfen die inhaltliche Korrektheit — etwa, ob der Gesamtnettobetrag mit der Summe aller Positionsbeträge übereinstimmt.

Die drei häufigsten Validierungsfehler aus der Praxis:

1. BR-55: BT-5 (Währungscode) fehlt oder ist nicht auf EUR gesetzt — häufig bei Importen aus Tabellenprogrammen ohne explizite Währungsangabe.
2. BR-CO-15: Der berechnete Gesamtnettobetrag weicht von der Summe der Positionsbeträge ab — Sub-Cent-Rundungsdifferenzen durch Float-Arithmetik beim manuellen Ausfüllen.
3. BR-25: BT-153 (Artikelname je Position) fehlt in mindestens einer Rechnungsposition.

Eine alternative Prüfung und gleichzeitige Visualisierung ermöglicht der Ratgeber ZUGFeRD visualisieren und prüfen — dort lässt sich die eingebettete XML direkt im Browser einsehen, ohne die Datei manuell entpacken zu müssen.

ZUGFeRD per E-Mail versenden: Pflichtinhalt und Praxis-Setup

ZUGFeRD-Rechnungen werden in der Praxis überwiegend per E-Mail zugestellt. Das Format stellt dabei keine besonderen technischen Anforderungen — die ZUGFeRD-PDF ist der einzige Anhang; zusätzliche separate XML-Dateien sind nicht erforderlich, da die XML vollständig in der PDF eingebettet ist.

Empfehlung zur Dateibenennung: Schema Rechnung-[RechnungsNr]-[Datum].pdf — viele ERP-Systeme erkennen eingehende E-Rechnungen automatisch, wenn Betreff oder Dateiname die Rechnungsnummer enthält.

E-Mail-Betreff: Kein gesetzlich vorgeschriebener Standard. Praxisüblich: „Rechnung [Nr.] vom [Datum] — [Unternehmensname]”. Buchhalter und ERP-Importroutinen bevorzugen strukturierte Betreffs ohne Sonderzeichen.

DKIM/SPF für eigene Domains: Für den Versand über eine eigene Domain müssen DKIM- und SPF-Einträge korrekt konfiguriert sein — fehlen sie, landen ZUGFeRD-Rechnungen im Spam-Filter des Empfängers und werden nie geöffnet. Wer eigene Domain-Einstellungen noch nicht konfiguriert hat, kann den E-Mail-Versand über die Plattform nutzen, die den Versand über zertifizierte Mailserver übernimmt.

Rechtlicher Rahmen: Seit dem 1. Januar 2025 müssen alle B2B-Unternehmen in Deutschland strukturierte E-Rechnungen empfangen können. Die Versandpflicht gilt ab 1. Januar 2027 für Unternehmen mit mehr als 800.000 € Jahresumsatz und ab 1. Januar 2028 für alle übrigen B2B-Aussteller. Kleinunternehmer sind nach § 34a UStDV dauerhaft von der Ausstellungspflicht befreit. Wer für Behörden abrechnet, benötigt für diesen spezifischen Empfänger XRechnung; die Schritte erläutert die XRechnung erstellen Anleitung.

Häufige Fehler beim ZUGFeRD erstellen — und wie Sie diese vermeiden

Drei Fehlerquellen begegnen Neuanwendern bei fast jedem ersten ZUGFeRD erstellen-Versuch:

Fehler 1 — Profil passt nicht zum Empfänger: MINIMUM und BASIC WL reichen für die gesetzliche E-Rechnungspflicht nicht. BASIC ist grundsätzlich zulässig; EN16931 ist für breite B2B-Interoperabilität empfohlen, und öffentliche Auftraggeber können das XRECHNUNG-Profil oder reine XRechnung verlangen. Prüfen Sie deshalb vor dem Export die Vorgaben des Empfängers und validieren Sie anschließend genau gegen das gewählte Profil.

Fehler 2 — Rundungsdifferenzen in Positionsbeträgen: Wer Beträge manuell in Tabellenprogramme einträgt und als CSV importiert, riskiert Rundungsdifferenzen durch Float-Arithmetik — etwa 3 × 33,33 € = 99,99 € statt exakt 99,99 €. Der KoSIT-Validator meldet das als BR-CO-15. Lösung: Positionsbeträge vor der Übergabe an den Generator auf zwei Dezimalstellen runden; kaufmännisch gerundete Werte sind gesetzlich korrekt (ROUND_HALF_UP).

Fehler 3 — Leeres Pflichtfeld BT-153: Jede Rechnungsposition muss eine Artikelbezeichnung in BT-153 enthalten. Eine rein visuelle Beschreibung im PDF-Bereich ohne entsprechendes XML-Feld führt zu einem BR-25-Fehler im Validator — auch dann, wenn die gedruckte Rechnung vollständig aussieht. Der Generator muss den Bezeichnungstext auch in den XML-Teil schreiben, nicht nur in das sichtbare PDF-Layout.

Quellen

• ZUGFeRD 2.5 Spezifikation — Forum elektronische Rechnung Deutschland (FeRD/AWV), 10. Juni 2026. ferd-net.de
• EN 16931-1:2026 und unterstützende Artefakte — Europäische Kommission, Stand 2026; die Ausgabe 2017 bleibt während der Migration konform. digital-building-blocks.ec.europa.eu
• BMF: FAQ zur obligatorischen elektronischen Rechnung — Bundesministerium der Finanzen, Stand 2026. bundesfinanzministerium.de
• KoSIT-Validator für E-Rechnungen (validator.kosit.de) — Koordinierungsstelle für IT-Standards, 2026. validator.kosit.de
• §14 UStG – Ausstellung von Rechnungen — Umsatzsteuergesetz in der Fassung des Wachstumschancengesetzes, 2024. gesetze-im-internet.de