Meine Pleite mit ZUGFeRD-eRechnungen und der Validierung – Teil 4

eRechnund, ZUGFeRRSeit Anfang 2026 müssen Unternehmen elektronische Rechnungen (kurz eRechnung) annehmen können. Ich habe diesen Schritt auch für mich umgesetzt und in einer Artikelreihe von Teil 1 bis Teil 3b mit einer vermeintlichen Lösung beschrieben. Im Lauf der letzten Wochen bin ich dann aber mit der Validierung von eRechnungen im ZUGFeRD-Format auf den Bauch gefallen. Ich habe inzwischen zwar eine  funktionierende Lösung, möchte aber nachfolgend in Teil 5 skizzieren, wo es bei der Validierung von eRechnungen scheitert und zu welcher Notlösung ich dann gegriffen habe.

Kurzer Rückblick zum Thema eRechnung

Seit Anfang 2025 wird die elektronische Rechnung (kurz eRechnung) schrittweise verpflichtend eingeführt. Größere Unternehmen müssen bei Umsätzen zwischen inländischen Unternehmern regelmäßig eine elektronische Rechnung (E-Rechnung) erstellen. Für kleinere Unternehmen gelten Übergangsfristen.

Seit dem 1.1.2026 müssen Unternehmen elektronische Rechnungen entgegen nehmen können. Ab 2028 müssen dann alle Unternehmen eRechnungen für Unternehmenskunden ausstellen können. Ich hatte im Blog-Beitrag ZUGFeRD und XRechnung: Bestandsaufnahme und Überblick – Teil 1 die Details skizziert.

Spätestens 2028 trifft mich dann die eRechnungs-Pflicht auch, und ich hatte im Dezember 2025 damit begonnen, mich auf das Thema vorzubereiten, so dass ich ab dem 1.1.2026 sowohl eRechnungen empfangen als auch ausstellen kann. Welche Lösungen es grundsätzlich gibt, habe ich im Beitrag Lösungen zum Empfang und Erzeugen von ZUgFeRD-Rechnungen – Teil 2 angerissen.

Persönlich wollte ich keine Cloud-Lösung von einem Anbieter, sondern eine Software mit Perpetual Lizenz, die ich lokal unter Windows und ggf. Linux verwenden kann. Mit meinen vielleicht 50 Rechnungen pro Jahr sollte diese Lösung bezahlbar und einfach sein.

Nach vielen Tests hatte ich mich für die OpenSource-Lösung Fakturama entschieden und diese in den Beiträgen OpenSource ZUGFeRD-Lösung Fakturama im Hands-on – Teil 3a sowie OpenSource ZUGFeRD-Lösung Fakturama im Hands-on – Teil 3b etwas detaillierter vorgestellt.

Die Pleite mit der Validierung

eRechnungen können in den Formaten ZUGFeRD (PDF+XML-Teil) und XRechnung (nur XML-Teil) erstellt werden. Zur Verarbeitung dieser elektronischen Rechnungen muss der XML-Teil aber bestimmten Spezifikationen entsprechen und alle aus steuerlichen Gründen erforderlichen Angaben enthalten. Der Nachweis, dass eine eRechnung zu den vom Empfänger verwendeten Standards konform ist, erfolgt durch eine Validierung.

Im Blog-Beitrag Lösungen zum Empfang und Erzeugen von ZUGFeRD-Rechnungen – Teil 2 hatte ich die Ansätze skizziert, die ich zur Validierung der erzeugten ZUGFeRD-Rechnungen verwendet hatte. Am Ende des Tages war ich mit Fakturama in der Lage eRechnungen im ZUGFeRD-Format zu erstellen. Und diese wurden mit den von mir lokal zur Validierung verwendeten Programmen (Quba Viewer, Openindex ZUGFeRD Manager) akzeptiert.

Ein Kunde weist die eRechnung als ungültig ab

Ich fühlte mich also gut aufgestellt und dachte, dass das Thema vom Tisch sei. Die ersten eRechnungen gingen an Kunden raus und alles sah gut aus. Bis die erste Mail eintraf, dass meine eRechnung im ZUGFeRD-Format nicht valide sei und zurückgewiesen werde. Der Kunde verwendete eine Cloud-Lösung, in der alle eRechnungen eingespeist werden. Dort werden alle eRechnungen automatisch validiert und ggf. bei Fehlern zurückgewiesen.

Genau von dieser Lösung erhielt ich eine E-Mail mit dem Hinweis, dass die Annahme der ZUGFeRD-Datei wegen Fehlern verweigert werde. Da stand ich nun mit meiner Fakturama-Lösung.

Meine Validierungen akzeptieren die ZUGFeRD-Dateien

Ein schneller Test mit Quba Viewer und dem Openindex ZUGFeRD Manager wies meine eRechnung im ZUGFeRD-Format als valide an. Ich habe dann den XML-Teil factur-x.xml mit dem Quba Viewer aus der ZUGFeRD-Datei herausgelöst und im Validator-Portal von Baden-Württemberg prüfen lassen. Es wurden mir mehrere Warnungen, samt dem Hinweis, dass die Annahme der Rechnung empfohlen werde, angezeigt.

Mit Ecosio in den saure Apfel gebissen

Nach einiger Recherche war klar, dass ich meine eRechnungen auf der Plattform ecosio.com kostenlos validieren lassen kann. War zwar nicht meine Wunschlösung, da es ein Upload in die Cloud bedeutete. Aber für einige Validierungen von Testrechnungen sollte es reichen.

Auf der Seite lässt sich eine eRechnung im ZUGFeRD-Format hochladen und dann die Validierungsregel auswählen. Gesagt getan, und die beanstandete eRechnung im ZUGFeRD-Format prüfen lassen. In der Tat wurden von Ecosio Fehler in der XML-Struktur ausgewiesen.

Allerdings waren diese Fehlermeldungen für mich bereits äußerst kryptisch – ein normaler Anwender wird schon gar nichts mit anfangen können. Da stand ich nun, hart gegen die Wand gefahren. Also doch eine der Cloud-Abo-Lösungen verwenden?

PDF24 als Notnagel

Mir blieb nichts anderes übrig, mir dann auf die Schnelle eine E-Rechnung für den Kunden mittels der Cloud-Lösung PDF24 generieren zu lassen. Dazu wird die verlinkte Webseite aufgerufen, und man kann die Daten für die eRechnung anschließend in bereitstehende Felder eintippen (siehe folgende Abbildung).

Es gibt sogar Schaltflächen, um Rechnungen und Rechnungs-Teildaten in JSON-Dateien zu speichern und später wieder zu laden. Das Erstellen einer eRechnung im ZUGFeRD-Format ist kostenlos. Diese so von mir auf die Schnelle erstellte eRechnung im ZUGFeRD-Format wurde bei der Validierung auf ecosio.com als korrekt ausgewiesen.

Auf der Suche nach einer Lösung …

Als ich diese eRechnung dann beim Kunden einreichte, wurde diese akzeptiert. Ich hatte also eine Notlösung – komfortabel schreibt sich anders. Zudem störte mich der Umstand, dass ich mit PDF24 doch noch in der Cloud gelandet bin. Auch wenn der Anbieter schreibt, dass die generierte Rechnung samt hochgeladenen Daten nach dem Erstellen binnen Stunden gelöscht und nichts ausgewertet wird.

Mit Fakturama bisher gescheitert

Eine Recherche ergab, dass es bereits Ende 2024 Meldungen im Fakturama-Forum gab, dass die ZUGFeRD-Rechnungen nicht validierbar seinen. Ich hatte zwar vernommen, dass die ZUGFeRD-Geschichte in der Version 2.2 von Fakturama gelöst werden soll. Aber mein Test mit der Beta dieser Version war niederschmetternd. Die Validierung auf ecosio.com scheiterte.

Ich habe dann die Faturama-Enwickler direkt per Mail kontaktiert und auf das Problem hingewiesen. Auch nach gut drei Wochen habe ich keine Rückmeldung erhalten. Klar, es ist ein Open Source-Projekt, da kann man nicht erwarten, dass die Leute auf Mails reagieren. Aber am Ende des Tages hieß es für mich: Fakturama ist für mich in der vorliegenden Form unbrauchbar, wenn ich die Software auch vom Funktionsumfang für meine Zwecke als  geeignet ansah. Aber ich muss im Fall der Fälle halt eine validierbare eRechnung erzeugen können.

Glücksgriff mit Rechnung Fertig

An dieser Stelle fiel dann ein Puzzleteil ins Bild, denn auf X meldete sich Martin Pyka, der auf rechnungfertig.de eine Lösung zum Erstellen von eRechnungen anbietet.

Es handelt sich um eine per Electron-Framework implementierte Lösung für kleine Firmen oder Freiberufler, die unter Windows läuft. Martin Pyka bietet einen kostenlosen Download der Software an, so dass man ausführlich testen kann. In der Testversion werden alle generierten Rechnungen mit einer Markierung "Test" versehen.

Ich habe mir die ZIP-Archivdatei mit den Programmdateien heruntergeladen, und unter Windows in einen lokalen Ordner entpackt. Als ich die Programmdatei erstmals startete, war ich binnen einer Minute begeistert. Das Programm startete recht fix, wartete mit einer für mich intuitiven Oberfläche auf und bot sofort das Generieren einer ZUGFeRD-Rechnung mit Testdaten an.

Begeistert deshalb, weil ich seit Januar 2026 einige Lösungen getestet habe, diese oft binnen kurzer Zeit verwerfen musste, weil ich einfach kein Land sah, die Lösung irre kompliziert und/oder irre langsam war. Mit Fakturama habe ich knapp zwei Tage experimentiert, bis ich soweit war, dass ich eine (nicht validierbare) eRechnung erzeugen konnte.

Bei RechnungFertig hatte ich das Gefühl, dass ich binnen fünf Minuten zum Ziel gelangen könnte. Zwar fiel ich beim Generieren der Test-eRechnung mit den vorbereiteten Daten auf die Nase, weil es eine kryptische Fehlermeldung ab. Ich hatte aber gelesen, dass der Entwickler sowohl Microsoft Word als auch den LibreOffice Writer zur Generierung der PDF-Anteile der eRechnung unterstützt.

Anhang der Log-Dateien, auf die in der Fehlermeldung zur Analyse der Fehlerursache hingewiesen wurde, fand ich die Information, dass etwas mit der Generierung nicht stimmt. Mir kam schnell der Verdacht, dass es man meinem noch installierten Word 2000 hängen könne. Also den Office 2000-Programmordner umbenannt, und schon klappte die Erzeugung meiner ersten Testrechnung.

Die Validierung auf ecosio.com ergab auch grünes Licht für die Testrechnung. Die Lizenz für 40 Euro ist auch erschwinglich. Das war der Punkt, wo ich mit dem Entwickler Kontakt aufnahm, um das obige Word-Problem anzusprechen. Aktueller Stand ist, dass ich seit Anfang Februar mit Martin Pyka in Kontakt stehe, und das Programm teste. Ich habe eine Lizenz und bin mit RechnungFertig-1.4.1 gestartet. Inzwischen sind wir bei RechnungFertig-1.5.2, weil der Entwickler auf Grund meiner Hinweise einige Korrekturen und Ergänzungen vorgenommen hat.

Noch mal ein Rückschlag

Ich war endlich so weit, dass ich validierbare eRechnungen im ZUGFeRD-Format erstellen konnte. Mein Word 2000-Problem hatte ich auch entschärft, indem ich im PowerShell-Modul, welches der Entwickler zur Prüfung, ob Microsoft Office oder LibreOffice verfügbar ist, die Logik zur Programmauswahl entsprechend angepasst habe.

Als ich dann letzte Woche in der vom Entwickler bereitgestellten Programmversion 1.5.0 die erste Produktiv-Rechnung erstellen ließ, kam dann der nächste Rückschlag. Die Validierung auf ecosio.com scheiterte.  

Es gab plötzlich zwei oder drei Warnungen. Bei den alten, mit RechnungFertig 1.4.1 erstellten eRechnungen wurde sogar ein Validierungsfehler gemeldet. Es sieht mir so aus,  dass ecosio.com im Februar 2026 den Validierungsprozess überarbeitet hat. Nur so ist zu erklären, dass die alten, vor Wochen als valide bezeichneten ZUGFeRD-Rechnungen plötzlich abgewiesen wurden.

Lange Rede, kurzer Sinn: Ich stehe mit dem Entwickler im Austausch und habe die Probleme als Tester gemeldet. Der Entwickler wies bei einer Warnung darauf hin, dass diese auf Grund der fehlenden Empfänger-E-Mail-Adresse passiert. Beim Testen fand er noch weitere Fehler im Validierungsteil. Mit der mir nun vorliegenden RechnungFertig 1.5.2 bin ich erneut in der Lage, validierbare eRechnungen zu erstellen.

Ich plane in Teil 5 noch eine Vorstellung der Lösung "RechnungFertig", denn ich denke, das Programm ist für kleine Freiberufler mit wenigen Rechnungen schon eine geniale Lösung – und mit 40 Euro für die Lizenz auf jeden Fall einen Blick wert. Zudem kann jeder die Software im Demo-Modus unbegrenzt testen und schauen, ob es passt.

Artikelreihe
ZUGFeRD und XRechnung: Bestandsaufnahme und Überblick – Teil 1
Lösungen zum Empfang und Erzeugen von ZUgFeRD-Rechnungen – Teil 2
OpenSource ZUGFeRD-Lösung Fakturama im Hands-on – Teil 3a
OpenSource ZUGFeRD-Lösung Fakturama im Hands-on – Teil 3b
Meine Pleite mit ZUGFeRD-eRechnungen und der Validierung – Teil 4