feat: create validated ZUGFeRD invoices in one console command
This commit is contained in:
1 parent
e0c15fc7f2
commit
a643cf5227
30 files changed
+1509
-207
No files matched your search
@@ -0,0 +1,89 @@
|
||||
# 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.
|
||||
Reference in new issue
Block a user