ZUGFeRD-Leitfaden: Was ist ZUGFeRD – und wann lohnt es sich?

ZUGFeRD ist ein in Deutschland verbreitetes Format für elektronische Rechnungen, bei dem strukturierte Rechnungsdaten in eine PDF-Datei eingebettet werden. Dadurch kann eine Rechnung menschenlesbar (PDF) und maschinenlesbar (strukturierte Daten) zugleich sein.

Dieser Leitfaden geht über die Grundlagen hinaus: Er erklärt, wie ZUGFeRD technisch funktioniert, wann es sinnvoller ist als XRechnung, was Empfänger typischerweise validieren – und welche Einstellungen du vor dem Produktivstart prüfen solltest.

Hinweis: Diese Seite dient der Orientierung und ist keine Rechts- oder Steuerberatung. Anforderungen können je nach Empfänger (z. B. öffentlicher Auftraggeber) und Prozess variieren.

1) ZUGFeRD in einem Satz

ZUGFeRD verbindet eine PDF-Rechnung mit eingebetteten strukturierten Rechnungsdaten, sodass Empfänger die Rechnung automatisiert verarbeiten können – ohne komplett auf eine reine XML‑Rechnung wechseln zu müssen.

2) Kernaussagen (wenn du nur einen Abschnitt liest)

  • ZUGFeRD ist ein hybrides Rechnungsformat: PDF für Menschen, strukturierte Daten für Systeme.
  • Es ist für B2B, B2G und B2C geeignet – in der Praxis entscheidet aber meist die Empfängeranforderung.
  • Die meisten Ablehnungen entstehen durch Datenqualität (Pflichtfelder, Steuercodes, Rundung), nicht durch „ein PDF-Problem“.
  • Wenn ein Portal ausdrücklich XRechnung fordert, solltest du einen XML‑zentrierten Prozess einplanen.

3) Wann ist ZUGFeRD sinnvoll?

Typische Situationen, in denen ZUGFeRD hilfreich ist:

  • B2B‑Rechnungen an Unternehmen, die automatisiert buchen/importieren möchten
  • Prozesse, die weiterhin auf PDF‑Workflows setzen, aber strukturierte Daten zusätzlich nutzen wollen
  • wenn du weniger Medienbrüche willst: Versand als PDF, Verarbeitung als strukturierte Daten

Wenn dein Empfänger explizit eine XRechnung verlangt (z. B. häufig im öffentlichen Bereich), ist ZUGFeRD nicht immer ausreichend – das hängt vom konkreten Szenario ab.

4) ZUGFeRD vs. XRechnung (grob und praxisnah)

Beide Formate zielen auf elektronische Rechnungsprozesse ab, werden aber in der Praxis oft unterschiedlich eingesetzt:

  • ZUGFeRD: häufig „PDF‑zentrierter“ Workflow mit eingebetteten Daten
  • XRechnung: häufig „XML‑zentrierter“ Workflow, besonders relevant für öffentliche Auftraggeber

Für die Auswahl zählt weniger die Theorie als die Frage:

  • Was fordert der Empfänger?
  • Welche Systeme verarbeitet der Empfänger?
  • Willst du PDF als primäres Dokument behalten?

Wenn du XRechnung benötigst, lies dazu auch: /xrechnung

5) Typischer Workflow (einfach)

  1. Rechnungsdaten erfassen (Kunde, Positionen, Steuersätze, Zahlungsbedingungen)
  2. Rechnung erstellen
  3. Optional: ZUGFeRD‑Variante erzeugen (PDF + eingebettete strukturierte Daten)
  4. Versand an den Empfänger
  5. Archivierung (auffindbar, vollständig, unverändert)

6) Woher kommt ZUGFeRD – und warum ist das wichtig?

ZUGFeRD wird vom Forum elektronische Rechnung Deutschland (FeRD) bereitgestellt und orientiert sich u. a. an:

  • EU‑Vorgaben zur elektronischen Rechnungsstellung im öffentlichen Auftragswesen (Richtlinie 2014/55/EU)
  • der europäischen Rechnungsnorm EN 16931

Warum das für dich zählt: Viele Prüfregeln und Pflichtfelder leiten sich daraus ab. Wenn eine Rechnung abgelehnt wird, ist es oft nicht „die PDF“, sondern eine Regel in den strukturierten Daten (fehlender Referenzwert, inkonsistente Summen, falsche Steuercodierung).

Offizielle Informationen/Downloads (FeRD):

7) Wie funktioniert ZUGFeRD technisch? (Hybrid: PDF + strukturierte Daten)

Vereinfacht besteht eine ZUGFeRD‑Rechnung aus:

  1. einem PDF/A‑3 (archivierbares PDF), und
  2. einer eingebetteten strukturierten Rechnung auf Basis der UN/CEFACT Cross‑Industry‑Invoice (CII).

Der Empfänger kann das PDF normal lesen – und sein System kann die eingebetteten Daten automatisiert auswerten.

Praktische Konsequenzen:

  • Die strukturierten Daten müssen exakt zum PDF passen (Summen, Steuerbeträge, Daten).
  • Wenn du das PDF nachträglich bearbeitest (stempeln, zusammenführen, neu rendern), kann die Konsistenz brechen.
  • Behandle PDF + Daten nach Veröffentlichung als ein „gesperrtes“ Geschäftsdokument.

8) ZUGFeRD‑Profile (BASIC / EN 16931 / EXTENDED) – was bedeutet das?

In der Praxis begegnen dir verschiedene Profile. Sie bestimmen grob, wie umfangreich die strukturierten Rechnungsdaten sind.

  • BASIC: eher reduzierte Datenmenge (für einfache Rechnungen)
  • EN 16931: orientiert sich am europäischen Kernrechnungsmodell
  • EXTENDED: zusätzliche Felder/Strukturen für spezielle Anforderungen

Wichtig ist weniger der Name, sondern die Empfängerfrage:

  • Kann der Empfänger ZUGFeRD grundsätzlich verarbeiten?
  • Erwartet er ein bestimmtes Profil?
  • Gibt es Vorgaben im Portal/EDI‑Prozess?

Hinweis: Profile und Detailregeln können sich je nach Version verändern. Wenn ein Portal ein Profil vorgibt, gilt diese Vorgabe zuerst.

9) Was prüft ein Empfänger typischerweise?

Empfänger‑Systeme prüfen häufig zwei Ebenen:

  1. Technische Ebene: Ist der Aufbau korrekt und konsistent?
  2. Fachliche Ebene: Passen Summen, Steuern und Pflichtfelder zusammen?

Typische Prüfpunkte:

  • vollständige Absender-/Empfängerdaten
  • konsistente Beträge (Netto/Steuer/Brutto)
  • korrekte Steuercodes (z. B. Standard, ermäßigt, Reverse‑Charge)
  • plausible Leistungsbeschreibung
  • erforderliche Referenzen (z. B. Leitweg‑ID / Buyer‑Reference in B2G‑Szenarien)

10) Validierung & Tests (praktischer Ansatz)

Wenn du ZUGFeRD neu einführst, lohnt ein kleiner Test‑Workflow:

  1. Testrechnung an dich selbst (oder Testempfänger) senden
  2. Im Empfänger‑System prüfen, ob die strukturierten Daten erkannt werden
  3. Bei Problemen: Felder systematisch durchgehen (Stammdaten, Steuerlogik, Rundung)

Viele Workflows nutzen zusätzlich Validatoren/Prüfroutinen (z. B. im Portal oder in der Buchhaltungssoftware des Empfängers). Welcher Validator „der richtige“ ist, hängt vom Szenario ab.

11) Vor dem Produktivstart: Setup‑Checkliste

Wenn du willst, dass ZUGFeRD stabil läuft, solltest du diese Grundlagen einmal sauber aufsetzen.

Stammdaten (Absender)

  • Firmenname und Adresse (konsistente Schreibweise)
  • USt‑IdNr. (falls relevant) und steuerliche Angaben
  • Bankdaten (IBAN/BIC) und Zahlungsbedingungen
  • sauberes Nummernschema für Rechnungen

Stammdaten (Empfänger/Kunde)

  • korrekter Firmenname und Adresse
  • USt‑IdNr. (falls relevant)
  • ggf. Empfänger‑Routing‑Infos (Portal‑ID, Buyer‑Reference, Kostenstelle)

Positionen & Steuern

  • klare Leistungs-/Produktbeschreibung
  • korrekte Menge/Einheit
  • korrekte Steuerkategorie / MwSt‑Satz
  • Rabatte/Zuschläge konsistent abbilden

Summen & Rundung

  • eine Rundungslogik festlegen (Positions‑ vs. Gesamt‑Rundung) und konsequent nutzen
  • mit „schwierigen“ Rechnungen testen (viele Kleinpositionen, gemischte Steuern, Rabatte)

12) Häufige Fehler (und wie du sie vermeidest)

Fehler 1: Pflichtangaben fehlen oder sind inkonsistent

Achte auf vollständige Rechnungsdaten und konsistente Beträge/Steuern. Ein PDF kann korrekt aussehen, während die strukturierten Daten Pflichtfelder nicht erfüllen.

Fehler 2: Abweichende Rundungen zwischen PDF und strukturierten Daten

Wenn Summen oder Rundungen nicht exakt passen, kann die automatische Verarbeitung scheitern.

Beispiel (vereinfachtes Prinzip):

  • Positionen werden einzeln gerundet, aber die Gesamtsumme wird anders gerundet
  • oder Netto/Steuer/Brutto werden aus unterschiedlichen Rundungsstufen berechnet

Praktischer Tipp: Prüfe die Rundungslogik mit 2–3 typischen Rechnungen (z. B. mit vielen kleinen Positionen).

Fehler 3: Falsche Steuerkategorie (insbesondere Reverse‑Charge)

Reverse‑Charge und andere Spezialfälle benötigen bestimmte Codes/Felder. Ein Hinweis im PDF allein reicht für die strukturierte Validierung oft nicht.

Praktischer Tipp: Erstelle je Steuer‑Szenario eine Testrechnung (Standard, ermäßigt, Reverse‑Charge) und validiere sie im Empfängerprozess.

Fehler 4: Empfänger kann ZUGFeRD nicht verarbeiten

Klär vorher, ob der Empfänger ZUGFeRD unterstützt – sonst bleibt es ein „schönes PDF“ ohne Automatisierungsvorteil.

Fehler 5: Archivierung ohne klare Regeln

Ein sauberer Ablauf (Benennung, Ablage, Backup) hilft auch im GoBD‑Kontext.

GoBD‑Grundlagen findest du hier: /gobd

13) Troubleshooting: Was tun bei Ablehnung?

Wenn eine Rechnung abgelehnt wird, geh pragmatisch in dieser Reihenfolge vor:

  1. Empfängeranforderung klären: ZUGFeRD erlaubt? Welches Profil? Portal‑Regeln?
  2. Pflicht‑Referenzen prüfen (häufig in B2G): Buyer‑Reference / Leitweg‑ID.
  3. Summen abgleichen: stimmen Netto/Steuer/Brutto exakt?
  4. Steuern prüfen: korrekte Steuerkategorie und Satz? Reverse‑Charge korrekt modelliert?
  5. Daten prüfen: Rechnungsdatum, Leistungsdatum, Fälligkeit.
  6. Stammdaten prüfen: Adressen, USt‑IdNr., Bankdaten.

Wenn du den Fehler mit einer einzigen Testrechnung reproduzieren kannst, lassen sich die meisten Probleme schnell beheben.

14) Versionen (warum „geht bei Kunde A“ bei Kunde B scheitern kann)

Empfänger und Portale validieren nicht immer mit derselben Version und denselben Regelsets.

FeRD veröffentlicht aktuelle Downloads und stellt ältere Versionen im Versionsarchiv bereit.

Stand Dezember 2025 nennt FeRD ZUGFeRD 2.4 als aktuelles Infopaket. Wenn dein Prozess noch eine ältere Version (z. B. 2.1.x) referenziert, kläre die Kompatibilität mit dem Empfänger.

Offizielle Links:

15) Kurz‑Checkliste für den Einstieg

  • Empfängeranforderungen geklärt (ZUGFeRD vs. XRechnung)
  • Stammdaten korrekt (Adresse, USt‑IdNr., Zahlungsbedingungen)
  • Positionen & Steuern stimmen (inkl. Rundung)
  • Pflichtfelder sind vollständig (insb. Adresse, Leistungsbeschreibung, Datum)
  • Testversand an dich selbst / Testempfänger
  • Archivierung definiert (Auffindbarkeit, Backup)

16) Mini‑FAQ

Muss ich immer ZUGFeRD nutzen?

Nein. Entscheidend ist, was dein Empfänger verlangt und welche Prozesse du abbilden willst.

Was, wenn der Empfänger XRechnung fordert?

Dann ist ZUGFeRD nicht automatisch ausreichend. Siehe: /xrechnung

17) Nächste Schritte auf dieser Website

18) Ein pragmatischer Einstieg

Wenn du aktuell nur PDF‑Rechnungen verschickst, ist ein sinnvoller Weg oft:

  1. den PDF‑Workflow beibehalten,
  2. ZUGFeRD für Empfänger nutzen, die es verarbeiten,
  3. XRechnung nur dort einsetzen, wo es ausdrücklich gefordert ist.

So bleibt die Umstellung klein, während du dir einen robusten, testbaren Prozess aufbaust.