Seit Januar 2025 müssen Unternehmen in Deutschland strukturierte elektronische Rechnungen empfangen und verarbeiten können. E-Rechnung ist einer der anerkannten Standards für diesen Austausch und kombiniert Lesbarkeit mit automatisierter Verarbeitung.
Dieser Standard prägt Rechnungsprozesse, beeinflusst Compliance-Anforderungen und wirkt sich auf ganze Systemlandschaften aus. Wer ihn richtig umsetzt, kann Medienbrüche reduzieren, Automatisierung vorantreiben und operative Risiken minimieren.
ZUGFeRD 2 ist ein hybrides E-Rechnungsformat, das eine menschenlesbare PDF-Rechnung mit maschinenlesbaren strukturierten Daten im XML-Format in einer einzigen Datei kombiniert. Das PDF verwendet den Archivierungsstandard PDF/A-3 als Container, während die XML dem CII-Format (Cross Industry Invoice) folgt. Beide Ebenen enthalten dieselben Rechnungsinformationen und sind vollständig synchronisiert.
Eine ZUGFeRD-Datei besteht aus zwei untrennbar verbundenen Elementen: dem visuellen Teil mit PDF-Rechnung inklusive Layout, Logo und Formatierung, die ein Standard-PDF-Reader anzeigt, sowie dem strukturierten Teil als CII-XML-Datei, die als Anhang im PDF/A-3-Container eingebettet ist und alle Rechnungsfelder in standardisierter, maschinenlesbarer Form enthält. Die XML ist nicht optional – eine echte ZUGFeRD-Rechnung existiert erst, wenn PDF und XML fachlich konsistent und technisch korrekt zusammenpassen.
Eine klassische PDF-Rechnung ist ein reines Dokument für menschliche Lesbarkeit ohne strukturierte Daten. Systeme müssen Texterkennungstechnologien (OCR) einsetzen oder Daten manuell erfassen – fehleranfällig und zeitaufwändig. ZUGFeRD ergänzt diese Lesbarkeit um Struktur: Die XML ermöglicht automatisches Auslesen von Rechnungsnummern, Beträgen, Steuersätzen und anderen Schlüsselinformationen sowie deren direkte Übernahme in Buchhaltungssysteme ohne Medienbruch.
Die aktuelle Version ist ZUGFeRD 2.3, veröffentlicht 2024 und vollständig an den europäischen EN16931-Standard abgestimmt. Alle Versionen ab ZUGFeRD 2.1 nutzen dieselbe CII-XML-Struktur und sind untereinander interoperabel.
Das zentrale Nutzversprechen ist die Automatisierung des Purchase-to-Pay-Prozesses (P2P). Mit strukturierten Rechnungsdaten können Systeme Rechnungen automatisch erkennen und klassifizieren, Daten direkt in ERP-Systeme übernehmen ohne manuelle Eingabe, Rechnungen positionsgenau gegen Bestellungen und Wareneingänge abgleichen, sowie Freigabeprozesse automatisieren oder stark vereinfachen und Fehlerquoten reduzieren und Durchlaufzeiten verkürzen.
Diese Automatisierung ist wirtschaftlich relevant: Sie reduziert manuellen Bearbeitungsaufwand pro Rechnung, beschleunigt Zahlungsprozesse und verringert Datenerfassungsfehler. Zur ROI-Bewertung sollten CFOs folgende Hebel quantifizieren: Rechnungsvolumen pro Monat, erwartete Quote des Straight-Through-Processing (automatische Verarbeitung ohne manuelle Intervention), Kosten pro manueller Rechnungsprüfung oder Fehlerfall, Projektkosten für Middleware-Integration oder ERP-Updates sowie laufende Betriebskosten für Validierung und Monitoring.
Das PDF/A-3-Format ist archivierbar und langfristig lesbar. Die eingebettete XML liefert strukturierte Daten für revisionssichere Aufbewahrung nach GoBD (Grundsätze zur ordnungsgemäßen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form). Elektronische Rechnungen müssen in Deutschland maschinell lesbar aufbewahrt werden.
Die Verfahrensdokumentation muss folgende Punkte adressieren: Welche Validierungsschritte (XSD-Struktur, Schematron-Geschäftsregeln) erfolgen und wer ist verantwortlich? Welche Logs und Artefakte (Validierungsberichte, Fehlerprotokolle, Archiv-Nachweise) werden aufbewahrt und wo? Wie wird die Originalität und Unveränderbarkeit der Rechnung nach Eingang gesichert (z. B. Hashwert, Zeitstempel, Integritätsprüfung)? Wie wird der Profiltyp und der Validierungsstatus audit-relevant verknüpft und nachweisbar gemacht? Welche Rollen (Systemadministrator, Rechnungsprüfer, Archiv-Manager, Auditor) sind für welche Schritte verantwortlich?
Das Format ist verbreitet in Deutschland, Österreich und der Schweiz. Im grenzüberschreitenden Austausch, besonders mit französischen Partnern, ist es hochrelevant, da Factur-X (der französische Name für denselben Standard) gleich häufig eingesetzt wird. Unternehmen mit internationalen Lieferketten profitieren von dieser technischen Gleichheit.
ZUGFeRD 2 definiert mehrere Profile, die festlegen, wie viele und welche Daten in der XML enthalten sind. Die Profilwahl ist zentral für die Umsetzung – sie beeinflusst Systemkompatibilität, Automatisierungstiefe und Prozessdesign.
Das einfachste Profil mit grundlegenden Identifikationsdaten wie Rechnungsnummer, Datum, Verkäufer, Käufer und Gesamtbetrag. Die PDF ist die primäre Informationsquelle, XML dient vor allem der Zuordnung und Archivierung. Geeignet für sehr einfache, dokumentarische Fälle mit geringen Integrationsanforderungen. In Deutschland stellt dieses Profil keine vollständige Rechnung im Sinne des Umsatzsteuergesetzes dar, da es keine Positionen und keine Steueraufschlüsselung enthält.
Ergänzt das Minimum-Profil um Zahlungsdetails, Steueraufschlüsselung und zusätzliche Parteiinformationen, enthält aber weiterhin keine einzelnen Rechnungspositionen. Geeignet für einfache Rechnungen, bei denen keine positionsgenaue automatisierte Verarbeitung erforderlich ist. Auch dieses Profil ist in Deutschland nicht vollständig nach UStG und wird wenig eingesetzt.
Das erste Profil mit Rechnungspositionen in strukturierter Form, wobei jede Position Beschreibung, Menge, Einzelpreis und Steuersatz enthält. Dies ist das empfohlene Profil für standardisierte E-Rechnungsstellung in der EU und erfüllt die europäische EN16931-Norm vollständig. Es ist die Basis für grenzüberschreitende, automatisierte Rechnungsverarbeitung, und die meisten modernen Peppol-kompatiblen Systeme erwarten diesen Detaillierungsgrad. Für die meisten Unternehmen ist dieses Profil die richtige Wahl.
Erweitert über EN16931 hinaus um zusätzliche Handelsparteien, Logistikinformationen, detaillierte Zahlungsanweisungen und weitere Felder. Sinnvoll bei komplexen Lieferketten-Szenarien und erweiterten Informationsbedarfen. Nicht jedes empfangende System unterstützt Extended-Felder vollständig – das kann zu Kompatibilitätsproblemen führen.
Eine deutsche CIUS (Core Invoice Usage Specification) auf Basis von EN16931, spezifisch für Rechnungen an deutsche öffentliche Auftraggeber. Sie enthält nationale Pflichtangaben wie die Leitweg-ID und strengere Validierungsregeln als ZUGFeRD. Während ZUGFeRD über alle Übertragungswege versandt werden kann, ist XRechnung stärker an strukturierte Übertragungswege und behördliche Anforderungen gebunden.
ZUGFeRD und Factur-X sind technisch identisch. Der Unterschied liegt nur in Name und Branding. Deutschland entwickelte ZUGFeRD, Frankreich entwickelte Factur-X parallel. Im Jahr 2020 einigten sich beide Organisationen auf eine gemeinsame Spezifikation. Seit ZUGFeRD 2.1 sind die Formate vollständig gleichwertig: dieselbe CII-XML-Struktur, derselbe PDF/A-3-Container, dieselben EN16931-konformen Profile. Jedes Tool, das ZUGFeRD lesen kann, kann auch Factur-X lesen und umgekehrt.
| Aspekt | ZUGFeRD 2 | XRechnung |
|---|---|---|
| Format | Hybrid (PDF + XML) | Nur XML |
| Lesbarkeit | Menschenlesbar (PDF) + maschinenlesbar (XML) | Rein maschinenlesbar |
| Übertragungswege | Alle Wege möglich (E-Mail, Upload, Datenaustausch) | Strukturierte Wege und Leitwegbetreiber vorgesehen |
| Einsatz | Privatwirtschaft, gemischte Landschaften | Deutsche Behörden, öffentliche Auftraggeber |
| Nationale Regeln | Europäisch harmonisiert | Deutschlandspezifische Pflichtfelder (z. B. Leitweg-ID) |
ZUGFeRD bleibt lesbar und erlaubt breite Versandwege – ideal für Übergangsphasen und gemischte Empfängerlandschaften. XRechnung ist stärker strukturiert und behördlich geprägt. Unternehmen, die an öffentliche Auftraggeber liefern, müssen XRechnung unterstützen; für private Partner ist ZUGFeRD oft die bessere Wahl. Die operative Konsequenz: P2P-Prozesse (inbound) sind meist primär ZUGFeRD-fokussiert; O2C-Prozesse (outbound zu Behörden) erfordern XRechnung-Versand, was separate Mappings, Validierungen und Partner-Kommunikation bedeutet.
ZUGFeRD verwendet das CII-XML-Format, eines von zwei anerkannten EN16931-Syntaxen. Die andere Syntax ist UBL (Universal Business Language). Das Peppol-Netzwerk (Pan-European Public Procurement On-Line) akzeptiert ausschließlich UBL. Wenn eine ZUGFeRD-Rechnung über Peppol versendet oder empfangen werden soll, muss die CII-XML in UBL konvertiert werden. Diese Konvertierung ist auf EN16931-Basis verlustfrei, da beide Formate dasselbe semantische Datenmodell unterstützen. Rechnungen mit dem Profil EN16931 (Comfort) oder höher enthalten genug Daten für eine vollständige Konvertierung.
Eine erfolgreiche ZUGFeRD-Implementierung hängt von der Integration in bestehende Systemlandschaften ab. Die Schnittstellenverantwortung muss klar geregelt sein.
ZUGFeRD-Rechnungen kommen per E-Mail, Upload oder über Netzwerkdienste an. Ein Konvertierungstool oder eine Middleware extrahiert die XML aus dem PDF/A-3-Container, validiert die Struktur und Geschäftsregeln und routet die Rechnung zum passenden System. Die strukturierten Rechnungsdaten werden aus der XML ausgelesen und in das Buchhaltungssystem übernommen, wo Abgleiche mit Bestellungen und Freigaben erfolgen. Das PDF wird im Dokumentenmanagementsystem abgelegt und mit Metadaten versehen. Die ZUGFeRD-Originaldatei in ihrer vollständigen Form wird revisionssicher archiviert.
Medienbrüche entstehen häufig an unklaren Übergabepunkten zwischen Systemen. Beispielsweise wenn die Middleware die XML extrahiert und vergisst, Validierungsergebnisse zu dokumentieren, oder wenn das Dokumentenmanagementsystem nur das PDF speichert und die XML verloren geht. Eine klare Schnittstellendokumentation, eindeutige Verantwortlichkeiten und Audit-Artefakte sind zentral für einen zuverlässigen Betrieb.
ZUGFeRD-Rechnungen müssen auf zwei Ebenen validiert werden. Strukturelle Validierung (XSD) prüft gegen das XML-Schema und sichert syntaktische Korrektheit, zulässige Codes und Kardinalitäten. Geschäftsregeln-Validierung (Schematron) prüft fachliche Anforderungen wie Gesamtbetragsübereinstimmung, Steuersatzkonsistenz und Profilkonformität. Beide Prüfungen sind erforderlich für eine belastbare Rechnungsvalidierung.
Ein Fehlerbehandlungsprozess ist zentral: Was geschieht, wenn eine Rechnung nicht validiert oder der ERP-Abgleich fehlschlägt? Typische Optionen sind automatische Ablehnung mit Fehlerdetails, manuelle Prüfung durch den Rechnungsprüfer oder automatische Korrekturversuche. Monitoring-Dashboards sollten eingehende, verarbeitete und zurückgewiesene Rechnungen im Blick behalten. KPIs zur kontinuierlichen Überwachung sollten die Quote validierter vs. zurückgewiesener Rechnungen pro Partner, häufigste Validierungsfehler, Durchlaufzeiten von Eingang bis Buchung, Fehlerquoten bei Abgleich mit Bestellungen und Automatisierungsquote abdecken.
Ein häufiger Fehler ist die Profilwahl ohne Abstimmung mit Empfängern. Wird das EN16931-Profil versendet, aber der Empfänger erwartet Extended, oder umgekehrt, kann es zu Verarbeitungsfehlern kommen. Schlimmer noch: Wird ein zu einfaches Profil gewählt (Minimum, Basic), fehlen wichtige Positionsdaten und der Automatisierungsvorteil fällt weg.
Oft stimmen Daten in der visuellen PDF-Rechnung nicht exakt mit den Werten in der XML überein. Beispiele sind ein Steuerbetrag im PDF anders als in der XML, Rechnungspositionen im PDF, aber nicht in der XML, oder Steuerbeträge, die sich nicht auf angegebene Steuersätze beziehen. Dies führt zu Validierungsfehlern und macht eine zuverlässige automatisierte Verarbeitung unmöglich. Das Risiko verschärft sich bei Export aus ERP-Systemen mit unterschiedlichen Rundungslogiken.
Viele Unternehmen testen ZUGFeRD-Implementierungen intern mit synthetischen Testdaten. Echte Partner-Rechnungen offenbaren dann plötzlich Probleme wie unerwartete Feldwerte, andere Steuerlogiken oder Sonderzeichen in Namen. Produktive Tests mit wenigen echten Lieferanten sollten früh beginnen – idealerweise parallel zur internen Vorbereitung.
Beim Versand von ZUGFeRD-Rechnungen an Partner ist oft unklar, welches Profil versendet wird, oder Partner erhalten unterschiedliche Profile ohne vorherige Abstimmung. Das führt zu Ablehnungen und Nachfragen. Eine dokumentierte Entscheidung und Partnerkommunikationsstrategie sind zentral für Akzeptanz und Betriebsstabilität.
Das Originalformat (PDF + eingebettete XML) wird nicht archiviert. Stattdessen wird nur das PDF gespeichert oder die XML separat. Im Audit kann später nicht mehr nachgewiesen werden, welches Profil verwendet wurde oder ob Daten validiert waren. Ein robustes Archivierungskonzept muss von Anfang an geplant sein: Wo werden Originaldateien abgelegt? Wie lange? Wer hat Zugriff? Wie wird die Unveränderbarkeit gesichert? Wie werden Metadaten mit der Datei verknüpft?
Nach dem initialen Rollout schleichen sich Abweichungen ein: Feldmappings passen plötzlich nicht mehr, weil sich Kundendatenstrukturen im ERP geändert haben, oder die Validierungs-Middleware wird nicht aktualisiert und schlägt bei neuen ZUGFeRD-Versionen fehl. Regelmäßige Überprüfung und Governance sind erforderlich, um Wartung, Änderungen und Versionsupdates einzusteuern.
| Frage / Kriterium | Antwort / Bewertung | Empfehlung |
|---|---|---|
| Wer sind Ihre Empfänger? | Nur deutsche öffentliche Auftraggeber | XRechnung (Pflicht) |
| Gemischte Landschaft (Privatwirtschaft + Behörden) | ZUGFeRD EN16931 als Basis, XRechnung für Behörden | |
| Hauptsächlich private Unternehmen | ZUGFeRD EN16931 | |
| Wie groß ist das Rechnungsvolumen? | Gering (<100/Monat) | Einfacheres Profil ausreichend, aber EN16931 empfohlen |
| Mittel bis hoch (>100/Monat) | EN16931 für Automatisierung erforderlich | |
| Systemintegration notwendig? | Keine; manuelle Verarbeitung | Minimum/Basic ausreichend, aber nicht umsatzsteuerkonform |
| ERP-Integration, automatisierte Freigaben | EN16931 oder Extended | |
| Netzwerk-/Peppol-Anbindung | EN16931 als Minimum (Extended nur getestet) | |
| Welche Daten brauchen Sie? | Nur Gesamtbetrag und Grunddaten | Minimum/Basic (nicht empfohlen für Deutschland) |
| Positions- und Steuerdaten | EN16931 (Standard) | |
| Zusätzliche Logistik-, Lieferanten-, Zahlungsdaten | Extended (Partner-Kompatibilität prüfen) |
Die goldene Regel lautet: Starten Sie mit EN16931 (Comfort), wenn Sie automatisierte Verarbeitung planen. Dieses Profil ist europäisch harmonisiert, breit unterstützt und bietet Skalierungspotenzial. Extended kommt nur infrage, wenn tatsächlich komplexere Daten zu verarbeiten sind und der Empfänger das Profil technisch unterstützt.
Hochwertige Rechnungsdaten und Implementierungen lassen sich an mehreren Merkmalen erkennen.
Ein funktionierendes Qualitätsmanagementsystem sollte kontinuierlich überwachen: Quote validierter vs. zurückgewiesener Rechnungen pro Partner, häufigste Validierungsfehler und deren Ursachen, Durchlaufzeiten von Eingang bis Buchung, Fehlerquoten bei Abgleich mit Bestellungen, Automatisierungsquote und Archiv-Konsistenz. Diese Überwachung hilft zu erkennen, wo Qualitätsprobleme entstehen und wo Nachbesserungen nötig sind. Rechnungsempfänger sollten in der Lage sein, eingehende Rechnungen schnell zu erkennen und zu klassifizieren, damit sie in die richtige Verarbeitung fließen. Empfänger sollten auch validieren können, dass strukturierte Daten tatsächlich korrekt und vollständig sind – als Voraussetzung für automatisierte Verarbeitung.
Nein. ZUGFeRD 1.0 und 2.0 sind nicht kompatibel. Eine Datei kann nicht gleichzeitig beide Versionen enthalten und syntaktisch korrekt sein. Versionen ab 2.1 (2.1, 2.2, 2.3) sind untereinander interoperabel, da sie dieselbe CII-XML-Struktur verwenden.
Die E-Rechnungspflicht ab Januar 2025 verpflichtet Sie zum Empfang. Der Versand hat bis 2027/2028 Übergangsfrist. Viele Unternehmen implementieren zuerst den Empfang, später auch den Versand. Wer an öffentliche Auftraggeber liefert, sollte XRechnung-Versand parallel planen, da für behördliche Rechnungen strengere Anforderungen gelten.
Nein, nicht direkt. Ein einfaches PDF enthält keine strukturierten Daten. Um ZUGFeRD zu erzeugen, braucht man Zugriff auf die strukturierten Rechnungsdaten, idealerweise aus einem ERP- oder Buchhaltungssystem. Die meisten modernen Buchhaltungsprogramme können ZUGFeRD direkt erzeugen.
Middleware-Lösungen können ZUGFeRD-XML extrahieren und in Ihre ERP-Datenstrukturen abbilden. Dies ist aufwändiger, aber machbar. Der Nachteil ist, dass das Automatisierungspotenzial teilweise ungenutzt bleibt und Sie einen Medienbruch haben.
In Deutschland zehn Jahre lang, maschinell lesbar. Die Originaldatei mit eingebetteter XML muss aufbewahrt werden, nicht nur ein Ausdruck oder ein einzelnes PDF ohne XML. Je nach Kontext (Verträge, Lieferbedingungen, Audit-Anforderungen) können längere Aufbewahrungsfristen gelten.
Kostenlose Tools wie Profil-Checker analysieren die XML und bestimmen automatisch, welches Profil vorliegt. Sie können auch die XML mit einem Editor öffnen und nach bestimmten Elementen suchen, die nur in höheren Profilen vorhanden sind. Die XML kann extrahiert werden, indem Sie die Datei mit einem Archiv-Programm öffnen.
ZUGFeRD 2 kombiniert Lesbarkeit mit Automatisierung und ist ein durchdachter Standard für moderne Rechnungsprozesse. Die richtige Implementierung – klare Profilwahl, robuste Validierung, durchdachte Fehlerbehandlung und revisionssichere Archivierung – ist der Schlüssel zu wirtschaftlichem Nutzen und regulatorischer Sicherheit.