In der klassischen Welt gibt es zwei getrennte Vorstellungen von einer Rechnung. Die eine ist das Dokument, das man ansieht: ein Blatt Papier oder eine PDF-Datei mit Logo, Adressen, Positionen und Summen, die eine Person liest, prüft und ablegt. Die andere ist der reine Datensatz: eine strukturierte Aufstellung von Feldern, die eine Software ohne menschliches Zutun einliest und verbucht. ZUGFeRD löst den scheinbaren Widerspruch zwischen beiden Welten auf, indem es sie in einem einzigen Dokument vereint. Sichtbar ist ein ganz normales PDF; unsichtbar eingebettet steckt ein maschinenlesbarer XML-Datensatz mit denselben Rechnungsinhalten.
Genau das meint der Begriff hybrides Format. Der Empfänger kann frei wählen, wie er die Rechnung nutzt: Wer sie nur ansehen möchte, öffnet das PDF wie gewohnt. Wer sie automatisiert verarbeiten will, liest den eingebetteten XML-Datensatz aus und übergibt ihn an die Buchhaltung. Beide Sichten stammen aus derselben Datei und sollen denselben Inhalt tragen. Damit adressiert ZUGFeRD eine der zentralen Hürden bei der Einführung elektronischer Rechnungen: Nicht jeder Empfänger ist gleich weit, und niemand muss von heute auf morgen seine gesamte Verarbeitung umstellen.
Hinter ZUGFeRD steht das Forum elektronische Rechnung Deutschland (FeRD), eine nationale Plattform, in der sich Verbände, Ministerien, die öffentliche Verwaltung und Wirtschaftsvertreter zum Thema elektronische Rechnung abstimmen. Das FeRD ist keine Software und kein Anbieter, sondern ein Gremium, das den Standard definiert, dokumentiert und weiterentwickelt. Diese Herkunft ist wichtig: ZUGFeRD ist ein offener, herstellerneutraler Standard und nicht das Produkt eines einzelnen Softwarehauses. Wer ZUGFeRD unterstützt, folgt einer gemeinsamen Spezifikation, an die sich Rechnungsersteller und Empfangssysteme gleichermaßen halten können.
Der offene Charakter erklärt auch, warum ZUGFeRD in einer Vielzahl von Buchhaltungs-, ERP- und Rechnungsprogrammen auftaucht. Weil niemand Lizenzgebühren an einen Formatinhaber zahlt und die Spezifikation dokumentiert vorliegt, konnten viele Anbieter das Format in ihre Produkte aufnehmen. Für Unternehmen bedeutet das eine gewisse Unabhängigkeit: Man bindet sich an einen Standard, nicht an eine einzelne Software.
ZUGFeRD hat sich über mehrere Generationen entwickelt. Die erste Version legte das Grundprinzip fest — ein PDF/A mit eingebettetem XML. Mit der folgenden Generation rückte das Format näher an die europäische Normwelt heran und wurde technisch überarbeitet. Ein wichtiger Meilenstein war die Angleichung an die EU-Norm EN 16931 und die enge Abstimmung mit dem französischen Pendant, sodass ein gemeinsames deutsch-französisches Format entstand, das unter dem Namen Factur-X in Frankreich und als ZUGFeRD in Deutschland geführt wird. Spätere Versionen haben Profile ergänzt, Details präzisiert und die Interoperabilität mit XRechnung verbessert.
Für die Praxis ist weniger die genaue Versionsnummer entscheidend als das Bewusstsein, dass es verschiedene Versionsstände und Profile gibt. Welche Version ein Sender erzeugt und welche ein Empfänger verarbeiten kann, sollte im Zweifel abgeglichen werden. Die jeweils aktuelle Version, die verfügbaren Profile und deren genaue Bezeichnung entwickeln sich weiter und sollten beim FeRD beziehungsweise in der eingesetzten Software auf den aktuellen Stand geprüft werden.
Warum gerade PDF/A-3? PDF/A ist ein Standard für die langfristige, revisionssichere Archivierung von Dokumenten. Er stellt sicher, dass ein PDF auch in vielen Jahren noch originalgetreu darstellbar ist, weil etwa Schriften eingebettet und bestimmte Abhängigkeiten vermieden werden. Die Variante PDF/A-3 hat gegenüber ihren Vorgängern eine entscheidende Eigenschaft: Sie erlaubt das Einbetten beliebiger Dateien in das PDF. Genau diese Fähigkeit nutzt ZUGFeRD, um den XML-Datensatz in das PDF hineinzulegen. Das PDF bleibt damit ein vollwertiges, archivfähiges Dokument und trägt den strukturierten Datensatz gleichsam huckepack.
Der eingebettete Datensatz liegt im XML-Format CII (Cross Industry Invoice) vor. CII ist eine international etablierte Syntax für Rechnungsdaten und beschreibt die Rechnung in strukturierten Feldern: Rechnungsnummer, Rechnungsdatum, Angaben zu Verkäufer und Käufer, einzelne Positionen mit Mengen und Preisen, Steuerbeträge, Zahlungsbedingungen und Gesamtsummen. Weil dieselben Inhalte, die im PDF sichtbar sind, im XML strukturiert hinterlegt werden, kann eine Software die Rechnung auslesen, ohne die grafische Darstellung interpretieren zu müssen.
Ein zentrales Konzept von ZUGFeRD sind die Profile. Ein Profil legt fest, welchen Umfang und welche Detailtiefe der eingebettete XML-Datensatz hat. Vereinfacht gesagt reicht die Spanne von einem sehr schlanken Datensatz mit nur wenigen Kopfdaten bis hin zu einem umfassenden Datensatz mit allen Positionen und Zusatzangaben. Das ist praktisch, weil nicht jede Rechnung und nicht jeder Prozess die volle Datentiefe braucht — und weil Sender mit einem einfachen Profil einsteigen und später ausbauen können.
Für die meisten Unternehmen ist das EN-16931-Profil (in älterer Benennung auch als COMFORT geführt) der eigentliche Standardfall. Es bildet genau jene Rechnungsinhalte strukturiert ab, die die europäische Norm EN 16931 vorsieht, und stellt damit sicher, dass eine ZUGFeRD-Rechnung dieses Profils den inhaltlichen Kern einer normkonformen E-Rechnung erfüllt. Die schlankeren Profile MINIMUM und BASIC sind für Einstiegsszenarien und einfache Fälle gedacht, während EXTENDED zusätzliche Felder für komplexere Anforderungen bereithält. Welche Profile eine konkrete Software erzeugen und verarbeiten kann und wie sie im Detail benannt sind, unterscheidet sich zwischen Produkten und Versionsständen und sollte im Einzelfall geprüft werden.
Ein wichtiger Praxishinweis betrifft die schlanksten Profile: Ein Datensatz, der nur wenige Kopfdaten enthält, reicht für eine vollständig automatisierte Verbuchung im Regelfall nicht aus, weil ihm die Positions- und Detailinformationen fehlen. Solche Profile sind eher als Einstieg oder für eine grobe Vorerfassung gedacht. Wer die Vorteile der automatisierten Verarbeitung wirklich heben will, orientiert sich sinnvollerweise am EN-16931-Profil oder höher.
Ein Grundprinzip verdient besondere Aufmerksamkeit: Die sichtbare PDF-Ebene und der eingebettete XML-Datensatz sollen inhaltlich identisch sein. Was im PDF steht, muss auch im XML stehen und umgekehrt. Wenn die beiden Ebenen auseinanderlaufen — etwa weil ein Betrag nur im PDF korrigiert, aber nicht im XML aktualisiert wurde —, entsteht eine widersprüchliche Rechnung, die im schlimmsten Fall unbemerkt falsch verbucht wird. Verantwortungsvolle Rechnungssoftware erzeugt beide Ebenen aus derselben Datenquelle, sodass Abweichungen gar nicht erst entstehen. Beim Empfang gilt umgekehrt, dass man im Zweifel dem strukturierten XML-Datensatz die führende Rolle zuweist, weil dieser die maschinelle Verarbeitung steuert.
Der wichtigste gedankliche Ausgangspunkt: EN 16931 ist keine Datei, sondern eine Norm. Sie beschreibt, welche inhaltlichen Elemente eine elektronische Rechnung enthalten muss und wie diese semantisch definiert sind — also ein gemeinsames Datenmodell. ZUGFeRD, XRechnung und Factur-X sind demgegenüber konkrete Formate beziehungsweise Ausprägungen, die dieses Datenmodell technisch umsetzen. Wenn man so will, ist EN 16931 die Grammatik, und die Formate sind verschiedene Weisen, denselben Satz aufzuschreiben.
XRechnung ist ein rein strukturiertes E-Rechnungsformat und in Deutschland vor allem im Kontext der öffentlichen Verwaltung entstanden. Eine XRechnung ist im Kern ein XML-Datensatz ohne eingebettete Sichtebene — es gibt kein mitgeliefertes PDF, das ein Mensch bequem liest. XRechnung ist eine sogenannte nationale Ausprägung (CIUS) der EN 16931, also eine spezifische, auf deutsche Anforderungen zugeschnittene Umsetzung der Norm. Technisch kann XRechnung in unterschiedlichen XML-Syntaxen vorliegen; für die menschliche Ansicht braucht es eine Visualisierung, etwa über ein Anzeigeprogramm oder eine Stylesheet-Darstellung.
Factur-X ist im Kern dasselbe hybride Format wie ZUGFeRD. Es entstand in enger deutsch-französischer Abstimmung, sodass ZUGFeRD und Factur-X auf einer gemeinsamen technischen Basis stehen: ein PDF/A-3 mit eingebettetem CII-XML. In Deutschland läuft dieses Format unter dem Namen ZUGFeRD, in Frankreich unter dem Namen Factur-X. Für die Praxis bedeutet das eine hohe grenzüberschreitende Interoperabilität — eine korrekt erzeugte Datei kann in beiden Ländern im jeweiligen Verarbeitungskontext genutzt werden. Die beiden Namen bezeichnen also weitgehend dasselbe Konzept aus zwei nationalen Blickwinkeln.
Die entscheidende Nachricht ist, dass diese Formate nicht in Konkurrenz um „richtig oder falsch“ stehen, sondern unterschiedliche Wege zum selben Ziel sind. Weil sie sich am gemeinsamen Datenmodell der EN 16931 orientieren, lässt sich der inhaltliche Kern zwischen ihnen übertragen. Ein moderner Empfangsprozess sollte idealerweise mit mehreren dieser Formate umgehen können — mit dem eingebetteten XML einer ZUGFeRD-Datei ebenso wie mit einem reinen XRechnungs-Datensatz. Genau hier liegt eine der Stärken von ZUGFeRD: Da das EN-16931-Profil den Normkern trägt, ist die inhaltliche Nähe zu XRechnung groß.
In der Praxis begegnet Unternehmen die Formatfrage vor allem an den Rändern: Wer an die öffentliche Verwaltung fakturiert, trifft häufig auf die Erwartung eines bestimmten Formats; wer international arbeitet, profitiert von der gemeinsamen Basis mit Factur-X. INAGRO empfiehlt, die Formatentscheidung nicht abstrakt, sondern entlang der tatsächlichen Empfänger zu treffen: Welche Formate erwarten meine Kunden und Behörden, und was kann meine Software erzeugen und empfangen? Welche Formate und Ausprägungen im Einzelfall gefordert sind, kann sich ändern und sollte konkret geprüft werden.
Am Anfang steht eine europäische Initiative: Die EU wollte den elektronischen Rechnungsaustausch vereinheitlichen und schuf mit EN 16931 ein gemeinsames semantisches Datenmodell für elektronische Rechnungen. Die Norm beschreibt, welche Informationen eine E-Rechnung enthält und wie diese Informationen bedeutungsmäßig definiert sind — unabhängig davon, in welcher technischen Syntax sie am Ende ausgedrückt werden. Damit wurde eine gemeinsame Sprache geschaffen, an der sich nationale Formate wie XRechnung und hybride Formate wie ZUGFeRD und Factur-X ausrichten können.
Der Kern der Idee ist Interoperabilität über Grenzen und Systeme hinweg. Wenn alle Beteiligten dasselbe Datenmodell verwenden, kann eine Rechnung aus einem Land oder System in einem anderen verarbeitet werden, ohne dass für jede Kombination eine eigene Schnittstelle gebaut werden muss. ZUGFeRD ist in dieser Architektur eine konkrete Umsetzung: Sein EN-16931-Profil bildet den Normkern strukturiert ab und macht die Rechnung damit anschlussfähig an die gesamte europäische E-Rechnungswelt.
Ein häufiges Missverständnis lautet, jede PDF-Rechnung sei bereits eine E-Rechnung. Im rechtlichen Sinne des neueren Verständnisses ist das nicht der Fall. Eine bloße Bild-PDF, die per E-Mail verschickt wird, ist ein elektronisches Abbild einer Rechnung, aber keine strukturierte E-Rechnung. Als E-Rechnung im engeren Sinne gilt vielmehr eine Rechnung, die in einem strukturierten, maschinenlesbaren Format ausgestellt, übermittelt und empfangen wird und die eine automatisierte Verarbeitung ermöglicht — orientiert am europäischen Datenmodell. Genau diese Anforderung erfüllt ZUGFeRD über seinen eingebetteten XML-Datensatz, während eine reine Bild-PDF sie nicht erfüllt.
Diese Unterscheidung ist mehr als eine Feinheit. Sie erklärt, warum Unternehmen ihre Prozesse umstellen müssen: Das gewohnte Verschicken einer einfachen PDF genügt der strukturierten E-Rechnung nicht. ZUGFeRD ist hier ein eleganter Brückenschlag, weil es das gewohnte PDF beibehält und den geforderten strukturierten Datensatz zugleich mitliefert.
In Deutschland wird die Verpflichtung zur elektronischen Rechnung im inländischen Geschäftsverkehr zwischen Unternehmen (B2B) schrittweise eingeführt. Die grundsätzliche Stoßrichtung ist klar: Die strukturierte E-Rechnung wird zum Regelfall, papier- und einfache PDF-Rechnungen verlieren im B2B-Bereich schrittweise ihre Selbstverständlichkeit. Die Einführung ist typischerweise gestaffelt aufgebaut, sodass zunächst die Empfangsfähigkeit für E-Rechnungen im Vordergrund steht und die verpflichtende Ausstellung in weiteren Schritten und mit Übergangsregelungen folgt — häufig mit Erleichterungen für kleinere Unternehmen und Übergangszeiträumen.
Für viele Unternehmen ist ZUGFeRD gerade wegen der schrittweisen Einführung attraktiv. Das hybride Format erlaubt es, gleichzeitig alten und neuen Anforderungen gerecht zu werden: Der Empfänger, der noch nicht automatisiert verarbeitet, sieht weiterhin ein lesbares PDF; der Empfänger, der schon so weit ist, nutzt den eingebetteten Datensatz. Ein Rechnungssteller kann seine Belege also frühzeitig ZUGFeRD-fähig machen, ohne befürchten zu müssen, dass ein Teil seiner Kunden damit nichts anfangen kann. Diese Rückwärtskompatibilität macht ZUGFeRD zu einem pragmatischen Werkzeug in der Übergangsphase — und darüber hinaus. Ob im Einzelfall ZUGFeRD, XRechnung oder ein anderes Format gefordert ist, hängt vom Empfänger und der jeweils geltenden Regelung ab; dies ist keine Rechts- oder Steuerberatung.
Der übliche Weg beginnt in der Software, in der ohnehin fakturiert wird. Sind die Rechnungsdaten vollständig erfasst — Empfänger, Positionen, Steuersätze, Zahlungsbedingungen —, erzeugt das System daraus sowohl die visuelle PDF-Ebene als auch den strukturierten XML-Datensatz und bettet Letzteren in das PDF/A-3 ein. Weil beide Ebenen aus derselben Datenquelle stammen, sind sie inhaltlich konsistent. Für den Anwender fühlt sich das an wie das gewohnte Erzeugen einer PDF-Rechnung; die Hybridisierung geschieht im Hintergrund.
ZUGFeRD-Erzeugung findet man heute an mehreren Stellen der Softwarelandschaft. Fakturierungs- und Rechnungsprogramme für kleine Unternehmen bieten die Funktion ebenso an wie umfassende ERP- und Warenwirtschaftssysteme für den Mittelstand. Auch klassische Buchhaltungssoftware und Kanzleilösungen unterstützen die Erzeugung strukturierter Rechnungen. Wo eine Software das Format nicht nativ beherrscht, können spezialisierte Bibliotheken, Konverter oder Middleware die Lücke schließen. Für Unternehmen ist die praktische Frage weniger, ob ZUGFeRD grundsätzlich geht, sondern ob die konkrete eingesetzte Software das benötigte Profil und den passenden Versionsstand erzeugt.
Ein zentraler, in der Praxis gern übersehener Baustein ist die Validierung. Weil der eingebettete XML-Datensatz von der Gegenseite maschinell verarbeitet wird, muss er den formalen Regeln des jeweiligen Profils und der EN 16931 entsprechen. Eine Validierung prüft genau das: Sind alle Pflichtfelder vorhanden, stimmen die rechnerischen Zusammenhänge, ist die Syntax korrekt? Fehler, die hier auffallen, lassen sich vor dem Versand beheben — Fehler, die erst beim Empfänger auffallen, führen zu Rückfragen, Zahlungsverzögerungen und Nacharbeit. Es lohnt sich daher, die Validierung fest in den Ausstellungsprozess einzubauen und nicht auf gut Glück zu versenden.
Ebenso wichtig ist die Konsistenz zwischen PDF und XML. Wer nachträglich am PDF etwas ändert, ohne den Datensatz nachzuziehen, erzeugt eine widersprüchliche Datei. Deshalb sollten Korrekturen immer in der Ausgangssoftware erfolgen, aus der beide Ebenen neu und gemeinsam erzeugt werden. Manuelles Nachbearbeiten der fertigen Datei ist ein häufiger Stolperstein.
Beim Versand bleibt vieles vertraut: Eine ZUGFeRD-Datei ist technisch eine PDF-Datei und kann grundsätzlich auf denselben Wegen übermittelt werden wie eine gewöhnliche PDF-Rechnung — etwa per E-Mail oder über ein Rechnungsportal. Der Unterschied liegt nicht im Transportweg, sondern im Inhalt: Die Datei trägt den strukturierten Datensatz mit sich. Für bestimmte Empfänger, insbesondere im Umfeld der öffentlichen Verwaltung, können jedoch spezielle Übertragungswege oder Portale vorgeschrieben sein, und teils wird dort ein anderes Format erwartet. Welcher Weg und welches Format für einen konkreten Empfänger gelten, sollte vorab geklärt werden; pauschale Annahmen führen leicht zu abgelehnten Rechnungen.
Der Verarbeitungsweg beginnt mit dem Erkennen und Extrahieren. Trifft eine Rechnung ein, prüft das Empfangssystem, ob es sich um eine ZUGFeRD-Datei handelt, und liest den eingebetteten XML-Datensatz aus. Aus diesem strukturierten Datensatz gewinnt die Software die relevanten Felder — Rechnungsnummer, Datum, Lieferant, Positionen, Steuerbeträge, Summen — ohne dass ein Mensch sie abtippen muss. Genau hier liegt der Effizienzgewinn: Der Datensatz ist bereits strukturiert und muss nicht mühsam aus einem Bild oder Text rekonstruiert werden.
Es folgt die Prüfung und Anreicherung. Die ausgelesenen Daten werden gegen Stammdaten und Regeln geprüft: Ist der Lieferant bekannt, passt die Rechnung zu einer Bestellung oder einem Vertrag, sind die Beträge plausibel, stimmen Steuersätze und rechnerische Zusammenhänge? In vielen Systemen schließt sich ein Abgleich mit Bestellungen und Wareneingängen an, der klärt, ob die Rechnung berechtigt ist. Erst danach kommt die Kontierung und Verbuchung, bei der die Rechnung den passenden Konten zugeordnet und in die Buchhaltung übernommen wird.
Der Begriff Dunkelbuchung beschreibt den Idealzustand einer vollständig automatisierten Verarbeitung: Eine Rechnung wird eingelesen, geprüft, kontiert und verbucht, ohne dass ein Mensch eingreift — sie läuft gewissermaßen „im Dunkeln“ durch. Für standardisierte, wiederkehrende Rechnungen mit bekannten Lieferanten und klaren Zuordnungsregeln ist das ein realistisches und lohnendes Ziel. Es setzt allerdings voraus, dass die Datenqualität stimmt und dass die Regeln, nach denen automatisch gebucht wird, sorgfältig definiert sind.
Wichtig ist ein realistisches Erwartungsmanagement. Nicht jede Rechnung eignet sich für die Dunkelbuchung. Ungewöhnliche Sachverhalte, neue Lieferanten, Abweichungen zwischen Bestellung und Rechnung oder unklare Kontierungen gehören weiterhin auf den Tisch einer Fachkraft. Ein gut gestalteter Prozess bucht deshalb die eindeutigen Fälle automatisch und leitet die Ausnahmen gezielt zur manuellen Bearbeitung — statt zu versuchen, alles zu automatisieren und dabei Fehler zu riskieren. So entsteht ein Zusammenspiel aus Maschine und Mensch, das den Aufwand senkt, ohne die fachliche Kontrolle aufzugeben.
In der Praxis scheitert die automatisierte Verarbeitung selten am Format selbst, sondern an den Rändern. Ein häufiges Problem sind Rechnungen, die zwar wie ZUGFeRD aussehen, aber keinen (vollständigen) Datensatz enthalten — etwa reine Bild-PDFs oder Dateien mit einem sehr schlanken Profil, das nicht genug Informationen für die Verbuchung trägt. Ebenso können Abweichungen zwischen PDF und XML zu Verwirrung führen, wenn der Empfänger nicht klar definiert, welche Ebene führend ist. Und schließlich braucht die Automatisierung gepflegte Stammdaten auf der Empfängerseite: Ist der Lieferant nicht angelegt oder fehlen Zuordnungsregeln, bleibt die Rechnung liegen. INAGRO empfiehlt, den Empfangsprozess ebenso ernst zu nehmen wie die Erstellung — er ist es, der den eigentlichen Effizienzgewinn bringt.
Im Zentrum steht die Anbindung an Buchhaltung und ERP. Der aus einer ZUGFeRD-Rechnung ausgelesene Datensatz soll nicht in einer Insel landen, sondern direkt in die Finanzbuchhaltung oder das ERP-System fließen, wo er kontiert und verbucht wird. Je nahtloser diese Übergabe funktioniert, desto größer der Nutzen: Idealerweise wird eine Rechnung einmal eingelesen und steht anschließend für Buchung, Zahlung, Auswertung und Archiv zur Verfügung, ohne dass Informationen mehrfach erfasst werden. In integrierten Systemen ist dieser Weg kurz; in heterogenen Landschaften braucht es Schnittstellen, die die Daten sauber überführen.
Parallel zur buchhalterischen Verarbeitung spielt das Dokumentenmanagement (DMS) eine wichtige Rolle. Eine ZUGFeRD-Datei ist gleichzeitig ein visuelles Dokument und ein Datensatz — beides muss abgelegt und wiederauffindbar sein. Ein DMS speichert die Datei, verknüpft sie mit dem Buchungssatz und macht sie über Metadaten durchsuchbar. Der Charme des hybriden Formats zeigt sich hier erneut: Die eine Datei trägt sowohl die menschenlesbare Ansicht für spätere Einsicht als auch den strukturierten Datensatz, der die Zuordnung und Suche erleichtert. Für eine spätere Prüfung — etwa durch die Finanzverwaltung — ist es entscheidend, dass die Originaldatei unverändert und vollständig aufbewahrt wird.
Rechnungen sind aufbewahrungspflichtige Unterlagen, und für ihre digitale Aufbewahrung gelten in Deutschland die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form (GoBD). Für ZUGFeRD bedeutet das vor allem: Die Rechnung muss in ihrem Originalzustand aufbewahrt werden — und zwar so, dass sie unverändert, vollständig und über die gesetzliche Aufbewahrungsfrist hinweg lesbar bleibt. Weil die ZUGFeRD-Datei den strukturierten Datensatz enthält, ist gerade dieser Datensatz Teil des Originals und darf nicht verloren gehen, etwa indem nur ein ausgedrucktes oder neu erzeugtes PDF archiviert wird.
Die zentralen Prinzipien lauten Nachvollziehbarkeit, Unveränderbarkeit und Vollständigkeit. Es muss nachvollziehbar sein, wann welche Rechnung eingegangen ist und wie sie verarbeitet wurde; die aufbewahrte Datei darf nachträglich nicht unbemerkt verändert werden; und es dürfen keine Belege fehlen. Ein GoBD-konformes Archiv stellt dies technisch und organisatorisch sicher — durch geeignete Speicherung, Zugriffskontrollen und eine dokumentierte Verfahrensweise. Die genauen Anforderungen und deren Auslegung sind ein eigenes Fachthema; die Details gehören zum Steuerberater und zur Verfahrensdokumentation. Dies ist keine Steuerberatung.
INAGRO rät, die Integration von Beginn an mitzudenken statt sie als Nachgedanken zu behandeln. Die entscheidenden Fragen lauten: Wie kommt eine eingehende ZUGFeRD-Rechnung von der E-Mail oder dem Portal in das Buchhaltungssystem, wo wird sie geprüft, wie wird sie archiviert, und wer verantwortet die Schnittstellen? Eine durchdachte Kette aus Empfang, Verarbeitung, Buchung und Archiv spart über das Jahr erheblichen Aufwand und reduziert Fehlerquellen. Eine Insellösung dagegen erzeugt manuelle Übertragungen und Medienbrüche — genau das, was ZUGFeRD eigentlich vermeiden soll. Welche Systeme sich wie anbinden lassen, hängt von der konkreten Software ab und sollte mit den Anbietern und dem Umsetzungspartner geklärt werden.
Der Nutzen ist auf beiden Seiten der Rechnung greifbar. Als Rechnungssteller wird man mit ZUGFeRD-fähigen Belegen den Erwartungen zunehmend digital arbeitender Kunden und der wachsenden gesetzlichen Anforderung gerecht — ohne die gewohnte, lesbare PDF aufzugeben. Als Rechnungsempfänger liegt der größere Hebel: Die automatisierte Verarbeitung von Eingangsrechnungen spart Erfassungsaufwand, reduziert Tippfehler und beschleunigt Freigabe und Zahlung. Über das Jahr summiert sich das gerade bei mittleren Rechnungsvolumina spürbar.
Dem steht ein Aufwand gegenüber, der nicht verschwiegen werden sollte. Es braucht Software, die ZUGFeRD erzeugen und empfangen kann, gepflegte Stammdaten, definierte Prozesse für Prüfung und Freigabe sowie eine GoBD-konforme Archivierung. Hinzu kommt der organisatorische Wandel: Mitarbeitende müssen den neuen Weg verstehen und mittragen. Dieser Aufwand ist überschaubar, aber real — und er fällt vor allem einmalig bei der Einführung an, während der Nutzen dauerhaft wirkt.
In der Praxis begegnet ZUGFeRD dem Mittelstand in wiederkehrenden Konstellationen. Ein Handels- oder Dienstleistungsbetrieb stellt seine Ausgangsrechnungen auf ZUGFeRD um, um Geschäftskunden und Behörden gerecht zu werden, und behält dabei die vertraute PDF-Ansicht. Ein Unternehmen mit vielen Eingangsrechnungen — etwa im Einkauf — automatisiert die Verarbeitung, um Erfassungsaufwand zu senken und Skonto-Fristen besser zu nutzen. Ein Betrieb, der eng mit seinem Steuerberater zusammenarbeitet, profitiert davon, dass strukturierte Rechnungsdaten die Übergabe und Weiterverarbeitung erleichtern.
Allen Szenarien ist gemeinsam, dass der Nutzen mit dem Volumen und der Prozessreife steigt. Wer nur wenige Rechnungen im Monat schreibt, spürt den Effekt weniger als ein Betrieb mit vielen wiederkehrenden Belegen. INAGRO empfiehlt, die Einführung an den tatsächlichen Volumina und den realen Empfängern auszurichten — und nicht die technisch anspruchsvollste Lösung um ihrer selbst willen zu wählen.
Aus der Beratungspraxis lassen sich einige wiederkehrende Fallstricke benennen. Erstens die Verwechslung von PDF und E-Rechnung: Eine bloße Bild-PDF ist keine strukturierte E-Rechnung, auch wenn sie so aussieht. Zweitens das falsche Profil: Wer ein sehr schlankes Profil wählt, liefert zu wenig strukturierte Daten für die automatisierte Verarbeitung. Drittens Inkonsistenzen zwischen PDF und XML durch nachträgliches Bearbeiten der Datei. Viertens vernachlässigte Stammdaten, die die Automatisierung auf der Empfängerseite ausbremsen. Und fünftens eine unzureichende Archivierung, die nicht die vollständige Originaldatei aufbewahrt. Alle diese Stolpersteine sind vermeidbar, wenn man die Einführung strukturiert angeht und nicht ad hoc improvisiert.
Aus steuerlicher Sicht ist zunächst wichtig, dass eine Rechnung bestimmte Pflichtangaben enthalten muss, damit sie ihren Zweck — insbesondere den Vorsteuerabzug — erfüllen kann. Das EN-16931-Profil von ZUGFeRD bildet die geforderten Rechnungsinhalte strukturiert ab und unterstützt damit eine ordnungsgemäße Rechnung. Ob eine konkrete Rechnung im Einzelfall alle Anforderungen erfüllt, ist jedoch eine fachliche Bewertung, die nicht die Software, sondern der Mensch — im Zweifel der Steuerberater — trifft. Die Software liefert die Struktur; die inhaltliche Richtigkeit bleibt in der Verantwortung des Unternehmens.
Bei der Aufbewahrung gelten, wie in Kapitel 07 beschrieben, die GoBD: Die vollständige Originaldatei ist unverändert, vollständig und über die gesetzliche Frist lesbar aufzubewahren. Für ZUGFeRD ist dabei die Besonderheit zu beachten, dass der eingebettete Datensatz zum Original gehört. Wer nur einen Ausdruck oder ein neu erzeugtes PDF archiviert, riskiert, das Original unvollständig aufzubewahren. Eine dokumentierte Verfahrensweise, die den gesamten Weg von Empfang über Verarbeitung bis Archiv beschreibt, ist hier ein wichtiger Baustein.
Sobald für Erstellung, Versand, Empfang oder Archivierung von E-Rechnungen Cloud-Plattformen oder externe Dienstleister eingesetzt werden, rückt der Datenschutz in den Vordergrund. Rechnungen enthalten personenbezogene Daten — etwa Namen von Ansprechpartnern, Kontaktdaten und teils Angaben, die Rückschlüsse auf Geschäftsbeziehungen erlauben. Werden diese Daten von einem Dienstleister verarbeitet, handelt es sich in der Regel um eine Auftragsverarbeitung, die einen entsprechenden Vertrag (AVV) und die Aufnahme in das eigene Verarbeitungsverzeichnis erfordert.
Ein besonderes Augenmerk verdient der Serverstandort und Verarbeitungsort. Liegen die Daten und die Verarbeitung in der EU beziehungsweise im EWR, sind Fragen des Drittlandtransfers entschärft, und die Datenhoheit bleibt im europäischen Rechtsrahmen. Genau hier liegt eine Stärke, die im DACH-Mittelstand zunehmend geschätzt wird: EU-Datenhoheit als Qualitätsmerkmal. Wer eine Plattform oder einen Dienstleister wählt, sollte deshalb aktiv prüfen, wo die Daten gespeichert und verarbeitet werden, ob ein Transfer in Drittländer stattfindet und wie dieser gegebenenfalls abgesichert ist. Bei Anbietern mit Sitz oder Infrastruktur außerhalb der EU ist besondere Sorgfalt geboten.
Compliance rund um die E-Rechnung ist kein einmaliges Häkchen, sondern eine fortlaufende Aufgabe. Gesetzliche Anforderungen, Fristen und Formatvorgaben entwickeln sich weiter; Software wird aktualisiert; Prozesse ändern sich. INAGRO empfiehlt, Verantwortlichkeiten klar zu benennen, die Verfahrensweise zu dokumentieren und regelmäßig zu prüfen, ob die eingesetzten Formate, Wege und Aufbewahrungsmethoden noch dem aktuellen Stand entsprechen. Weil die Materie sowohl steuerliche als auch datenschutzrechtliche Fragen berührt, gehört die verbindliche Bewertung in die Hände der jeweiligen Fachleute.
