Hilfe zu ZUGFeRD und XRechnung

Aufgepasst bei E-Rechnungen!

Sichtbares PDF und eingebettete Rechnung könnten unterschiedlich sein!
- Seit 1.1.2025 ist das eingebettete XML die maßgebliche Rechnung.
- Böswillige Akteuere könnten Ihnen falsche Beträge unterjubeln. Beachten Sie das!

ZUGFeRD kombiniert ja in einem PDF-Dokument (PDF/A-3) sowohl eine sichtbare Rechnung als auch strukturierte Rechnungsdaten im XML-Format (auch "hybride Rechnung" genannt). dabei ist dann aber entscheidend, dass PDF und XML denselben Inhalt gemäß § 14 Abs. 4 Umsatzsteuergesetz (UStG) widerspiegeln (die sog. "inhaltliche Identität"). Da von der Finanzverwaltung keine spezifischen Kontrollen vorgeschrieben sind, sollten Unternehmen eigene Verfahren entwickeln, um sicherzustellen, dass beide Versionen der Rechnung identisch sind. Was also als Vereinfachung des Versands und der elektronischen Verarbeitung von Rechnungen gedacht ist, bringt auch wieder neue Fallstricke mit sich. Gerade größere Unternehmen, die das XML-Datenformat in bestehende Softwaresysteme teilautomatisert integriert haben, könnten hier falsche Beträge unbemerkt bewilligen.

Daher immer prüfen!

Müssen Kleinunternehmer E-Rechnungen versenden?

Kleinunternehmer (nach § 19 Umsatzsteuergesetz) sind ab 1. Januar 2025 von der Ausstellung von E-Rechnungen befreit, müssen diese aber weiterhin empfangen können. Als "Kleinunternehmer" gilt ein Gewerbetreibender (Einzelunternehmer oder Freiberufler), der im Vorjahr nicht mehr als 25.000 Euro Umsatz netto generiert hat und voraussichtliche im laufenden Jahr 100.000 Euro netto Umsatz nicht übersteigen wird. Bei GmbHs muss die Behandlung als Kleinunternehmer gesondert beantragt werden und Kleingewerbetreibende mit einfachem Gewerbeschein können die Regelung freiwillig ablehnen (mit erneuter Prüfung nach 5 Jahren). Wird die Behandlung als Kleinunternehmer dagegen in Anspruch genommen, dann zieht das vor allem umsatzsteuerliche Regelungen nach sich. Ein Kleinunternehmer weist auf Rechnungen keine Umsatzsteuer aus und es besteht kein Recht auf Vorsteuerabzug. Zudem müssen Kleinunternehmer keine Umsatzsteuervoranmeldungen abgeben. Und hier im Kontext der E-Rechnung besonders relevant: Kleinunternehmer müssen eben ab 1. Januar 2025 E-Rechnungen zwar empfangen können, sind aber von der Pflicht zur Ausstellung von E-Rechnungens befreit.

Was bedeutet es, E-Rechnung empfangen zu können?

Eine E-Rechnung, als eine ZUGFeRD oder XREchnung, "empfangen zu können" ist ja nun seit dem 1.1.2025 Pflicht für quasi alle. Daher ist es wichtig einfach zu wissen, dass "empfagen können" schlichtweg heißt, dass sie eine eingegangene E-Rechnung lesen können müssen - also auf ihrer Grundlage eine geschäftliche Aktion tätigen können. Mit anderen Worten: sie können lesen, welche Beträge etwa zu begleichen sind oder welche Summen ihnen zurückerstattet werden, etc. Eben alles, was man mit einer handelsüblichen Papierrechnung bisher auch getan hätte.
Es geht nicht zwingend darum, die E-Rechnung in irgendein System einzuspielen. Es ist aber schon so, dass sie - falls sie spezielle Buchhaltungssoftware selbst im Hause einsetzen - in der Lage sein müssen, diese Rechnung in ihrem System zu erfassen. Das kann bedeuten, dass ihr System in der Lage ist, eine E-Rechnung zu importieren. Das könnte aber auch bedeuten, dass Sie die Informationen der maßgeblichen eingebetteten XML-Daten abtippen oder sonstwie korrekt übernehmen können. Viele Betriebe werden nach Kenntnisnahme die E-Rechnung auch schlicht an ihren Buchhalter oder Steuerberater weiterreichen. So oder so ist es aber wichtig, den Inhalt einer E-Rechnung korrekt anzuzeigen. Dafür helfen Tools, wie man sie hier auf unserem ZUGFeRD Portal findet.
Am 15.Oktober 2024 veröffentlichte das Bundesministerium der Finanzen (BMF) einige wichtige Konkretisierungen vor der Einführung der obligatorischen elektronischen Rechnung bei Umsätzen zwischen inländischen Unternehmern ab dem 1. Januar 2025.

Welche E-Rechnungen muss man empfangen können?

Alle Formate. Unternehmen in Deutschland müssen ab dem 1. Januar 2025 sowohl ZUGFeRD als auch reine XML-Dateien verarbeiten können. Konkret bedeutet dies:

  • ZUGFeRD:
    Unternehmen müssen das Hybrid-Format empfangen können, das aus einem menschenlesbaren PDF/A-3 mit eingebetteter XML-Datei in der Syntax "Cross-Industry Invoice" (CII) besteht
  • XRechnung:
    Unternehmen müssen auch reine XML-Dateien empfangen können, und zwar in zwei Varianten:
    • XML-Datei in der Syntax "Cross-Industry Invoice" (CII)
    • XML-Datei in der Syntax "Universal Business Language" (UBL)

Diese Formate entsprechen der europäischen Norm EN 16931 für elektronische Rechnungen. Die Empfangspflicht gilt für alle inländischen Unternehmen, unabhängig von ihrer Größe. Es ist wichtig zu beachten, dass ab dem 1. Januar 2025 keine Zustimmung des Empfängers mehr erforderlich ist, um E-Rechnungen in diesen Formaten zu erhalten.

Aufbewahrung von E-Rechnungen

Wie ist es mit der Aufbewahrungspflicht bei E-Rechnungen? Nun, elektronische Rechnungen dürfen nicht ausgedruckt archiviert werden, da sie maschinell auswertbar bleiben müssen. Das Umsatzsteuergesetz verlangt, dass Rechnungen über einen Zeitraum von zehn Jahren aufbewahrt werden (§ 14b Abs. 1 Satz 1 UStG).
Für digitale Rechnungen gilt außerdem, dass sie gemäß den GoBD (Grundsätze zur ordnungsgemäßen Führung und Aufbewahrung von elektronischen Dokumenten) archiviert werden müssen. Gemäß Randziffer 131 der GoBD, Stand 28. November 2019, müssen Handels- und Geschäftsbriefe sowie Buchungsbelege in dem Format gespeichert werden, in dem sie empfangen wurden. Dieses Originalformat der elektronischen Rechnungen ist ausschlaggebend für die ordnungsgemäße Archivierung (Randziffer 128 GoBD). Bei der Übermittlung von Rechnungen per E-Mail kann man allerdings die eigentliche E-Mail vernachlässigen, denn nach Ansicht des Gesetzgebers dient die E-Mail primär als Transportmittel, ähnlich einem Umschlag. Eine Archivierung der E-Mail ist also grundsätzlich nicht erforderlich, außer sie enthält zusätzliche Informationen, die für die Rechnung relevant und aufbewahrungspflichtig sind.

→ Kontaktieren Sie die Datenspeicher-Spezialisten der Micropolis GmbH für GoBD-konforme Archivierungs-Lösungen.

Wie benutze ich Zugferd? (Ist das eine Software?)

Nein, ZUGFeRD ist keine Software oder Programm. ZUGFeRD ist ein Datenformat. Eine recht standardisierte Datei, die die rechtlichen Vorgaben der Europäischen Union (EU-Richtlinie 2014/55/EU, Europäische Norm 16931) umsetzt, jedoch nicht als eigenständige Softwarelösung. Der "ZUGFeRD Standard" beschreibt die Struktur eines Datensatzes, bestehende aus einer PDF-Datei, die XML-Anhänge mit sich führt. Das Erstellen, das Lesen, das Sepichern dieser Daten und der Transportdateien wiederum ist dann in die firmeneigene Software zu integrieren. Unternehmen haben hierbei unterschiedliche Möglichkeiten der Integration: Häufig erfolgt die Einbindung über Standardsoftware wie ERP- oder EDI-Systeme. Alternativ kann die hauseigene IT-Abteilung ZUGFeRD eigenständig in spezieller Individualsoftware implementieren. Zahlreiche Buchhaltungs- und ERP-Systeme bieten bereits eine Unterstützung für ZUGFeRD. Auch Online-Tools wie unser ZUGFeRD Rechnungsgenerator oder Browser-basierte ZUGFeRD Rechnungsprüfer helfen, mit validierten E-Rechnungen zu arbeiten.

Was sind die ZUGFeRD "Profile"?

Grob gesagt sind das Varianten einer ZUGFeRD Datei. Die aktuellen ZUGFeRD Spezifikationen definieren aktuell 5 Profile, von denen 3 vollständig den Anforderungen entsprechen (die anderen zwei können nur intern als Buchungshilfen verwendet werden. Um EU-konforme elektronische Rechnungen zu erstellen, empfiehlt sich das Profil COMFORT (EN 16931). Die fünf ZUGFeRD-Profile unterscheiden sich durch die Menge der standardisierten Daten und dem Grad ihre Übereinstimmung mit den Anforderungen des Umsatzsteuergesetzes (UStG).
  • Profil EN 16931 (COMFORT)
    Dieses Profil repräsentiert die vollständige EN 16931-1 und konzentriert sich auf die wesentlichen Inhalte einer elektronischen Rechnung. Es erfüllt die UStG-Vorgaben vollständig und wird in Deutschland als vollwertige Rechnung anerkannt.
  • Profil EXTENDED
    Als Erweiterung der EN 16931-1 unterstützt dieses Profil komplexe Geschäftsprozesse, beispielsweise bei Rechnungen für mehrere Lieferungen oder Lieferorte, strukturierte Zahlungsbedingungen oder zusätzliche Lagerhaltungsinformationen auf Positionsebene. Auch dieses Profil ist gemäß UStG in Deutschland eine vollständige Rechnung.
  • Profil BASIC
    Dieses Profil bildet eine reduzierte Version der EN 16931-1 ab und eignet sich für einfache UStG-konforme Rechnungen. In Deutschland wird es ebenfalls als vollständige Rechnung anerkannt.
  • Profil MINIMUM
    Es enthält grundlegende Angaben wie die Identität von Käufer und Verkäufer, den Gesamtrechnungsbetrag und die Gesamtumsatzsteuer. Details auf Positionsebene sind nur begrenzt vorhanden, und eine Umsatzsteueraufschlüsselung ist nicht enthalten. Daher gilt dieses Profil als Buchungshilfe und nicht als vollständige Rechnung gemäß UStG.
  • Profil BASIC WL
    Dieses Profil enthält keine Rechnungspositionen, stellt aber auf Dokumentebene alle relevanten Informationen zur Verfügung, die für die Buchung der Rechnung benötigt werden. Es ist keine UStG-konforme Rechnung, sondern dient als Buchungshilfe.

Gibt es verschiedene ZUGFeRD Versionen?

Ja, es gibt verschiedene Versionen von ZUGFeRD, die im Laufe der Zeit weiterentwickelt wurden, um wechselnde Anforderungen an elektronische Rechnungen zu erfüllen. Der Übergang von ZUGFeRD 1 auf ZUGFeRD 2 brachte dabei zahlreiche Änderungen mit sich, insbesondere bei der Benennung der XML-Knoten (also der kompatibilität der eingebetteten XML-Anhänge). Dabei wurde das zugrunde liegende XML-Schema von "CrossIndustryDocument" auf "CrossIndustryInvoice" umgestellt, was zu einer verbesserten Struktur und Kompatibilität führen sollte - aber eben auch umfangreiche Änderungen in jeder verarbeitenden Software mit sich brachte.
Die aktuelle ZUGFeRD-Version 2.2.x (Stand 2025) basiert auf dem Factur-X-Standard in der Version 1.0.06. Diese Versionen wurden entwickelt, um sich den ebenfalls im Fluss befindlichen europäischen Vorgaben anzugleichen, darunter die EN 16931 und die EU-Richtlinie 2014/55/EU. Während ZUGFeRD in verschiedenen Profilen wie BASIC, COMFORT und EXTENDED angeboten wird, wird das Referenzprofil XRECHNUNG unabhängig von ZUGFeRD durch die Koordinierungsstelle für IT Standards (KoSIT) gepflegt und weiterentwickelt. Dies bringt mit sich, dass wohl auch die Versionen von ZUGFeRD kontinuierlich angepasst werden müssen, um konform zu bleiben und neueren Anforderungen zu entsprechen.

Beispiel einer ZUGFeRD Rechnung. Gibt es Beispiel-ZUGFeRD-Rechnungen im Netz??

Ja, es gibt zahlreiche Beispieldateien, sowohl ZUGFERD, als auch XRechnung oder Factur-X, im Netz zum Download. Manche davon sind von offizieller Stelle ausgegeben, andere sind eine Sammlung von Dateien, wie man sie "in der Wildniss" des Alltags findet, teils mit bewussten Fehlern oder anderen Sonderbarkeiten. Hier ist eine Linkliste - natürlich ohne Anspruch auf Vollständigkeit:

Zusammenhang zwischen den verschiedenen Standards für E-Rechnungen

Im Kontext elektronischer Rechnungen existiert eine Vielzahl von Begriffen und Standards, die miteinander in Beziehung stehen. ZUGFeRD ist ein deutsches Gewächs und wurd von der FeRD Initiative als inländischer Standard für elektronische Rechnungen entwickelt. Aufgrund einer Annäherung an einen ähnlichen französischen Standard ist ZUGFeRD 2.1 schließlich identisch mit Factur-X. Der Standard Factur-X 1.0 bzw. ZUGFeRD 2.1 wiederum entspricht im Zuge einer noch weitreichenderen harmonisierung der europäischen Norm EN 16931. Das ergibt ZUGFeRD 2.1 = Factur-X 1.0 = EN 16931. Die EN 16931 Norm wiederum basiert auf dem globalen UN/CEFACT-Standard "Cross Industry Invoice" (CII), der noch auf das ältere EDIFACT zurückgeht.
Parallel dazu existiert mit XRechnung ein weiterer deutscher Standard, der ebenfalls Teil der EN 16931 ist. XRechnung wird von der Koordinierungsstelle für IT-Standards (KoSIT) definiert. Während Factur-X 1.0, ZUGFeRD 2.1 als auch XRechnung die Anforderungen der EN 16931 erfüllen, sind die Rechnungsformate (Factur-X/ZUGFeRD vs. XRechnung) nicht zwangsläufig identisch. Um hier wiederum eine Kompatibilität herzustellen, wurde mit ZUGFeRD Version 2.1.1 ein XRechnung-Referenzprofil eingeführt.

Was ist ein PDF/A-3?

Auch PDF-Dateien gibt es in verschiedenen Versionen und Formaten, jeweils mit verscheidenen Fähigkeiten. Für ZUGFeRD-Rechnungen sind PDF-Dateien im Format PDF/A-3 als Trägerdatei vorgeschrieben. Diesem PDF-Format liegt in der Regel eine PDF-Datei in Version 1.7 zugrunde. Die PDF/A-Varianten sind generell PDF-Dateien, die standardisiert bzw. zertifiziert sind und auch längere Archivierungsanforderungen, etwa für Lesbarkeit in der Zukunft, erfüllen sollen. Die Spezifikationen für PDF/A und PDF/UA sind dabei jeweils Einschränkungen und Anforderungen (Erweiterungen) der PDF-Standards, die ihnen zugrunde liegen (also PDF 1.4 für PDF/A-1, ISO 32000-1 für PDF/A-2 und PDF/A-3 und PDF/UA-1 und schließlich ISO 32000-2 für PDF/A-4 und PDF/UA-2).

Eine PDF/A-3 Datei basiert dabei immer auf der PDF-Version 1.7 oder höher. Denn obwohl auch PDF-Dateien der Version 1.4 in der Lage sind, beliebige Dateien anzuhängen, so schließt der auf PDF 1.4 basierende Format-Standard PDF/A-1 explizit jegliche Anhänge aus, die keine eingebetteten Schriftarten, Farbprofile oder andere zum Darstellen der Seite nötigen Dateien sind. Erst das Format PDF/A-3, welches auf der etwas neueren PDF Version 1.7 basiert, erlaubt das Anhängen von beliebigen Dateien. Und dazu zählt eben auch die XML-Rechnung einer ZUGFeRD-Datei. Nun gibt es vom PDF/A-3 Format auch wieder Untervarianten, etwa PDF/A-3a, PDF/A-3b, and PDF/A-3u. Für ZUGFeRD sind alle diese Varianten erlaubt.

Zitat aus dem "Leitfaden PDF/A-3 als Trägerformat für ZUGFeRD" des FeRD: "Besonderheiten einer PDF/A Datei im Vergleich zu einem beliebigen PDF Dokument sind (...):
  • Es muss eine Kennung in Form eines XMP Erweiterungsschemas existieren, das die PDF/A-Eigenschaft und den Konformitätsstufe (ConformanceLevel) explizit enthält
  • Alle Metadaten sind in XMP Form einzubetten. Das verwendete XMP Schema kann entweder aus der Menge vordefinierter Schemata genommen werden oder es muss ein eigenes Schema erstellt und zwingend immer mit den Metadaten zusammen eingebettet werden.
  • Alle verwendeten Zeichensätze sind in das PDF/A einzubetten. Zur Optimierung können an Stelle vollständiger Zeichensätze auch nur Subsets der effektiv verwendeten Glyphen eingebettet werden.
  • Es dürfen keine Fremddateien wie Filme, Tondateien oder sonstige Binärdateien eingebettet werden, außer über den später beschriebenen A-3 konformen Mechanismus.
  • Es dürfen keine aktiven Elemente mehr im PDF/A vorhanden sein. Darunter versteht man z.B. JavaScript für Aktionen oder Flash für Animationen.
  • Es sind nur genau definierte Bildformate zur Einbettung zulässig. Dazu zählen CCITT Group 3 und Group 4, JBIG2, JPEG und JPEG2000.
  • Es darf keine Verschlüsselung oder sonstige Berechtigungssteuerung im Dokument enthalten sein.

Was sind XMP Metadaten?

Ein gewöhnliches PDF wird zu einem PDF/A-3 durch eine Reihe von Erweiterungen. Eine dieser Erweiterungen ist, dass in der Datei in einem speziellen Block eine kleine Textdatei eingebettet wird, die eine standardisiert formatierte Beschreibung der Datei selbst und der darin enhaltenen Informationen darstellt. Diese Textdatei folgt den Vorgaben der sog. "Extensible Metadata Platform" kurz "XMP", eine Auszeichnungstechnologie für Metadaten, geschrieben als XML Datei. Eine PDF/A-3 Datei muss zwingend einen XMP Block enthalten. Von Seiten der Vorgaben für ein PDF/A-3 wird erwartet, dass darin RDF Description tags aus den Namespaces xmlns:xmp="http://ns.adobe.com/xap/1.0/", xmlns:pdf="http://ns.adobe.com/pdf/1.3/" und xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/" (ohne Anspruch auf Vollständigkeit) definiert sind. Damit aus einer standardkonformen PDF/A-3 Datei auch noch eine konforme ZUGFeRD-Rechnung wird, müssen weitere Namespaces definiert sein, etwa xmlns:pdfaExtension="http://www.aiim.org/pdfa/ns/extension/" oder xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#". Letzterer Namespace legt z.B. fest, dass es sich hier um Angaben gem. des Factur-X-Invoice-Profils Version 1.0 ("1p0" bedeutet "1.0") handelt.

Wie wird die XML-Datei in das PDF/A-3 eingebettet?

PDF-Dateien können eine ganze Reihe von Dingen, außer nur Seiten von Text darstellen. Ähnlich der Datei eines Textverarbeitungsprogrammes können hier in den Text Bilder eingesetzt, oder eben "eingebettet" werden. Und PDF/A-3 bietet die Möglichkeit, ganze Dateien - vergleichbar mit einer ZIP-Datei, die auch mehrere Dateien bündelt - zu dem eigentlichen Dokument hinzuzufügen. Technisch spricht man hier von Dateianhängen - obwohl im Bezug auf die ZUGFeRD-Rechnung auch immer von "in die PDF-Datei einbetten" gesprochen wird. Dateianhänge kennt man wohl eher von E-Mails. Das Verfahren zum Anhängen der XML-Rechnung an die PDF-Datei ist aber ganz ähnlich. Wichtig ist darauf hinzuweisen, dass ZUGFeRD oder Factur-X Rechnungen immer nur einen Anhang haben (die XML Version der Rechnung) dürfen (zumindest gem. Version 1.0 des ZUGFeRD Standards - Version 2.x hingegen erlaubt es). Dieser Anhang muss zudem auch einen speziellen Dateinamen haben und einen passenden MIME-Type (Dateiformat-Angabe). Man kann also an E-Rechnungen nicht einfach noch beliebige Dokumente oder Bilder anhängen, da so Buchhaltungssysteme durcheinander kommen könnten.

Leitfaden PDF/A-3 als Trägerformat für ZUGFeRD

Was ist eine XRechnung?

Die XRechnung, bereitgestellt von der „Koordinierungsstelle für IT Standards“ (KoSIT), ist ein Format zum Austausch elektronischer Rechnungen. Sie basiert auf einem vollständig strukturierten Datenmodell, das sämt/liche Rechnungsinhalte klar definiert. Dies ermöglicht eine automatische elektronische Weiterverarbeitung der Informationen und erfüllt damit moderne Anforderungen an Effizienz und Standardisierung. Die Rechnung liegt dabei als XML-Dokument vor - daher auch XRechnung.

Was ist ein hybrides Rechnungsformat?

Ein hybrides Rechnungsformat kombiniert zwei Elemente in einem Dokument: eine visuelle, menschenlesbare Darstellung der Rechnung und strukturierte, maschinenlesbare Daten. Beispielsweise enthält das PDF-Dokument einer ZUGFeRD-Rechnung eine traditionelle Rechnung, die einfach mit den Augen überprüft werden kann, während gleichzeitig XML-Daten integriert sind, die von Software für automatisierte Prozesse genutzt werden können. Dieses Format erleichtert sowohl die manuelle als auch die elektronische Verarbeitung von Rechnungen, was besonders bei digitalen Geschäftsabläufen von Vorteil ist. Dadurch, dass beide Darstellungen einer Rechnung bereitsgestellt werden, ist ein Übergang von traditionellen zu moderneren digitalen Prozessen ermöglicht. Allerdings setzt das voraus, dass die sichtbare und "unsichtbare" Rechnung inhaltlich identisch sind - siehe Aufgepasst bei E-Rechnungen!.

Gibt es ein ZUGFeRD XML-Schema

Ja, zu ZUGFeRD gibt es ein XML-Schema. Das XML-Format, das in ZUGFeRD verwendet wird, basiert auf dem Core Cross Industry Invoice (CII)-Standard (grob: der Kern-Branchenübergreifende Rechnungsstandard), der von UN/CEFACT entwickelt wurde. Das Format folgt spezifischen Schema-Definitionen, um die Kompatibilität und Validierung für elektronische Rechnungen sicherzustellen. Ein XML "Schema" ist dabei ein weiteres Dokument (.xsd), welches zu Datenfeldern, die in einer XML-Datei angegeben sind, entsprechende Prüfvorgaben enthält. Dabei werden dann z.B. folgende Elemente einer ZUGFeRD_Rechnung geprüft:

Struktur: Die XML-Datei gliedert sich in mehrere zentrale Bereiche:
  • ExchangedDocumentContext: Legt den Kontext der Rechnung fest, einschließlich des verwendeten ZUGFeRD-Profils (z. B. BASIC, EN16931, EXTENDED).
  • ExchangedDocument: Enthält Metadaten der Rechnung, wie Rechnungsnummer und -datum.
  • SupplyChainTradeTransaction: Beinhaltet detaillierte Transaktionsdaten, wie eine aufgeschlüsselte Rechnungsstellung.

Validierung:
  • Die XML-Datei muss gemäß dem Schema gültig sein. Validierungswerkzeuge, wie die vom DIN (Deutsches Institut für Normung) bereitgestellten, können die Konformität überprüfen.
  • Das Schema stellt sicher, dass Pflichtfelder vorhanden sind und optionale Felder korrekt formatiert sind.

Anwendung:
  • Das XML-Schema ermöglicht die Integration maschinenlesbarer Rechnungen in PDF/A-3-Dokumente, wodurch menschenlesbare und strukturierte Datenformate kombiniert werden.
  • Es unterstützt Profile wie BASIC, COMFORT und EXTENDED, die sich an verschiedene Anforderungen und Komplexitäten der Rechnungsstellung anpassen.
Weitere technische Details oder Zugriff auf die Schema-Dateien finden sich auf Plattformen wie ferd-net.de oder GitHub, wo auch ZUGFeRD-Schemata gepflegt werden.

Was ist mit den Pflichtangaben in einer elektronischen Rechnung?

Nur weil die Rechnung nicht mehr in traditioneller Papierform vorliegt, heißt das nicht, dass man von den Vorgaben für eine ordnungsgemäße Rechnung gemäß § 14 UStG befreit ist. Pflichtangaben in einer Rechnung wie Geschäftsführung, Handelsregistereintrag, Rechtsform und Sitz des Unternehmens sind auch bei elektronischen Rechnungen zwingend anzugeben. Seitdem die XRechnung beziehungsweise die maschinenlesbare E-Rechnung das maßgebliche Dokument ist und Pflichtangaben wie Geschäftsführer, Rechtsform etc. früher oft nur in der visuellen PDF-Darstellung "mit abgedruckt" wurden, muss sichergestellt werden, dass diese Pflichtangaben nun auch im strukturierten XML-Teil der XRechnung enthalten sind. Nur so ist gewährleistet, dass alle gesetzlichen Anforderungen auch bei der elektronischen Rechnungsstellung erfüllt werden.

Abgrenzung zwischen Dokument, Position und Posten - in Rechnungen

Um das semantische Datenmodell einer elektronischen Rechnung zu verstehen, ist es wichtig, die Begriffe "Dokument", "Position" und "Posten" klar zu unterscheiden.
Die oberste Ebene bildet das Dokument, das alle Positionen einer Rechnung umfasst. Jede dieser Positionen enthält genau einen Posten, der die Grundlage für die Abrechnung darstellt. Die Summe aller Positionsbeträge (unter Berücksichtigung eventueller Nachlässe und Abgaben auf Dokumentenebene) ergibt den Rechnungsendbetrag.
Der Posten stellt die feinste Ebene einer Rechnung dar. Er entspricht bei Warenlieferungen einem einzelnen Artikel, beispielsweise einer Flasche oder einem Liter. Der Einzelpreis eines Postens, gegebenenfalls reduziert durch Rabatte, basiert auf einer bestimmten Grundmenge oder Verpackungseinheit. Diese Grundmenge, z.B. eine Flasche oder ein Stück, bildet die Basis für Mengenangaben.
Die nächste Ebene ist die Position, die eine bestimmte Menge eines Postens beschreibt. So könnte ein Posten beispielsweise eine Flasche sein, während eine Position 100 Flaschen umfassen kann. Der Betrag einer Position errechnet sich durch die Multiplikation des Einzelpreises des Postens mit der angegebenen Menge, unter Berücksichtigung möglicher Rabatte oder Abgaben auf Positionsebene. Idealerweise stimmen die Maßeinheiten von Posten und Position überein, um Konsistenz zu gewährleisten.
In anderen Zusammenhängen werden Positionen häufig als Rechnungszeilen bezeichnet. Dieser Begriff wird auch in der EN 16931 verwendet, wo er als Invoice Line (BG-25 INVOICE LINE) definiert ist.

Wöfür steht das Feld "BuyerReference" in einer E-Rechnung?

In einer Factur-X- oder ZUGFeRD-Rechnung enthält das Feld „Käuferreferenz“-Feld ("Buyer Reference" in den XML-Daten) typischerweise eine vom Käufer angegebene Referenz, die die eindeutige Zuordnung (Identifizierung) einer Rechnung in seinen internen Systemen erleichtert. Dies kann eine Bestellnummer, ein Projektcode oder eine andere Kennung sein, die der Käufer zur Verfolgung (Tracking) oder Bearbeitung von (seinen) Rechnungen verwendet. Das wird gemacht, um eben Rechnungen einer Transaktion oder Vereinbarung auf Käuferseite zuzuordnen. In Geschäftsbriefen wird das auch gerne mit "Ihr Zeichen" bezeichnet.
Ob dieses Datenfeld jedoch immer nur von Kundenseite aus genutzt wird, ist nicht immer ganz klar. So kann es sein, dass der Aussteller einer Rechnung - obwohl dieses Datenfeld eigentlich vom Kunden gefüllt wird - vom Verkäufer schon vorausgefüllt bzw. benutzt wird. So ist es durchaus üblich, dass z.B. ein Onlineshop als Verkäufer das Feld „Käuferreferenz“ für die Bestellnummer/ Warenkorbnummer des Käufers verwendet. Das kann sinnvoll sein, wenn Rechnungsnummern von den IDs eines Einkauf-Vorgangs abeichen. Ob Sie also dieses Feld mit vom Kunden erhaltenen Daten füllen - oder umkekehrt dem Kunden eine von ihnen generierte Nummer/ID vorgeben hängt von Ihren Prozessen ab.

Was sind "unitCodes" in einer E-Rechnung?

In den XML-Daten von ZUGFeRD-Rechnungen finden sich die "unitCode"-Attribute in den Positionen der Rechnungsposten ("line items"). Sie geben die Maßeinheit der Menge an, die für Waren oder Dienstleistungen berechnet wird. Diese Codes basieren auf der internationalen "UN/ECE-Empfehlung Nr. 20", die standardisierte Maßeinheiten definiert und so Klarheit und Konsistenz im internationalen Handel gewährleistet - insbesondere im internationalen Handel, wo unterschiedliche Sprachen und Messsysteme Missverständnisse verursachen könnten. Beispiele für unitCodes sind:
  • H87: Bedeutet "Stück" oder "Einheit" und dient zur Zählung einzelner Artikel die konkret einzelne Stücke sind und gut gezählt werden können.
  • C62: Steht für generischere "Einheiten" und wird verwendet, um Artikel oder Stücke zu zählen (English "unit"), die ihrerseits nicht zwingend einen einzelnen Artikel, sondern auch ein Bündel oder eine aggregierte Einheit repräsentieren könnten.
  • KGM: Steht für "Kilogramm" und gibt das Gewicht an.
  • LTR: Bezeichnet "Liter" und wird für Flüssigkeitsmengen verwendet.
  • MTR: Steht für "Meter" und wird verwendet, um Längen anzugeben.
  • HUR: Steht für "Stunde" und wird verwendet, um Zeit in Stunden anzugeben.
  • DAY: Bedeutet "Tag" und wird für zeitbasierte Dienstleistungen genutzt.

Welches Datums-Format kann ich verwenden?

Die Vorgaben für eine E-Rechnung sind recht strikt in der Art, wie ein Datum in den Rechnungsdaten angegeben werden muss. Neben der eigentlichen Zeichenkette wird daher auch immer vermerkt, in welchem spezifischen Format das Datum vorliegt. Geläufig in den XML-Daten einer Factur-X / ZUGFeRD Rechnung ist das Format "DateTimeString" format="102", welches schlicht eine Aneinanderkettung von Jahr, Monat und Tag ist, also z.B. "20280714" für den "14. July 2028".
Damit wir in unseren Web-Apps ein eingegebenes Datum richtig erkennen und für die strukturierte Darstellung aufbereiten können, versucht der Programmcode geläufige deutsche Datumsformate zu erkennen. Derzeit sind das diese Schreibweisen:
  • "22. April '26" (mit abgekürztem Jahr)
    "2. April '26"
    "02. April '26"
  • "4. Apr. 2027" (mit abgekürztem Monat)
    "04. Apr. 2025"
  • "4. Jun. '28" (mit abgekürztem Monat und Jahr)
    "08. Aug. 2028"
  • "4. 12. 2029" (mit Punkten, gem. DIN 1355-1)
    08.01.2029"
  • "20250404" (Format "102", auch bekannt als "ISO 8601" ohne Trenner)
  • "2025-04-04" (JJJ-MM-TT, "ISO 8601" mit Trenner bzw. DIN EN 28601)

Was ist der Unterscheid zwischen BilledQuantity und BasisQuantity in einer Rechnungsposition?

In Rechnungen sind der "Preis pro Stück" nicht immer zwingend auf die Stückzahle "1" abgestellt. Der Preis eines Produkts kann sich auch durchaus auf einen Teiler beziehen. Diese sog. BasisQuantity nun definiert den Einheitenbezug für den Preis. Wenn BasisQuantity = 1 ist, wird wie gewohnt der Nettopreis pro Einheit angegeben. Die BilledQuantity aber bezieht sich auf die tatsächliche Anzahl der in Rechnung gestellten Einheiten, also z.B. 100 Stück von Produkt A, dessen Grundpreis hier aber der Einfachheit halber mit dem Teiler (BasisQuantity) "1" angegeben ist, also z.B. 8,00EURO pro Stück, ergibt 100 * 8 = 800 EUR netto.

Welche Arten von XRechnungen gibt es?

Wie auch bei traditionell geschriebenen Rechnungen, so gibt es auch bei XML E-Rechnungen wie ZUGFeRD verschiedene Typen von Dokumenten, etwa Gutschriften, Rückerstattungen oder eben normale Rechnungen. In einer Factur-X-XML-Datei gibt das Element "ram:TypeCode" am Anfang des XML-Dokuments den Typ des ausgetauschten Dokuments an. Der Wert "380" z.B. ist ein standardisierter Code, der eine "Rechnung" bezeichnet. Dieser Code stammt aus der UN/CEFACT-Empfehlung Nr. 20, die Dokumenttypen-Codes für den elektronischen Datenaustausch (EDI) definiert. Weiteer Beispiele sind:
  • 380: Typ "Handelsrechnung" (wird für die Abrechnung von Waren oder Dienstleistungen verwendet).
  • 381: Gutschrift (wird für Anpassungen oder Rückerstattungen verwendet).
  • 383: Lastschrift (wird für zusätzliche Gebühren verwendet).

Welche Zahlungscodes gibt es in E-Rechnungen (TypeCode)?

Wie auch bei traditionell geschriebenen Rechnungen, so gibt es auch bei XML E-Rechnungen wie ZUGFeRD verschiedene Typen von Zahlungsarten. Und während in traditionellen Rechnungen meist gröber angegeben ist, wie und wo der Verkäufer die Zahlung erwartet, so werden in elektronischen Rechnungen die erwartete Zahlmethode mit einem Code genau kodiert. Dieser Code wird dann im "ram:SpecifiedTradeSettlementPaymentMeans" Element des XML-Dokuments als "ram:TypeCode" angegeben. Geläufige Codes sind hier:
  • 58: SEPA Credit Transfer (SEPA-Überweisung)
  • 59: SEPA Direct Debit (SEPA-Lastschrift)
  • 30: Credit Transfer (traditionelle Überweisung ohne SEPA)
  • 49: Direct Debit (Lastschrift)
Auch der mißverständliche Code 42 ("Payment to bank account") wird heute eher nicht mehr verwendet, da es eine ebenfalls veraltete Form der Überweisung mit Kontonummer und Leitcode meinte.