ZUGFeRD und Factur-X

ZUGFeRD ist ein hybrides Format, das Menschen und Maschinen zugleich bedient. Es besteht aus einem PDF/A-3 (lesbar wie eine „normale“ Rechnung) und einem eingebetteten XML-Datensatz (maschinenlesbar). Dadurch kann der Empfänger die Rechnung notfalls einfach als PDF öffnen, während Buchhaltungssoftware parallel die strukturierten Daten automatisch ausliest. Factur-X ist eng damit verwandt: Im Kern ist Factur-X die französische Bezeichnung des deutsch-französisch harmonisierten Standards und technisch kompatibel zu ZUGFeRD (gleiche Grundidee: PDF/A-3 plus eingebettetes XML, ausgerichtet an EN 16931).

Für grenzüberschreitende Arbeit ist das meist weniger ein Technikthema als ein „Label-Thema“ in Kommunikation und Kundenanforderungen. Allerdings muss beachtet werden, dass manche französische Abrechnungssysteme andere Konventionen bei der Darstellung von Gutschriften oder Storno haben, als Deutsche Systeme. Technisch sind also ZUGFeRD und Factur-X das gleiche, deren Anwendung in den jeweiligen Ländern kann aber semantisch zu Unterschieden führen.

Obwohl eine ZUGFeRD-Rechnung aus einer PDF-Datei (für den Menschen lesbar) und einer eingebetteten XML-Datei (für die Maschine lesbar) besteht, gilt Folgendes:

• Rechtsgültigkeit: Die eingebettete XML-Datei (nach EU-Norm EN 16931) ist der rechtlich verbindliche Rechnungsbestandteil.
• Aufbewahrungspflicht: Die Datei muss elektronisch aufbewahrt werden. Ein Ausdruck der PDF-Darstellung reicht für das Finanzamt nicht aus; der digitale Datensatz (PDF + XML) ist revisionssicher zu speichern.
• Identität: PDF und XML müssen inhaltlich identisch sein. Im Zweifel oder bei Unstimmigkeiten zählt der strukturierte XML-Inhalt.

ZUGFeRD Profile

Eine ZugFERD-Datei kann in verschiedenen Profilen erstellt werden, die sich im Grad der Strukturierung und im Anwendungszweck unterscheiden. Das Profil MINIMUM enthält nur die grundlegenden Pflichtangaben und eignet sich vor allem für einfache Rechnungen ohne komplexe steuerliche oder handelsrechtliche Anforderungen. BASIC und BASIC WL (White Label) bieten zusätzliche strukturierte Informationen, etwa zu Positionen oder Steuern, bleiben jedoch bewusst schlank für standardisierte B2C- oder weniger komplexe B2B-Szenarien. Das Profil EN 16931 entspricht der europäischen Norm für die elektronische Rechnungsstellung und ist insbesondere für den öffentlichen Sektor und den europaweiten Austausch relevant. Darüber hinaus ermöglicht EXTENDED die Abbildung komplexer Geschäftsprozesse mit erweiterten Informationen, beispielsweise zu Lieferbedingungen, Referenzen oder projektspezifischen Details. 

BASIC WL

BASIC WL (White Label) entspricht inhaltlich weitgehend BASIC, ist jedoch speziell für Massenszenarien mit geringem Informationsbedarf konzipiert. Es erlaubt eine noch stärker reduzierte, praxisorientierte Nutzung, bei der viele komplexere Angaben bewusst nicht vorgesehen sind. Der Fokus liegt hier auf hoher Automatisierbarkeit und breiter Einsetzbarkeit in standardisierten Abrechnungsprozessen.

Wichtig zu beachten ist:  Es ist eine vereinfachte Variante, die jedoch die Anforderungen an eine E-Rechnung im Sinne der europäischen Norm nicht erfüllt.

XRechnung

XRechnung ist der deutsche Standard für elektronische Rechnungen an öffentliche Auftraggeber (B2G). Technisch ist XRechnung eine rein strukturierte XML-Datei (also nicht „ein PDF per E-Mail“), die EN-16931-Norm-konform ist. In der Praxis kommt XRechnung in zwei Syntaxvarianten vor (UBL oder UN/CEFACT CII), inhaltlich ist sie aber auf interoperable, automatische Verarbeitung ausgerichtet. Wer also Rechnungen an Behörden stellt, sollte sich an den jeweils geforderten XRechnung-Vorgaben und Versionen orientieren, weil Portale und Prüfsysteme Rechnungen sonst ablehnen können und sich Zahlungen verzögern.

EN16931

Der Begriff EN 16931 wird leider in zweifacher Hinsicht verwendet. Zum einen beschreibt er die europäische Norm für die elektronische Rechnungsstellung. Zum anderen ist aber auch gleichzeitig ein Profilname für die ZUGFeRD-Rechnung. Dies kann also eine Quelle für Verwirrung sein. 

Wichtig zu beachten ist, dass nur ZUGFeRD-Rechnungen in den Profilen „Basic“, „EN16931“ (hier wieder die doppelte Bedeutung), „EXTENDED“ und XRechnung zu E-Rechnungen nach der Norm EN16931 führen.

Weiterführende Links / Quellen:

– EN 16931 (Übersicht): https://e-standard.eu/en/standard/273801
– KoSIT / XRechnung-Umfeld (Visualisierung, Hintergrund): https://github.com/itplr-kosit/xrechnung-visualization
– FeRD (ZUGFeRD / Factur-X, Standards & Downloads): https://www.ferd-net.de/en/standards/zugferd/factur-x
– Profil-Erklärung (BASIC / BASIC WL, praxisnahes Glossar): https://manual.es2000.de/eserp/150/en-us/content/glossar/zugferd_profile.htm

Der entscheidende ZUGFeRD-Punkt wird oft unterschätzt: Das „schöne“ PDF ist nur die Sicht für Menschen – maßgeblich für die E-Rechnung ist der strukturierte XML-Teil. Das BMF stellt klar, dass umsatzsteuerliche Pflichtangaben im strukturierten Teil enthalten sein müssen. Heißt für Kleinunternehmer: Auch wenn du keine Umsatzsteuer ausweist, darf deine Rechnung nicht „irgendwie abgespeckt“ sein. Ein Klassiker ist: Im PDF steht korrekt „§ 19“, aber im XML fehlen Pflichtfelder oder es stehen noch 19 % drin, weil die Software ein Standard-Steuerprofil gezogen hat. Ergebnis: Der Empfänger kann nicht automatisiert buchen – und du hast unnötigen Aufwand.

Ein häufiger Irrtum lautet: „Als Kleinunternehmer muss ich keinen Steuersatz angeben, also kann ich Umsatzsteuer komplett ignorieren.“ Richtig ist: Du stellst ohne Umsatzsteuerausweis in Rechnung, aber der Grund muss erkennbar sein – der Kleinunternehmer-Hinweis gehört sauber auf die Rechnung. Seit 01.01.2025 werden die Anforderungen für Kleinunternehmer-Rechnungen zudem praktisch über die Sonderregel § 34a UStDV greifbarer, weshalb sich ein eigenes Template lohnt (statt eine „normale USt-Rechnung“ nur auf 0 zu setzen). Für deine Vorlagen bedeutet das: Im PDF keine USt-Beträge und keine Prozent-Steuersätze anzeigen, aber den §-19-Hinweis klar platzieren (z. B. im Fußbereich oder unter der Summenzeile).

Damit es in ZUGFeRD wirklich „wasserdicht“ ist, musst du den Hinweis zweigleisig denken: sichtbar im PDF und konsistent im XML. Im PDF haben sich kurze, eindeutige Formulierungen bewährt, z.B.:
– „Gemäß § 19 UStG wird keine Umsatzsteuer berechnet.“
– „Rechnungsstellung ohne Ausweis der Umsatzsteuer gemäß § 19 UStG.“
Optional (gerade bei B2B hilfreich, um Rückfragen zu vermeiden): „Ein Vorsteuerabzug ist aus dieser Rechnung nicht möglich.“
Im XML wiederum darfst du die Umsatzsteuerlogik nicht „leer lassen“ oder widersprüchlich befüllen: Typische Implementierungen arbeiten mit 0-Werten (Steuerbetrag/Steuersatz) plus Befreiungs-/Begründungstext (Exemption Reason). Entscheidend ist weniger die Wortwahl, sondern dass PDF-Aussage und XML-Daten dasselbe sagen – und dein Export eine EN-16931-Validierung besteht.

Der wichtigste Anwendungsunterschied ist also das Einsatzszenario: B2G (Rechnung an Behörden/öffentliche Auftraggeber) ist der Bereich, in dem XRechnung in der Praxis verlangt wird – inklusive Pflichtangaben wie Leitweg-ID/Buyer Reference oder Bestellbezug, sonst wird die Rechnung schnell abgewiesen. Im B2B-Alltag (Agenturen, KMU, andere Selbständige) liessen sich XRechnungen theoretisch auch verwenden, aber ZUGFeRD ist hier eher die stressfreiere Lösung, weil sich Rechnungen intern leichter prüfen, weiterleiten und „auf Sicht“ freigeben lassen – und trotzdem bereits die strukturierten Daten für die Buchhaltung/ERP enthalten. Wichtig: Beide Formate können grundsätzlich EN 16931-konform sein, entscheidend ist also weniger „legal oder nicht“, sondern was Ihr Kunde akzeptiert und technisch verarbeitet.

Rechtlich hat sich der Druck seit 2025 klar erhöht (Stand 16.01.2026): Unternehmen müssen seit 01.01.2025 grundsätzlich E-Rechnungen empfangen können, während es fürs Ausstellen im B2B-Bereich Übergangsregeln gibt. Praktisch heißt das für Freiberufler: Sie sollten spätestens jetzt in der Lage sein, strukturierte E-Rechnungen zu erzeugen – auch wenn Sie in der Übergangszeit ggf. noch mit klassischen PDFs arbeiten dürfen (oft aber nur mit Zustimmung des Empfängers). Spätestens wenn Kunden aktiv E-Rechnungen anfordern oder ihre Buchhaltung auf automatisierte Prozesse umstellt, wird ein „nur-PDF“-Workflow auf Dauer schwierig.

Die klassische Gutschrift (Typ 381) ist die richtige Wahl, wenn Sie dem Empfänger einen Betrag gutschreiben möchten (z.B. Rückerstattung, Bonus, Preisnachlass nachträglich, Kulanz), ohne zwingend eine bestehende Rechnung „zu stornieren“. Wichtig dabei: Die Gutschriftwirkung entsteht ausschließlich über den Dokumenttyp 381 – nicht dadurch, dass Sie Beträge negativ ausweisen. In der typischen ZUGFeRD/EN-16931-Umsetzung werden Positionswerte (Netto/Steuer/Brutto) ganz normal positiv befüllt, so wie bei einer normalen Rechnung. Das ist ein häufiger Stolperstein, weil manche Anwender intuitiv alles „ins Minus drehen“ – was dann je nach Empfängerprozess zu Rückfragen oder Ablehnungen führen kann.

Eine Negativrechnung (Typ 380) wird oft dann genutzt, wenn Sie technisch eine „normale Rechnung“ senden wollen, deren Gesamtbetrag negativ ist – zum Beispiel bei Schlussrechnungen nach Vorauszahlungen/Abschlägen oder in Verrechnungslogiken. In diesem Kontext ist also eine Negativrechnung eine ganz normale Rechnung, aber eben mit einem negativen Endergebnis. Die gängige Modellierung ist hier: Netto-Beträge bleiben positiv, aber die Menge wird negativ angegeben, sodass sich der negative Gesamtbetrag rechnerisch ergibt. Das kann funktionieren, ist aber in der Praxis sensibler, weil nicht jedes Portal oder jeder Workflow negative Endbeträge in einer „normalen Rechnung“ gleich gut akzeptiert. Wenn Sie häufig an öffentliche Auftraggeber oder über streng validierende Kanäle schicken, ist diese Variante besonders sorgfältig zu testen.

Wenn Sie hingegen eine konkrete, bereits gestellte Rechnung stornieren oder korrigieren müssen, ist meist die Rechnungskorrektur (Typ 384) der sauberste Weg. Auch hier werden die Beträge in den Positionsfeldern typischerweise positiv geführt; die Korrekturwirkung wird häufig über negative Mengen (oder über die Differenzlogik, je nach Prozess) abgebildet. Der entscheidende Punkt bei 384 ist aber weniger „Vorzeichen-Tricks“, sondern die eindeutige Referenz auf das Original: Die zu korrigierende Rechnung muss im Dokument korrekt referenziert werden (Preceding Invoice Reference / BG-3), damit Empfänger-Systeme die Korrektur automatisiert zuordnen können und nicht „zwei unabhängige Dokumente“ sehen.

Als Merkhilfe für Ihren Arbeitsalltag: 381 verwenden, wenn Sie eine Gutschrift als solche ausstellen (Gutschriftwirkung über den Typcode, nicht über Minus-Beträge). 384 verwenden, wenn Sie eine bestimmte Rechnung stornieren/korrigieren (inkl. Referenz auf das Original). 380 negativ nur dann nutzen, wenn Ihr Prozess bewusst mit negativen Rechnungen arbeitet und Sie sicher sind, dass der Empfängerkanal das akzeptiert. Und noch ein Sprach-Fallstrick: Im deutschen Steuerkontext bedeutet „Gutschrift“ manchmal das Gutschriftsverfahren/Selbstfakturierung – das ist technisch ein eigener Typcode (häufig 389) und etwas anderes als eine „kaufmännische Gutschrift“ im Sinne von 381.

Weiterführende Links / Quellen

• ZUGFeRD-Spezifikation 2.4: „0_FACTUR-X 1.08 2025 12 04 DE.pdf“, 7.1.6 Umgang mit Gutschrift, S. 38f
• ZUGFeRD/Factur-X Spezifikation (GEFEG), Abschnitt zu Invoice type code (BT‑3) und Typcodes (380/381/384):
  https://portal3.gefeg.com/projectdata/invoice/deliverables/installed/publishingproject/zugferd%202.0.1%20-%20facturx%201.03/en%2016931%20%E2%80%93%20facturx%201.03%20%E2%80%93%20zugferd%202.0.1%20-%20comfort.scm/html/de/0213.htm
• FAQ E‑Rechnung Bund: Credits und Rechnungskorrekturen in EN 16931/XRechnung (Praxis- und Interpretationshinweise):
  https://e-rechnung-bund.de/en/faq/how-should-i-indicate-credits-and-invoice-corrections/

Zur Erinnerung: Seit 01.01.2025 wird die E‑Rechnung im inländischen B2B-Umfeld zum neuen Standard (mit Übergangsregelungen), und eine „E‑Rechnung“ ist eben nicht einfach nur ein PDF, sondern ein strukturiertes elektronisches Format (z. B. XRechnung/XML oder ZUGFeRD mit eingebettetem XML), das automatisiert verarbeitet werden kann. Für die Aufbewahrung bedeutet das: Mindestens der strukturierte Teil muss im Original erhalten bleiben. Wenn Sie nur ein hübsches PDF ablegen, aber das XML fehlt oder wird nachträglich verändert, wird es im Zweifel kritisch. Deshalb sollte Ihr Workflow so aufgebaut sein, dass Sie mit RechnungFertig die E-Rechnungen generieren, die Sie danach konsequent ins Archiv überführen.

Eine Archivierungslösung dafür kann ein USB-WORM-Stick (Write Once, Read Many) sein: Er ist darauf ausgelegt, Dateien einmalig zu speichern. Danach sind sie nicht lösch- oder überschreibbar. Das ist für GoBD-relevante Anforderungen wie „Unveränderbarkeit“ ein großer Pluspunkt – und für kleine Betriebe attraktiv, weil keine Cloud nötig ist und keine laufenden Kosten entstehen. Der verlinkte Stick (16 GB) eignet sich für die Archivierung von E-Rechnungen (XRechnung/ZUGFeRD/Factur-X) und funktioniert unter Windows/Linux (aktuell leider nicht unter MacOS). Entscheidend: WORM ist ein starkes technisches Element – ersetzt aber nicht die organisatorischen Pflichten. In der Praxis funktioniert das Setup am besten mit einem festen Mini-Prozess: (1) Rechnung in RechnungFertig erstellen, (2) als E-Rechnung (XRechnung XML oder ZUGFeRD-PDF) speichern/exportieren, (3) vor dem Archivieren kurz validieren, ob die E-Rechnung technisch korrekt ist (damit Sie nicht fehlerhafte Dateien unveränderbar „einbetonieren“), und (4) dann ab auf den WORM-Stick – mit einem klaren Ablageschema. So erreichen Sie „Wiederauffindbarkeit“ auch ohne teures DMS, weil Sie über Ordnerstruktur und Dateinamen schnell suchen können.

Was Sie trotzdem einplanen müssen: GoBD-Konformität ist nicht nur Technik, sondern auch Nachvollziehbarkeit. Sie brauchen eine kurze Verfahrensdokumentation (für Kleinstbetriebe reichen oft wenige Seiten), in der steht: Wer erstellt Rechnungen? Welche Formate sind das „Original“? Wie werden Dateien benannt/abgelegt? Wie stellen Sie Vollständigkeit sicher (Checkliste „Rechnung erstellt → exportiert → validiert → archiviert“)? Und ganz wichtig: Ein WORM-Stick ist kein Backup. Wenn er verloren geht oder defekt ist, ist Ihr Archiv weg. Die pragmatische Lösung ist eine zweite, getrennt verwahrte Archivkopie nach festem Rhythmus (z. B. monatlich) – mit dem Ziel, dass auch diese Kopie die unveränderten Originale enthält und Sie im Notfall ausweichen können.

—

Weiterführende Links / Quellen

• BMF FAQ zur E‑Rechnung (Definition, Aufbewahrung, Übergang): https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html
• USB‑WORM‑Stick (Produktseite): https://erechnungs-validator.de/produkt/e-rechnung-archiv-usb-worm-stick-16gb/
• Hinweis-/Praxisartikel zur revisionssicheren Archivierung von E‑Rechnungen (Anbieter): https://erechnungs-validator.de/e-rechnungen-xrechnung-zugferdarchivieren-rechtssicher-revisionssicher-gesetzeskonform/
• Hintergrund zu XRechnung/ZUGFeRD in der Praxis (Einordnung strukturierter Daten): https://www.dr-weiss.com/eingangsrechnungsbearbeitung/tipps-zur-einfuehrung-xrechnung-und-zugferd-verarbeitung.html

Beim Versenden ist 2026 oft noch ein Übergangsjahr: Viele dürfen im B2B-Umfeld je nach Konstellation weiterhin „sonstige Rechnungen“ (PDF/Papier) nutzen – teils an Bedingungen geknüpft, etwa an die Zustimmung des Empfängers. Aber genau hier lauert der Praxis-Fallstrick: Große Kunden, Konzerne und öffentliche Auftraggeber stellen ihre Prozesse um und akzeptieren zunehmend nur noch strukturierte Rechnungen oder verarbeiten sie bevorzugt. Heißt für dich: Auch wenn du rechtlich vielleicht noch „dürftest“, kann es 2026 schon geschäftlich unklug sein, bei reinen PDF-Rechnungen zu bleiben – weil du sonst im schlimmsten Moment (wenn ein wichtiger Kunde umstellt) hektisch nachrüsten musst.

Technisch sind 2026 vor allem drei Begriffe wichtig: XRechnung, ZUGFeRD 2.x (z. B. 2.2) und „hybride PDFs“. XRechnung ist ein reines XML-Format (basierend auf EN 16931) und besonders im B2G-Bereich Standard, schwappt aber in B2B immer stärker rüber; deine Software sollte mindestens die gängigen aktuellen XRechnung-Versionen sauber unterstützen. ZUGFeRD ist für viele Kleine der pragmatische Einstieg: PDF/A-3 + eingebettete XML-Daten – Menschen können das PDF lesen, Systeme verarbeiten die XML. Wichtig ist dabei: Nicht jedes ZUGFeRD-Profil ist „voll EN-16931“; in der Praxis gelten bestimmte Profile (z. B. MINIMUM/BASIC-WL) als nicht ausreichend für eine „vollwertige“ E-Rechnung. Und: Bei hybriden Formaten zählt steuerlich und technisch zunehmend der strukturierte Teil – das PDF ist eher Anzeige, die XML ist die Wahrheit. Abweichungen zwischen PDF und XML können unnötige Risiken und Rückfragen auslösen.

Was solltest du jetzt (2026) konkret tun – und was kann warten? Jetzt solltest du (1) einen festen Eingangskanal definieren (z. B. rechnung@…), (2) sicherstellen, dass du XRechnung/ZUGFeRD anzeigen und idealerweise validieren kannst (Viewer/Validator oder direkt im Buchhaltungstool), und (3) die Archivierung GoBD-tauglich aufsetzen – inklusive der strukturierten Datei (XML), nicht nur „PDF abheften“. Planen solltest du 2026 außerdem die Umstellung deiner Ausgangsrechnungen auf mindestens ein E-Rechnungsformat (oft ZUGFeRD als Standard + XRechnung für Kunden/Portale, die es verlangen) und deine Stammdaten disziplinieren (Adresse, USt-ID, Leistungsdatum, Steuersätze etc.), weil Validatoren Fehler gnadenlos sichtbar machen. Im Blick behalten solltest Du – je nach Geschäftsmodell – das große EU-Thema ViDA: Die EU-weiten Digital-Reporting-Pflichten für grenzüberschreitende B2B-Umsätze kommen erst später (ab 2030).

Weiterführende Quellen

• BMF – FAQ zur E-Rechnung (Deutschland, Definition/Empfangspflicht/Kleinunternehmer): https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html
• Haufe – Überblick E-Rechnungspflicht und Übergangsregelungen: https://www.haufe.de/steuern/gesetzgebung-politik/elektronische-rechnung-wird-pflicht-erechnung-im-ueberblick_168_605558.html
• EU-Kommission (TAXUD) – ViDA-Paket, Zeitplan/DRR: https://taxation-customs.ec.europa.eu/news/adoption-vat-digital-age-package-2025-03-11_en
• IHK Köln – Hinweise zu BMF-Schreiben/E-Rechnung, Profile/Abweichungen Hybridformate: https://www.ihk.de/koeln/hauptnavigation/recht-steuern/steuern/bmf-schreiben-zur-e-rechnung-vom-15-10-2025-6774012
• IHK (Entwurf/Material zu BMF-Schreiben, Validierung/Umsetzungshinweise): https://www.ihk.de/meo/recht-und-steuern/steuerrecht/downloads/beitraege/entwurf-fuer-ein-2-bmf-schreiben-zur-e-rechnungspflicht-6612416