Was ist eine E-Rechnung? Eine Einführung in verständlicher Sprache
Ein Finanzteam kann eine Rechnung als PDF, als gescanntes Bild oder als in eine E-Mail eingefügten Text versenden und den Vorgang mit gutem Recht „elektronisch“ nennen. Nach EU-Recht gilt nichts davon als E-Rechnung.
Der Unterschied ist nicht kosmetischer Natur: Er entscheidet darüber, ob ein Unternehmen seine E-Rechnungs-Pflichten in Deutschland, Italien, Spanien und allen anderen EU-Märkten erfüllt, die verbindliche Vorgaben für strukturierte Rechnungen einführen – oder ob es weiterhin digitales Papier verschickt, das nur zufällig über das Internet statt über die Post reist.
Kurz gefasst
- Eine E-Rechnung ist eine Rechnung, die in einem strukturierten Datenformat ausgestellt, übermittelt und empfangen wird, das eine automatische, elektronische Verarbeitung ermöglicht – so definiert in der EU-Richtlinie 2014/55/EU.
- Ein PDF, eine gescannte Rechnung oder eine Rechnung im E-Mail-Text ist digital, aber keine davon ist strukturiert, und damit qualifiziert sich keine als E-Rechnung.
- EN 16931, die europäische Norm für die E-Rechnung, definiert diese Struktur und unterstützt zwei XML-Syntaxen: UBL und CII.
- Eine strukturierte E-Rechnung durchläuft Erstellung, Validierung, Netzwerkübertragung und automatische Verbuchung – ohne einen einzigen Schritt, in dem eine Person die Daten neu eintippt.
- Die E-Rechnung im B2G-Bereich ist EU-weit seit der Richtlinie 2014/55/EU verpflichtend, wobei die Mitgliedstaaten bis 2019 (Zentralregierung) und 2020 (nachgeordnete Ebenen) Zeit hatten, die Empfangsfähigkeit tatsächlich umzusetzen; die B2B-Pflichten werden Land für Land eingeführt, im Vorfeld der EU-weiten ViDA-Anforderung für den innergemeinschaftlichen Handel ab Juli 2030.
Was genau ist eine E-Rechnung?
Eine E-Rechnung ist eine Rechnung, die in einem strukturierten elektronischen Datenformat ausgestellt, übermittelt und empfangen wird, das ein Computersystem lesen und verarbeiten kann, ohne dass eine Person die Datei öffnet und die Daten erneut eingibt. Die rechtliche Definition stammt aus der Richtlinie 2014/55/EU: eine Rechnung, die in einem strukturierten Datenformat ausgestellt, übermittelt und empfangen wurde, das eine automatische und elektronische Verarbeitung ermöglicht.
Dieser letzte Halbsatz trägt die gesamte Definition. In einer strukturierten E-Rechnung liegen die Rechnungsnummer, die Kennungen von Käufer und Verkäufer, die Positionen und die Steuerbeträge allesamt in einem festen, maschinenlesbaren Schema vor. Ein Buchhaltungs- oder ERP-System importiert sie direkt in die Kreditorenbuchhaltung, ohne dass ein Mitarbeitender ein einziges Feld neu erfasst.
Was macht eine Rechnung strukturiert und nicht nur digital?
Eine strukturierte Rechnung trennt die Daten von ihrer Darstellung: Jedes Feld steht an einer definierten Position, die ein System lesen kann, statt als Text für einen Menschen aufbereitet zu sein.
Eine Papierrechnung bündelt drei Dinge, die die meisten Menschen nie getrennt betrachten: die Daten, ein visuelles Layout zum Lesen und ein physisches Objekt zur Übergabe. Das Papier zu scannen, als PDF zu exportieren oder in eine E-Mail einzufügen entfernt die physische Übergabe, lässt aber die beiden anderen Probleme bestehen – denn jemand muss das Layout weiterhin ansehen und die Zahlen in das nächste System eintippen.
Eine strukturierte E-Rechnung gibt die visuelle Ebene als maßgebliche Quelle vollständig auf. Eine für Menschen lesbare Darstellung kann weiterhin existieren, für alle, die sie ansehen möchten – so wie ZUGFeRD und Factur-X eine solche einbetten –, doch diese Darstellung ist ein Nebenprodukt. Die Rechnung sind die Daten.
Wie unterscheidet sich eine E-Rechnung von einem PDF oder einer gescannten Rechnung?
Eine PDF-Rechnung und eine echte E-Rechnung können denselben Geschäftsvorfall beschreiben und dennoch rechtlich unterschiedliche Dokumente sein – denn der Unterschied liegt darin, ob ein Computer oder ein Mensch das Lesen übernimmt.
| Rechnungsart | Datenformat | Erfordert manuelles Lesen | Maschinenlesbare Struktur | Erfüllt EU-Vorgaben zur E-Rechnung |
|---|---|---|---|---|
| Papierrechnung | Gedruckter Text | Ja | Nein | Nein |
| PDF- oder gescannte Rechnung | Digitales Bild oder unstrukturierter Text | Ja | Nein | Nein |
| Per E-Mail oder webbasiert versandte Rechnung (HTML) | Unstrukturierter digitaler Text | Ja | Nein | Nein |
| Strukturierte E-Rechnung (UBL- oder CII-XML) | Strukturiertes XML | Nein | Ja | Ja, sofern konform mit EN 16931 oder einem nationalen CIUS |
Der eInvoicing-Baustein der Europäischen Kommission stellt ausdrücklich klar, dass E-Rechnungen keine PDF- oder Word-Dateien, keine Rechnungsbilder, keine unstrukturierten HTML-Rechnungen und keine OCR-Ausgabe einer gescannten Papierrechnung sind – ganz gleich, wie digital der Zustellweg erscheinen mag.
Was bedeutet „ausgestellt, übermittelt und in strukturiertem Format empfangen“ eigentlich?
Die Definition der Richtlinie 2014/55/EU nennt drei getrennte Schritte, und eine Rechnung muss alle drei erfüllen, um zu zählen.
Ausgestellt in strukturiertem Format bedeutet, dass das System des Verkäufers die Rechnung direkt im geforderten Schema erzeugt – nicht als PDF, das anschließend konvertiert wird. Jedes Pflichtfeld – Rechnungsnummer, Ausstellungsdatum, Kennungen der Parteien, Positionen, Umsatzsteueraufschlüsselung – muss von dem Moment an vorhanden sein, in dem das Dokument existiert.
Übermittelt in strukturiertem Format bedeutet, dass die Datei vom Verkäufer zum Käufer gelangt, ohne diese Struktur unterwegs zu verlieren. Eine strukturierte XML-Datei kann technisch als E-Mail-Anhang reisen, doch die meisten nationalen Vorgaben leiten sie über ein definiertes Netzwerk wie Peppol, damit die empfangende Seite die Nachricht validieren kann, bevor sie den Käufer erreicht.
Empfangen in strukturiertem Format bedeutet, dass das System des Käufers dieselben strukturierten Daten unversehrt aufnimmt, die der Verkäufer gesendet hat, und ohne Konvertierungsschritt damit arbeiten kann. Die europäische Norm zur E-Rechnung fasst dies als dreistufiges Konformitätsmodell: Das Rechnungsdokument selbst muss dem CORE-Modell oder einem nationalen CIUS folgen, das sendende System muss solche Rechnungen erstellen können und das empfangende System muss jede konforme Rechnung annehmen und verarbeiten, ohne gültige optionale Felder abzulehnen.
Strukturieren Sie die Rechnung korrekt und versenden Sie sie dann als PDF per E-Mail, oder senden Sie eine ordentliche XML-Datei, die das System des Käufers nicht einlesen kann, dann scheitert der Austausch an einem der drei Schritte – ganz gleich, wie digital er von außen wirkt.
Welche Formate verwenden strukturierte E-Rechnungen?
Die meisten strukturierten E-Rechnungen in Europa bauen auf EN 16931 auf, dem semantischen Datenmodell, das das Europäische Komitee für Normung (CEN) im Auftrag der Europäischen Kommission veröffentlicht hat. EN 16931 definiert, welche Informationen eine Rechnung enthalten muss – kein einzelnes Dateiformat; zwei Syntaxen tragen diese Daten.
| Syntax | Wurzelelement / Container | Typische Verwendung |
|---|---|---|
| UBL 2.1 | <Invoice> für Rechnungen, <CreditNote> für Gutschriften | Peppol BIS Billing 3.0 sowie mehrere weitere nationale CIUS-Profile in der EU |
| UN/CEFACT CII | Cross Industry Invoice XML | Die CII-Variante der deutschen XRechnung sowie das Hybridformat ZUGFeRD/Factur-X |
Ein Absender hat nicht immer die freie Wahl zwischen beiden. Im Peppol-Netzwerk ist UBL die verpflichtende Syntax für Peppol BIS Billing 3.0 – jeder Access Point muss sie unterstützen, wobei ein Empfänger sich optional registrieren kann, um zusätzlich CII anzunehmen. ZUGFeRD/Factur-X-Hybride lassen dagegen gar keine Wahl: CII ist die einzige Syntax, die das Format unterstützt. Nationale Behörden legen über einen CIUS eigene Regeln auf EN 16931: Die deutsche XRechnung, derzeit in Version 3.0.2, ist ein Beispiel, wobei für Ende 2026 eine Überarbeitung 4.0 erwartet wird, die sich an einer aktualisierten EN-16931-Norm ausrichtet – diese Versionsnummer sollte vor der Veröffentlichung also noch einmal geprüft werden. Italiens FatturaPA steht vollständig außerhalb dieses Systems, da sie älter ist als EN 16931 und weder UBL noch CII verwendet; sie ist das Format, das das Sistema di Interscambio für inländische Rechnungen vorschreibt – nicht das einzige Format, das das SDI akzeptiert, da grenzüberschreitende Lieferanten, die italienische öffentliche Stellen abrechnen, stattdessen ein EN-16931-konformes CIUS-IT-Profil verwenden können. Die E-INVOICE API von fiskaly erzeugt und validiert diese CIUS-Varianten über mehrere Märkte hinweg aus einer einzigen Integration, statt eine separate Format-Pipeline pro Land zu erfordern.
Die wichtigsten Erkenntnisse
- Eine E-Rechnung ist eine rechtliche Kategorie, kein Dateityp. Die Richtlinie 2014/55/EU definiert sie darüber, was mit den Daten geschieht (strukturiert, automatische Verarbeitung), nicht darüber, ob die Rechnung elektronisch eingetroffen ist.
- „Digital“ und „strukturiert“ sind unterschiedliche Eigenschaften. Ein PDF kann digital sein, ohne strukturiert zu sein, und nur strukturierte Rechnungen erfüllen die EU-Vorgaben zur E-Rechnung.
- EN 16931 ist die Norm hinter den meisten E-Rechnungen in der EU und unterstützt zwei XML-Syntaxen, UBL und CII, statt eines einzigen festen Dateiformats.
- Einige nationale Schemata stehen vollständig außerhalb von EN 16931. Italiens FatturaPA und Spaniens Facturae sind älter als die europäische Norm und verwenden weder UBL noch CII.
- Die Konformitätslatte hat drei Teile: Ausstellen, Übermitteln und Empfangen müssen alle in strukturiertem Format erfolgen, damit ein Austausch als echte E-Rechnung zählt.
Wie gelangt eine E-Rechnung vom Aussteller zum Empfänger?
- Das System des Verkäufers erzeugt die Rechnung in einem strukturierten Schema. Ein ERP, eine Buchhaltungsplattform oder eine Rechnungs-API befüllt die Pflichtfelder nach EN 16931 oder CIUS direkt, statt zunächst ein PDF zu erzeugen.
- Die Rechnung wird gegen die geltenden Geschäftsregeln validiert. Automatisierte Prüfungen bestätigen, dass Pflichtfelder vorhanden sind, Steuerberechnungen korrekt sind und verwendete Codes (Währung, Land, Umsatzsteuerkategorie) gültig sind, bevor das Dokument das System des Verkäufers verlässt.
- Die Rechnung wird über ein strukturiertes Netzwerk übermittelt. Viele EU-Märkte leiten dies über einen Peppol Access Point, der das Nachrichtenformat vor der Weiterleitung validiert; andere nutzen eine nationale Plattform wie Italiens Sistema di Interscambio.
- Das empfangende System validiert die eingehende Datei. Der Access Point oder die Plattform des Käufers prüft die Rechnung gegen dasselbe Schema und dieselben Geschäftsregeln, bevor sie angenommen wird.
- Die Rechnung wird automatisch in die Kreditorenbuchhaltung gebucht. Niemand tippt die Beträge, die Rechnungsnummer oder die Steueraufschlüsselung neu ein; die strukturierten Felder werden direkt in das Hauptbuch des Käufers übernommen.
Die Rechnung wird für die vorgeschriebene Aufbewahrungsfrist archiviert. Die meisten EU-Rechtsordnungen verlangen, dass steuerliche Dokumente mehrere Jahre in einer manipulationssicheren, prüfbaren Form aufbewahrt werden – oft über dedizierte Archivierungsinfrastruktur wie fiskaly SAFE, weshalb die Archivierung in der Regel parallel zur E-Rechnung läuft und nicht als nachträglicher Gedanke.
Jeden einzelnen dieser Schritte von Grund auf zu bauen – Schema-Erzeugung, Validierung, Netzwerkübertragung und Archivierung – ist für jedes Unternehmen ein erheblicher Entwicklungsaufwand, den es allein stemmen müsste. Eine E-Rechnungs-API-Integration wie fiskaly E-INVOICE fügt sich in ein bestehendes ERP-, Abrechnungs- oder Kassensystem ein und übernimmt Erzeugung, Validierung und Übermittlung direkt, statt zu verlangen, dass dieses System von Grund auf um die Anforderungen jedes Landes herum neu gebaut wird.
Warum verlangen Regierungen strukturierte E-Rechnungen?
Steuerbehörden wollen dasselbe wie Buchhaltungsabteilungen: Daten, die sie nicht neu erfassen müssen und automatisch prüfen können. Eine strukturierte Rechnung erlaubt es einer Steuerbehörde, Umsatzsteuerberechnungen zu validieren und Betrug nahezu in Echtzeit zu markieren – etwas, das ein PDF oder ein Papierweg in großem Maßstab weit schwieriger macht.
Diese Logik steht hinter der EU-Reform ViDA („VAT in the Digital Age“), die die strukturierte E-Rechnung ab Juli 2030 auf innergemeinschaftliche B2B-Transaktionen ausweitet. Einzelne Mitgliedstaaten sind diesem Zeitplan bereits voraus. Die deutsche B2B-E-Rechnungspflicht verpflichtet Unternehmen seit dem 1. Januar 2025 zum Empfang strukturierter E-Rechnungen, wobei die Versandpflichten für größere Unternehmen 2027 und für alle übrigen bis 2028 gestaffelt in Kraft treten. Italiens Sistema di Interscambio schreibt die elektronische Rechnung für B2G-Transaktionen seit 2014 vor, ausgeweitet auf inländische B2B- und B2C-Transaktionen ab Januar 2019. Spaniens Gesetz Crea y Crece führt eine parallele B2B-Pflicht ein: Große Unternehmen (Umsatz über 8 Mio. €) sollen voraussichtlich um Oktober 2027 starten und alle übrigen betroffenen Unternehmen bis Oktober 2028 – wobei Spaniens E-Rechnungs-Zeitpläne in der Vergangenheit immer wieder verschoben wurden, sodass diese Termine eher als Richtwerte denn als fix zu behandeln sind. Die länderspezifischen Fristen hinter diesen Vorgaben finden Sie in fiskalys Leitfaden zu Europas E-Rechnungs-Pflichten.
Wer sollte sich jetzt mit der E-Rechnung befassen?
Jedes Unternehmen, das eine öffentliche Einrichtung in der EU abrechnet, benötigt bereits jetzt die Fähigkeit zur strukturierten E-Rechnung: Die B2G-E-Rechnung ist EU-weit verpflichtend, seit die Richtlinie 2014/55/EU in Kraft trat, wobei die Mitgliedstaaten die Empfangsfähigkeit für die Zentralregierung bis 2019 und für nachgeordnete Ebenen bis 2020 bereitstellen mussten. Die B2B-Anforderungen ziehen Markt für Markt nach, und die Softwareanbieter, die diese Unternehmen bedienen – Kassensysteme, ERPs, Buchhaltungswerkzeuge –, sind diejenigen, die tatsächlich in der Pflicht stehen, die Fähigkeit zu bauen, da ihre Kunden erwarten, dass sie ab Werk funktioniert, statt auf eine separate Lösung verwiesen zu werden.
Fazit
Die Grenze zwischen „digital“ und „strukturiert“ ist das, was eine gescannte Rechnung von einer rechtskonformen E-Rechnung trennt. Ein PDF oder ein per E-Mail versandtes Bild verlangt weiterhin, dass eine Person die Daten liest und neu erfasst; eine strukturierte E-Rechnung – in einem definierten Schema ausgestellt, unversehrt übermittelt und in einer Form empfangen, mit der das System des Käufers direkt arbeiten kann – tut dies nicht. Einen Format-für-Format-Vergleich von UBL, XRechnung, FatturaPA und Facturae finden Sie in fiskalys Leitfaden zu E-Rechnungs-Formaten. Die länderspezifischen Fristen hinter diesen Vorgaben finden Sie in fiskalys Leitfaden zu Europas E-Rechnungs-Pflichten. Zum Erzeugen, Validieren und Übermitteln strukturierter E-Rechnungen über Märkte hinweg aus einer einzigen Integration siehe fiskaly E-INVOICE.