Vor
einigen Wochen habe ich über meinen GitHub-Account eine
Java-Anwendung zur Erstellung einer einfachen Monats-e-Rechnung
verfügbar gemacht.
Ich
weise jedoch darauf hin, dass ich weder ein Steuerberater noch ein
Anwalt bin, und die von mir getroffenen Entscheidungen – so
nachvollziehbar sie auch sein mögen – sich als falsch
herausstellen könnten. Für Hinweise bin ich – schon im
Eigeninteresse – dankbar.
Was
also ist eine e-Rechnung?
Aus
Sicht eines Programmierers ist eine e-Rechnung nichts anderes als
eine XML-Datei in einem gesetzlich vorgeschriebenen Format, die also
solche oder in eine PDF-Datei eingebettet verschickt werden kann, und
nach dem Wachstumschancengesetz ab 2025 bzw. spätestens 2028 im
B2B-Geschäftsverkehr verwendet werden muss. Kurz gesagt: die
Papierrechnung ist tot – so gut wie...
Der
Grund ist eigentlich nachvollziehbar.
Stellen
Sie sich ein Unternehmen vor, das von seinen Lieferanten Hunderte
von Rechnungen im Monat erhält. Dieses Unternehmen hat mit
Sicherheit eine Software, die diese Rechnungen verwaltet und
rechtzeitig anweist.
Außerdem
hat das Unternehmen jemanden, der diese Rechnungen – egal, ob sie
auf Papier oder als PDF vorliegen – sichtet, die wichtigen Daten
heraussucht und in diese Software eingibt. Einfacher wäre es, wenn
die Daten bereits in einer computerlesbaren Form vorliegen würden –
und genau das ist eines der Ziele der e-Rechnung.
Bei
großen Firmen wird man das mit einem Update in der sowieso
vorhandenen Software lösen – bei Einzelkämpfern und kleinen
Unternehmen ohne eine solche Software wird es jedoch schwierig, diese
gesetzliche Anforderung umzusetzen.
Man
könnte auf die Idee kommen, diese XML-Datei (die im Grunde auch nur
eine Textdatei ist) von Hand zu erstellen. Das ist jedoch umständlich
und fehleranfällig, und irgendwie muss man das XML noch in die
PDF-Datei bekommen…
Das
heißt, man wird um irgendeine Software nicht herumkommen.
Für
die „nackte“ XML-Datei gilt die XRechnung-Spezifikation, für die
kombinierte PDF+XML-Variante ist es ZUGFeRD.
Eine
ZUGFeRD-Rechnung hat den Vorteil, dass man den
PDF-Teil mit einem
beliebigen PDF-Viewer anzeigen kann, für die XRechnung ist ein
spezieller Viewer notwendig.
Da
eine ZUGFeRD-Rechnung aus einem PDF-Teil und einen XML-Teil besteht,
existiert natürlich die Gefahr, dass die Daten, die ein Mensch im
PDF sehen kann, nicht denen entsprechen, die im XML kodiert sind.
Beim Erstellen ist man daher gesetzlich verpflichtet, dass die
Informationen in beiden identisch sind. Im Zweifelsfall gilt aber das
XML.
Im
Netz gibt es einige kostenlose Angebote zum Erzeugen dieser
PDF-Rechnungen – auch von namhaften Anbietern – bei denen man die
benötigten Daten in eine Maske einträgt und ein konformes PDF
erhält… natürlich direkt neben den kostenpflichtigen Angeboten,
mit denen das alles viel einfacher geht.
Auch
gibt es Open-Source-Fakturierungssoftware, die e-Rechnungen erstellen
kann, oder Makros für LibreOffice. Bei den meisten würde ich 90%
der Funktionalität nie brauchen und die Funktion, die ich brauche –
die Monatsrechnung – fehlt häufig.
Was
ist so besonderes an einer
Monatsrechnung?
Bei
den meisten
„einfachen“ Rechnungen bezieht
sich die
Rechnung nur auf
genau EINE
Bestellung. Wenn Sie z.B. in einem Webshop einkaufen, bekommen Sie
eine Rechnung für genau diese eine Bestellung. Diese
1:1-Beziehung
liegt
beim überwiegenden Teil aller Rechnungen vor.
Eine
Monatsrechnung fasst mehrere Bestellungen aus einem Monat in einer
Rechnung zusammen. Damit bezieht sich EINE Rechnung auf MEHRERE
Bestellungen.
Auch
dieser Fall ist in der ZUGFeRD-Spezifikation vorgesehen, nur leider
wird er meist nicht in der Software implementiert.
Was
braucht man für eine ZUGFeRD e-Rechnung?
Für
den PDF-Teil reicht die übliche Textverarbeitung wie LibreOffice
oder Word. Beide haben die Möglichkeit, den Text als PDF/A zu
speichern. Dabei stellt die „/A“-Variante („A“ wie Archiv)
sicher, dass das PDF auch später noch in der heutigen Form angezeigt
werden kann, u.a. dadurch, dass der benutzte Zeichensatz in das PDF
mit integriert wird.
Das
so erzeugte PDF allein wird aber künftig nicht mehr als Rechnung
ausreichen.
Den
fehlenden XML-Teil kann man mit dem o.g. Programm erzeugen. Es setzt
dabei auf die Mustang-Bibliothek.
Deren Vorteile:
Der
Nachteil:
Den
letzten Punkt habe ich dadurch gelöst, dass ich die fehlende
Funktionalität selbst programmiert und die XML-Datei entsprechend
der Spezifikation erweitert habe.
Mustang
verbindet dann die zuvor erzeugte PDF-Datei mit der neu erstellten
XML-Datei und erzeugt daraus
eine ZUGFeRD-Datei. Diese Datei wird dann von einem Validator
geprüft.
Der
Validator prüft die PDF-Datei, den Aufbau der XML-Datei und die
Abhängigkeit der Felder im
XML untereinander. Er
verwendet dabei Hunderte von Regeln. So
prüft er
beispielsweise,
dass Summen stimmen oder dass
ein bestimmtes Feld vorhanden ist,
wenn ein anderes Feld einen bestimmten Wert hat usw.
Er
verringert so die Gefahr, dass eine Rechnung vom Empfänger
zurückgewiesen wird, weil Fehler im XML vorhanden sind.
Eine
100%-ige Garantie ist das aber auch nicht. Es gibt mehrere
Validatoren und die sind sich nicht immer ganz einig. Außerdem
werden die Validatoren selbst auch weiterentwickelt und deren
Ergebnisse können dann in der nächsten Version bei der gleichen
PDF-Datei unterschiedlich ausfallen.
Simple Monats e-Rechnung (smer)
Mein
Programm steht als sog. „Fat-Jar“ zur Verfügung, das alle
Abhängigkeiten bereits mitbringt – vor allem die megabytegroßen
Validator-Dateien. Es setzt somit nur ein installiertes Java 17
voraus.
Aufgerufen
wird die Version
0.1.2 mit
java
-jar smer-0.1.2-all.jar name_der_pdf_datei.pdf
[name_des_rechungsdatei.yaml]
Wie
in der zugehörigen Dokumentation beschrieben, werden die Daten wie
Firmen- und Kundenanschriften, Warenliste und Steuerfälle in
YAML-Dateien gespeichert. Diese Daten ändern sich nach dem
anfänglichen Erstellen meist nicht mehr.
Der
„variable Teil“ sind die Daten
der eigentlichen
Rechnung. Auch
er wird in
einer YAML-Datei erwartet, deren Name man optional dem Aufruf
mitgeben kann.
YAML
ist ein Format, das man mit einem normalen Texteditor bearbeiten
kann und dessen Aufbau noch „menschenlesbar“ ist. Die Namen der
Felder sind so gewählt, dass sie selbsterklärend sind.
Wie
bei ähnlichen Angeboten im Internet werden auch hier die Daten dem
Programm auf einem
Silbertablett
präsentiert.
Es macht daraus eine XML-Datei, verbindet diese mit dem vorbereiteten
PDF und führt ein
Validierung durch.
Wie
oben erwähnt müssen Sie
sicherstellen, dass die Daten im PDF- und im XML-Teil identisch sind.
Das Programm gibt hierzu eine kurze Zusammenfassung der
im XML-Teil gespeicherten Zahlen aus.
Das
Programm reicht
in seiner jetzigen
Form aus, um
gelegentlich ein PDF zu einer Monatsrechnung
„aufzuwerten“.
Spätestens
dann, wenn man viele Rechnungen schreibt, wird jedoch der Wunsch nach
weiteren Funktionen kommen, wie beispielsweise
Solche
Erweiterungen sind aber für jeden Betrieb sehr spezifisch und daher
hier nicht implementiert. Das Programm ist aber so ausgelegt, dass es
sich leicht erweitern lässt.