# E-Rechnung 2027: Rechtsstand und Abgleich

Geprüft am 16.10.2026. Ziel dieses Projekts ist die Erstellung regulärer deutscher
B2B-Dienstleistungsrechnungen als validierte ZUGFeRD/Factur-X-Rechnung.

## Einordnung der INTEGRA-E-Mail

Die Umstellung ist relevant; ein gewöhnliches PDF erfüllt die Anforderungen an
strukturierte Rechnungsdaten nicht. Der Zeitplan lässt sich wie folgt einordnen:

| Zeitraum | Grundsätzlicher Stand für inländisches B2B |
| --- | --- |
| Seit 01.01.2025 | Empfang strukturierter E-Rechnungen ermöglichen; ein E-Mail-Postfach kann dafür genügen. |
| Bis 31.12.2026 | Übergangsregel für sonstige Ausgangsrechnungen. |
| Ab 01.01.2027 | Bei Vorjahresgesamtumsatz **über** 800.000 EUR endet die allgemeine Übergangsregel. |
| Bis 31.12.2027 | Bei Vorjahresgesamtumsatz **bis einschließlich** 800.000 EUR besteht die verlängerte Übergangsregel; außerdem gesonderte EDI-Übergangsregel. |
| Ab 01.01.2028 | Allgemeine Übergangsfristen beendet; gesetzliche Ausnahmen bleiben bestehen. |

Papier und sonstige elektronische Rechnungen sind bei der Zustimmung zu unterscheiden:
Die Empfängerzustimmung betrifft im Übergang sonstige elektronische Rechnungen
(etwa ein einfaches PDF), nicht generell Papier. Maßgeblich sind die gesetzlichen
Tatbestände und der Zeitpunkt des ausgeführten Umsatzes, nicht nur das Ausstellungsdatum.
Quelle: [§ 27 Abs. 38 UStG](https://www.gesetze-im-internet.de/ustg_1980/__27.html).

Die Umsatzgrenze ist keine Kleinunternehmergrenze. Sonderfälle wie Kleinbetragsrechnungen
bis 250 EUR, Fahrausweise, bestimmte steuerfreie Umsätze und die Ausnahme für
Kleinunternehmer sind getrennt zu beurteilen; B2G folgt zusätzlichen Vorgaben.
Den maßgeblichen Gesamtumsatz nach den gesetzlichen Verweisen mit der Steuerberatung
bestimmen, nicht aus der Summe der hier angelegten Rechnungen ableiten.
Quelle: [BMF-FAQ, Fragen 4 und 11](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html).

## Formate, Prüfung und Vorsteuer

ZUGFeRD ab 2.0.1 ist grundsätzlich geeignet, aber die Profile MINIMUM und BASIC-WL
reichen nicht aus. Dieses Projekt nutzt EN16931. Ein technischer Validierungslauf
ist sinnvoll und hier vor dem Versandentwurf verbindlich. Laut BMF ist Validierung
jedoch keine unmittelbare steuerliche Anerkennungsvoraussetzung; die pauschale
Aussage „zwingend technisch validieren, sonst kein Vorsteuerabzug“ greift daher zu
kurz. Leistung und Rechnungsinhalt müssen weiterhin geprüft werden.
Quelle: [BMF-FAQ, Frage 7](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html).

Bei Widersprüchen im hybriden Format sind die strukturierten Daten entscheidend.
Das Tool erzeugt Sichtkopie und XML deshalb aus derselben Datenquelle und Berechnung.
Aktuelle Formate und Validatoren entwickeln sich weiter: FeRD veröffentlicht inzwischen
ZUGFeRD 2.5.2. Eine ältere zulässige Version wird dadurch nicht automatisch unzulässig;
die tatsächlich verwendete Implementierung muss aber mit passenden Regeln und den
Empfängeranforderungen geprüft werden.
Quellen: [BMF-FAQ](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html),
[FeRD-Veröffentlichungen](https://www.ferd-net.de/downloads/veroeffentlichungen).

## Aufbewahrung

Rechnungen sind grundsätzlich acht Jahre aufzubewahren; Beginn und mögliche längere
Fristen sind gesondert zu beachten. Das strukturierte Original erhalten und nicht
nur ausdrucken. Quelle: [§ 14b UStG](https://www.gesetze-im-internet.de/ustg_1980/__14b.html).
Prüfbericht und versandte Datei gemeinsam aufzubewahren erleichtert den Nachweis.
Eine technische Prüfung ersetzt keine Vollständigkeits- und Richtigkeitskontrolle.
Quelle: [BMF-Schreiben vom 15.10.2025, insbesondere Rn. 35a und 60](https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Steuerarten/Umsatzsteuer/Umsatzsteuer-Anwendungserlass/2025-10-15-einfuehrung-obligatorische-e-rechnung.pdf?__blob=publicationFile&v=5).

## Ergebnis der Codeprüfung

| Anforderung | Vorher | Nach Überarbeitung |
| --- | --- | --- |
| Strukturierte Parteien, Positionen, Steuern | Fehlten im XML | In CII-EN16931 enthalten |
| Beträge in PDF/XML konsistent | Float-Berechnung | Gemeinsame Decimal-/Cent-Berechnung |
| Leistungszeitraum, Bestellung, Kundenreferenz | Fehlten | Optionale strukturierte Felder und PDF-Anzeige |
| PDF/A und eingebettetes XML | Keine PDF/A-Erzeugung sichergestellt | WeasyPrint-PDF/A, Mustang-Kombination und Prüfung |
| Validierungsergebnis | Nur Prozess-Exitcode | XML-Bericht einschließlich Teilergebnissen ausgewertet |
| Komfortable Erstellung | Allgemeines Init und manuelle Eingabe | Ein Aufruf mit beliebigem Kunden, Position, Menge, deutschem Nettopreis, automatischer Nummer und fertigem Anhang-PDF |
| Versandvorbereitung | Fehlte | Neuaufbau + Prüfung + EML mit hybridem PDF |
| Eingangsprüfung | Kein CLI-Befehl | Lokaler Prüfungsbefehl für XML/PDF |
| Revisionssichere Archivierung / DATEV / Peppol | Fehlten | Weiterhin externe Prozesse, keine vorgetäuschte Integration |

Vor dem ersten echten Versand: lokale Stammdaten bestätigen, freie Rechnungsnummer
wählen, vereinbarte Empfängeradresse und etwaige Bestellreferenz eintragen, Stunden
und Zeitraum prüfen, validiertes PDF sichten und den Mailentwurf absenden. Danach
Rechnung und Versandnachweis gesichert ablegen. Die Steuerberatung sollte die
betrieblichen Sonderfälle und den Aufbewahrungsprozess bestätigen.


## Ein-Aufruf-Bedienung ab Version 1.0

`einvoice --create` erzeugt das vollständige hybride PDF, validiert es und zeigt den
Anhang-Pfad an. Neue Kunden werden einmalig mit Anschrift angelegt, bestehende Kunden
über ihren Namen wiederverwendet. Es wird kein Kunde automatisch vorausgewählt;
IDV ist historischer Bestand. Die Erfolgsmeldung bestätigt die technischen Regeln
für PDF/A und EN16931. Ob Leistungsdaten, Steuersatz und Geschäftsvorfall richtig
sind, kann der Validator nicht eigenständig feststellen. Deshalb gibt die Konsole
keine pauschale Zusicherung „erfüllt alle gesetzlichen Vorgaben“ aus.