ZUGFeRD-Rechnung erstellen: So geht es richtig (und was schiefgeht)

Eine ZUGFeRD-Rechnung sieht aus wie eine PDF, ist aber deutlich mehr: eine PDF/A-3 mit einem normkonformen XML im Bauch, bei der beide Teile exakt übereinstimmen müssen. Genau deshalb scheitern die meisten Versuche, sie „mal schnell" zu erstellen. Dieser Artikel zeigt die drei Wege, die funktionieren, die fünf Stellen, an denen es typischerweise hakt, und wie Sie das Ergebnis prüfen, bevor es zum Kunden geht.

Was eine ZUGFeRD-Rechnung technisch braucht

Bevor es um Werkzeuge geht, die Anforderungen. Eine gültige ZUGFeRD-Rechnung ist:

1. eine PDF/A-3-Datei – nicht irgendeine PDF, sondern das Archivformat, das Anhänge erlaubt und Schriften einbettet
2. mit einem eingebetteten XML namens factur-x.xml, das der Spezifikation ZUGFeRD 2.x in einem normkonformen Profil (BASIC, EN 16931, EXTENDED, XRECHNUNG) entspricht
3. mit XMP-Metadaten in der PDF, die Profil und Version deklarieren
4. bei der PDF und XML dieselben Werte tragen – Rechnungsnummer, Beträge, Steuern, Parteien
5. deren XML alle Pflichtfelder der EN 16931 enthält, einschließlich derer, die auf Papierrechnungen fehlen (E-Mail-Adressen, Fälligkeit, Codes für Steuerkategorie und Mengeneinheit)

Word kann davon nichts. Ein PDF-Drucker kann Punkt 1 vielleicht, den Rest nicht. Was ZUGFeRD im Detail ist, steht im Leitfaden ZUGFeRD.

Weg 1: Rechnungsprogramm mit ZUGFeRD-Ausgabe

Der Weg für alle, die regelmäßig Rechnungen schreiben. Sie erfassen Kunde, Positionen und Beträge wie gewohnt; das Programm erzeugt PDF und XML aus denselben Daten, bettet ein und deklariert das Profil. Sie bekommen eine fertige Datei, die Sie verschicken können.

Worauf Sie beim Programm achten sollten:

• Version und Profil: ZUGFeRD 2.x, Profil EN 16931. Nicht MINIMUM, nicht BASIC WL, nicht Version 1.0.
• Pflichtfeldprüfung vor dem Erstellen: Fehlt die E-Mail-Adresse des Kunden, soll das Programm das sagen, bevor die Datei entsteht – nicht der Empfänger danach.
• Validierung: Prüft das Programm die Datei gegen Mustangproject oder einen gleichwertigen Validator?
• Konsistenz: PDF und XML aus einer Quelle.
• Kleinunternehmer und Reverse Charge korrekt als Steuerkategorie im XML, nicht als „0 %".

Wie Sie ein Programm in zehn Minuten auf diese Punkte testen, steht im Artikel E-Rechnung-Software.

Weg 2: Online-Generator

Für die eine Rechnung im Quartal: Formular ausfüllen, ZUGFeRD-Datei herunterladen. Kostenlos, ohne Registrierung. Was fehlt: Kundenstamm, Nummernkreis, Archiv, Storno. Jede Rechnung beginnt bei null, und die Rechnungsnummer vergeben Sie selbst – mit allen Risiken für Lücken und Doppelungen. Prüfen Sie außerdem, ob der Generator wirklich Profil EN 16931 erzeugt und nicht MINIMUM.

Weg 3: Bibliothek für eigene Software

Wer selbst entwickelt, nutzt eine Bibliothek: Mustangproject (Java, Open Source, zugleich Referenzvalidator), ZUGFeRD-csharp (.NET), factur-x (Python) oder horstoeko/zugferd (PHP). Sie erzeugen aus Ihren Daten XML und PDF/A-3 und betten ein. Der Aufwand liegt in der korrekten Befüllung aller Felder und Codes – die Bibliothek prüft nicht, ob Ihre Steuerkategorie stimmt.

PDF in ZUGFeRD umwandeln – geht das?

Die Suche „PDF in ZUGFeRD umwandeln" ist häufig, die Antwort ernüchternd: Eine bestehende PDF enthält die Rechnungsdaten nicht strukturiert. Ein Werkzeug kann sie per Texterkennung raten, aber nicht sicher lesen – und eine falsch erkannte Rechnungsnummer im XML macht die Rechnung ungültig. Was funktioniert: die Daten neu erfassen und daraus PDF und XML erzeugen. Das ist kein Umwandeln, das ist Neuerstellen. Mehr im Artikel PDF in E-Rechnung umwandeln.

Die fünf Stellen, an denen es scheitert

1. Keine PDF/A-3. Die PDF wurde mit einem normalen Drucker erzeugt und das XML angehängt. Der Validator meldet „not PDF/A-3" – keine ZUGFeRD-Rechnung.

2. Falsches Profil. Der Generator erzeugt MINIMUM, weil das am wenigsten Daten braucht. Der Empfänger bekommt eine Datei ohne Positionen – keine E-Rechnung nach UStG.

3. Abweichung zwischen PDF und XML. Die PDF zeigt 1.392,30 Euro, das XML 1.392,00. Die Rechnung ist ungültig; das XML gilt, der Kunde zahlt den falschen Betrag oder weist zurück.

4. Fehlende Pflichtfelder. Keine E-Mail-Adresse des Käufers (BT-49), kein Fälligkeitsdatum, keine Mengeneinheit. Schema-Fehler beim Empfänger.

5. Falsche Codes. Kleinunternehmer mit Steuerkategorie S und 0 % statt E, Mengeneinheit „Stück" als Text statt H87, Steuersatz als „19%" statt 19.00. Alles Validierungsfehler.

So prüfen Sie das Ergebnis

Bevor die erste ZUGFeRD-Rechnung an einen Kunden geht:

1. Datei im PDF-Reader öffnen. Zeigt das Anhang-Symbol factur-x.xml? Wenn nicht, ist nichts eingebettet.
2. XML im Viewer öffnen. Quba-Viewer oder ELSTER E-Rechnungs-Viewer: Wird die Rechnung ohne Fehlermeldung angezeigt? Stimmen die Beträge mit der PDF?
3. Validator laufen lassen. Mustangproject prüft PDF/A, Einbettung, Schema und Geschäftsregeln. Was rot ist, muss weg.
4. Testempfang. Schicken Sie die Datei an Ihren Steuerberater oder importieren Sie sie in eine Buchhaltungssoftware. Wird sie automatisch erkannt?

Wie Validierung genau funktioniert, steht im Artikel ZUGFeRD-Validator.

Kostenlos oder bezahlt?

Für die gelegentliche Rechnung reicht ein Generator. Für alles darüber zahlen Sie mit Zeit: manuelle Nummern, keine Vorlagen, kein Archiv, jede Rechnung von null. Ein Rechnungsprogramm mit ZUGFeRD ab 6 bis 10 Euro im Monat erledigt das mit einem Klick – und erzeugt meist gleich die XRechnung dazu. Was ein Rechnungsprogramm sonst können sollte, steht im Leitfaden Rechnungsprogramm.

Häufige Fragen

Stand: September 2026. Quellen: ZUGFeRD-Spezifikation 2.3 (FeRD), EN 16931, BMF-Schreiben vom 15. Oktober 2024.