Heute möchte ich in Teil 5 meiner Artikelreihe zur elektronischen Rechnung (kurz eRechnung) auf die Lösung "Rechnung-Fertig" eingehen. Eine kleine, aber feine Lösung für kleine Freiberufler und Kleinunternehmen mit "lediglich ein paar Rechnungen pro Jahr". Es ist eine funktionierende Lösung, die ich bei mir inzwischen einsetze, und die mir auch validierbare ZUGFeRD-Rechnungen erzeugt.
Vorab einige Bemerkungen
Ich stehe zwar mit dem Entwickler von Rechnung-Fertig, Martin Pyka, in Kontakt und habe von ihm auch eine lizenzierte Version der Software für meine Tests bekommen. Es gibt aber keine geschäftliche Beziehung über den Ansatz hinau, dass ich die Software "pro bono" für ihn teste und dem Entwickler bereits eine Menge Verbesserungsvorschläge geliefert habe. Ich habe auch keine Vorteile, wenn jemand auf diese Lösung setzt.
Warum ich die Software hier im Blog vorstelle? Ich habe in den letzten Wochen eine Menge eRechnungs-Lösungen angesehen und teilweise getestet (vergleiche auch Lösungen zum Empfang und Erzeugen von ZUgFeRD-Rechnungen – Teil 2). Jede dieser Lösungen wird seine Berechtigung haben. Prämisse war für mich aber, dass ich keine Abo- und keine Cloud-Lösung haben wollte, die gewählte Software aber "schnell und einfach" einzusetzen wäre.
Bei manchem Ansatz stand ich vor der Situation "die Trauben sind mir zu sauer, sprach der Fuchs und lief weiter" – ich sah keine Chance, binnen Stunden zu einer funktionsfähigen Lösung zu kommen, die man testen könnte. Ich war Ende 2025 sogar kurz davor, "für die Steuer" mal schnell einige Hundert Euro für eine Lizenz auszugeben, um eine ZUGFeRD-fähige Lösung zu haben. Hat aus terminlichen Gründen nicht geklappt – und als ich Anfang Januar 2026 die Testversion bei mir installierte, kam die Ernüchterung. Das Programm lief so zäh in meiner Umgebung, dass ein Arbeiten keinen Spaß machte – auf einen Test habe ich verzichtet und die Software gleich wieder deinstalliert. Andere Software verlangte eine spezielle Java Runtime, und weitere Programme wollten ein spezielles .NET-Framework, was ich nicht installieren konnte bzw. wollte, so dass ich den Test abgebrochen habe, und so weiter.
Im Dezember 2025 und Januar 2026 habe ich dann Fakturama als Open Source-Lösung bei mir aufgesetzt, mich ca. zwei Tage eingearbeitet und war theoretisch arbeitsfähig (siehe OpenSource ZUGFeRD-Lösung Fakturama im Hands-on – Teil 3a). Alleine, ich bin am Punkt der Validierung von ZUGFeRD-Rechnungen gescheitert (siehe Meine Pleite mit ZUGFeRD-eRechnungen und der Validierung – Teil 4).
Das war dann der Punkt, wo ich mit PDF24 zwar eine Notlösung für Einzelrechnungen hatte, aber daran arbeiten wollte, mit den Fakturama-Entwicklern das Problem der Validierung zu lösen. Leider habe ich bis heute keine Antwort auf meine kurze Anfrage vom Januar 2026 bekommen (kann ich bei Open Source auch nicht erwarten, aber in diesem Kontext ist Fakturama für mich nicht produktiv einsetzbar).
Das war meine Situation, als Entwickler Martin Pyka mich zufällig kurz auf X kontaktierte und anmerkte "Ich habe da auch ein Programm Rechnung-Fertig, was ZUGFeRD kann". Ich habe dann die Testversion heruntergeladen und kurz ausprobiert. Das Programm überzeugte mich vom Fleck weg – binnen fünf Minuten war ich quasi "testfähig". Und die schnell generierte Testrechnung ließ sich auch validieren (war da für mich bereits so etwas wie ein "Elchtest", ob eine weitere Beschäftigung mit der Software lohnt).
In Meine Pleite mit ZUGFeRD-eRechnungen und der Validierung – Teil 4 hatte ich zwar skizziert, welche kleine Klippe in meiner speziellen Arbeitsumgebung mit Word 2000 lauert – und ich habe dem Entwickler bereits eine Reihe Änderungs- und Verbesserungsvorschläge für seine Software übermittelt. Aber das Programm funktioniert, läuft schnell, und passt perfekt für meine Anforderungen (weniger als 50 eRechnungen pro Jahr mit eigenen steuerlichen Buchungen für eine Einnahmen-Ausgaben-Überschussrechnungssoftware). Zudem ist der Entwickler fix – nachdem die eRechnungs-Validierung, mutmaßlich Anfang Februar 2026, geändert wurde, und eRechnungen nicht mehr valide waren, hatte ich binnen zwei Tagen eine Korrekturversion der Software, samt Hinweisen, was ich noch ändern muss, um keine Validierungswarnungen zu erhalten.
Rechnung-Fertig wird aber nicht für jeden passen. Wer in diesem Bereich eine Lösung sucht, kann sich die Software als Testversion für Windows ansehen und binnen fünf Minuten mit Testdaten experimentieren. Dann lässt sich fix entscheiden, ob man die Lizenz erwirbt oder doch etwas anderes sucht.
Kurzvorstellung Rechnung-Fertig
Entwickler Martin Pyka bietet seine Lösung Rechnung-Fertig auf der gleichnamigen Webseite an. Dort zeigt er einige Screenshots der Funktionen, sowie ein Video mit dem Konzept und beschreibt, und erläutert, für wen er seine Software als Option sieht.
Es handelt sich um eine mit dem Elektron-Framework entwickelte Lösung, die unter Windows läuft. Ich habe kurz unter Mint mit Wine getestet, da startet das Programm, ist aber wegen Anzeigeproblemen (Bedienelemente und Felder sind nicht beschriftet) nicht nutzbar – hier ist mittelfristig wohl eine Anpassung denkbar.
Auf der Webseite lässt sich die unter 180 MByte große ZIP-Archivdatei mit der Software herunterladen. Ohne Lizenzschlüssel läuft das Programm im Testmodus. Der Zeitraum für den Test der Software ist zeitlich nicht limitiert. In den erzeugten eRechnungen findet sich lediglich eine "Test"-Kennzeichnung (nach Eingabe des Lizenzschlüssels verschwindet diese Kennzeichnung). Die Lizenz ist für ~40 Euro einmalig für den gegenwärtigen Entwicklungszweig erhältlich. Das hat mir alles sehr gut gefallen.
"Installation" der Software
Die Software kommt ohne Installer für Windows, was ich persönlich genial finde. Einfach das ZIP-Archiv herunterladen, in einen lokalen Ordner auf einer Datenpartition entpacken und schon ist man arbeitsfähig. Entpackt belegt die Software unter 500 MByte auf dem Laufwerk. Folgender Screenshot zeigt die Ordnerstruktur des Programmverzeichnisses.
Nach dem Entpacken reicht es, einfach die Datei RechnungFertig.exe aufzurufen, und dann den Testdatensatz auszuwählen. Schon kann man seine erste eRechnung mit Microsoft Word oder LibreOffice erstellen.
Hinweise zur Ordnerstruktur
Der Programmordner weist im Root-Verzeichnis die Programmdatei RechnungFertig.exe sowie die SQLite-Datenbank database.sqlite auf. Bei Programm-Updates habe ich diese Datei einfach in den neu angelegten Programmordner kopiert und war bezüglich der Daten arbeitsfähig.
Im Unterordner resources findet sich eine PowerShell Scriptdatei convert.ps1, die für die Erkennung der installierten Office-Version (Microsoft Office oder LibreOffice) sowie für Generierung der eRechnungen gebraucht wird. Wegen meiner exotischen Umgebung lief das Programm bei der Office-Erkennung durch Word 2000 "in den Wald" und scheiterte mit einem Fehler beim Erzeugen von eRechnungen. Ich habe daher die Programmlogik in der .ps1-Datei angepasst – hier will der Entwickler möglicherweise noch nachsteuern. Zum Debugging bei Fehlern gibt es übrigens eine log-Datei, die mich immer schnell auf die Spur der Ursache gebracht hat.
Im Unterordner templates finden sich zwei Word-Vorlagedateien, die vom Entwickler für eRechnungen vorbereitet wurden. Ich habe eine dieser Vorlagedateien kopiert und die Kopie umbenannt. Anschließend lässt sich die Vorlagedatei in Microsoft Word oder im LibreOffice Writer öffnen und an eigene Wünsche anpassen. Obiger Screenshots zeigt das Rohdokument mit den benötigten Feldern als Platzhalter. Hier lassen sich statische Daten wie Telefonnummer, ggf. Angaben bei den Bankdaten etc. anpassen bzw. ergänzen und ggf. eigene Logos hinzufügen.
Die Stammdaten für den Rechnungssteller (Anschrift, E-Mail, Bankdaten, Steuernummern etc.) werden im Programm unter Meine Daten eingetragen. Der Programmpunkt Einstellungen ermöglicht weitere Vorgaben für Rechnungsnummern, Onboarding etc.
Sind Rechnungsvorlagen individualisiert im Unterordner templates gespeichert, müssen diese im Programmfenster über den Menüpunkt Vorlagen in der Anwendung "registriert" werden. Dabei wird die Vorlagedatei in der Datenbank eingetragen sowie unter einer internen Bezeichnung in den Unterordner uploads kopiert. In der Vorlagenliste lässt sich eine Vorlage als Favorit markieren und wird dann bei der Rechnungsstelle als Vorauswahl zugewiesen.
Weiterhin sind bei der Erstkonfigurierung die Stammdaten für Kunden sowie für Artikel (der Lieferungen) über entsprechende Menübefehle einzutragen.
Wissenswertes rund um die Anwendung
Zum Erstellen einer Rechnung reicht es, im Programmfenster den Punkt Neue Rechnung anzuwählen. Genial fand ich das in nachfolgendem Screenshot unter "Onboarding" sichtbare Kontrollkästchen Testrechnung (lässt sich in den Einstellungen per Option abwählen).
Über dieses Kontrollkästchen lassen sich Testrechnungen mit den Vorgabedaten oder eigenen Daten erzeugen, ohne dass bereits Rechnungsnummern, die vom Programm fortlaufend generiert werden, "verbrannt" werden.
Zum Testen reicht es, den mit dem Programm gelieferten Musterstammdatensatz auszuwählen. Einfach "M" im angewählten Feld Name des Käufers drücken und den Kunden auswählen. Obiger Screenshot zeigt den entsprechenden Formularausriss. Eigene Kundendaten werden in der linken Spalte über den Menüpunkt Kunden eingepflegt. Beschreibungen und Preise für Artikel lassen sich über den gleichnamigen Menüpunkt in den Stammdaten ablegen.
Sind alle Angaben für eine Rechnung getätigt, lässt sich am Formularende ggf. die gewünschte Vorlage (hier "Artikel Template") wählen. Optional besteht inzwischen auch die Möglichkeit, eine XRechnung beim Erstellen herunterladen zu lassen. Danach kann man über Schaltflächen entweder eine PDF-Vorschau oder direkt eine eRechnung im ZUGFeRD-Format generieren lassen.
Dieser Vorgang dauert einige Sekunden, wobei entweder Microsoft Word oder der LibreOffice Writer mit Hilfe der gewählten Vorlage beim ZUGFeRD-Format die benötigte PDF-Dokumentdatei (factur-x.xml enthalten) als eRechnung generieren. Dann bietet ein Dialogfeld die Möglichkeit, den Zielordner zum Speichern der eRechnung zu wählen.
Hier bleibt anzumerken, dass derzeit bei jedem Programmstart der Download-Ordner des Benutzerkontos vorgegeben wird. Der zuletzt gewählte Speicherort bleibt nur für die Dauer einer Sitzung erhalten.
In meinem Fall war ich, nachdem die Software lief, binnen 5 Minuten in der Lage, mit den Testdaten eines Testrechnung im ZUGFeRD-Format zu generieren und auf ecosio.com validieren zu lassen. Die endgültige Anpassung der Vorlage sowie das Einpflegen der Stammdaten hat dann noch ca. 2 Stunden (bis alle meine Fehler gefunden und ausgemerzt waren) gedauert.
Was mir beim Programm und dem Konzept gefallen hat? Nach den Vorarbeiten mit Fakturama empfand ich die Oberfläche von Rechnung-Fertig als sehr einfach und intuitiv gehalten – genau das, was ich persönlich gesucht habe. Die Integration der Vorlage, der automatische Test, ob Microsoft Office oder LibreOffice installiert ist etc. sollte auch Anwendern, die nicht IT-affin sind, entgegen kommen.
Von der ursprünglich von mir getesteten Version 1.4.1 zur nun vorliegenden Version 1.5.2 hat der Entwickler einige Verbesserungen und Erweiterungen vorgenommen. Weitere Verbesserungen und Ergänzungen sind geplant. Was mir sehr gefallen hat, war die schnelle Reaktion des Entwicklers, der auf meine Hinweise und Bug-Reports binnen Stunden reagierte und eine Korrektur liefert.
Wenn ich den Entwickler richtig verstanden habe, plant er, die Software auf Grund der Rückmeldungen einiger Kunden und meiner Wenigkeit weiter um zusätzliche Funktionen zu ergänzen. Seit der von mir ursprünglich getesteten Version 1.4.1 sind bereits verschiedene Rechnungstypen dazu gekommen und viele Komfortfunktionen implementiert worden.
Vorteil ist, dass es eine einfache und transparente On-premises-Lösung ist, die einmal gekauft wird und dann unter Windows läuft (also keine Cloud-Anbindung oder Abonnements benötigt). Wie oft ein Upgrade auf eine neue Hauptversion kostenpflichtig wird, und wie häufig solche Upgrades überhaupt erforderlich werden, wird man abwarten müssen bzw. liegt auch in der Entscheidung des Entwicklers. Irgendwo wird er seine Arbeit am Ende des Tages finanzieren müssen.
Einziger Nachteil, den ich sehe: Wenn der Entwickler ausfällt oder das Projekt einstellt, wird man auf Dauer, speziell nach technischen Änderungen an den eRechnungs-Profilen, mit einer bestehenden Programmversion nicht mehr weiterkommen. Aber dieses Risiko ist quasi bei jedem Anbieter gegeben.
Unter dem Strich wird jeder selbst prüfen müssen, ob der Funktionsumfang ausreicht und ob man mit der Software klar kommt. Ich selbst bin von diesem Projekt recht angetan und werde gespannt verfolgen, wie sich das Programm weiter entwickelt.
Parallel dazu unternehme ich noch einen Versuch, ob ich mit den Fakturama-Entwicklern auf eine validierbare eRechnungs-Lösung komme. Zudem hat ein Leser in diesem Kommentar die "Rechnungs-Druckerei" (Vertrieb durch Markt+Technik), stammt aber von Prodaro, im Zusammenhang mit SoftMaker erwähnt. Prodaro bietet auf seiner Webseite eine Testversion an, und ich habe von Markt+Technik inzwischen diese Teststellung erhalten (es gibt mehrere Programmversionen). Ich plane die Rechnungs-Druckerei in der Pro Plus-Version ebenfalls zu evaluieren und dann hier im Blog zu gegebener Zeit ggf. als Teil 6 zu veröffentlichen. Dann gibt es ggf. mehrere geeignete On-premises Lösungen außerhalb der Cloud-/Abo-Angebote. Vielleicht hilft es jemanden bei der Auswahl und Entscheidung weiter.
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
Rechnung-Fertig, eine Lösung für eRechnung (ZUGFeRD und XRechnung) – Teil 5
MVP: 2013 – 2016
Sehr schöne Erklärung für diese Software, die ich nicht hätte besser schreiben können, jedoch finde ich dieses neue Wort, eRechnung immer noch zu lang und mein Rechtschreibprogramm meldet erneut einen Fehler.
Zum Glück schreibe ich keine Rechnungen und ich zahle als Freischaffender Künstler nur eine Künstlersteuer.
Tip:
Das Wort eRechnung dem Rechtschreibprogramm hinzufügen, dann meckert es in Zukunft nicht mehr.
SQLite-Datenbank im Programmverzeichnis? Dann braucht der ausführende Benutzer Schreibrechte auf das Verzeichnis, nicht gut. Kann Stefan Kanthak mal bitte was dazu sagen?
Ich überlege neben der ZIP-Datei zum Download, von der ich – ähnlich wie Günter – ebenfalls Fan bin, eine Setup.exe anzubieten, über die ich dann User-Verzeichnisse für die userbezogenen Daten nutzen könnte. Würde auch das Updaten vereinfachen.
Ich könnte eine Vorlage für einen MSI-Installer auf Basis von "WiX" beisteuern. Bei Bedarf kann Günter sicher die Kontaktdaten weiterleiten.
AUTSCH: mit "ekeltron" verfrickeltes Zeux ist von Idioten für Idioten — es ist NOCH übler als der Missbrauch einer "Java Runtime" oder einer "speziellen Version" des .NET Framework!
ekeltron, was soll das sein?
Die Diskussion sollten wir auslaufen lassen. Ich glaube, ich weiß, was Stefan Kanthak ausdrücken will und wo der Ursprungskommentar die Finger dran legt: Das Elektron-Framework, deren oft veraltete Chrome-Browser, sowie die Geschichte mit den Zugriffsrechten auf die Datenbank.
Ich plädiere für eine nüchterne Betrachtung des Ganzen. Ich weiß, warum der Entwickler auf das Elektron-Framework setzt (Plattform-Unabhängigkeit, könnte für die Linux-Schiene relevant sein). Das "veraltete Chrome-Browser-Thema" schätze ich im aktuellen Szenario als nicht relevant ein, da alles nur lokal läuft und bisher keine Webverbindungen genutzt werden. Bleibt noch das Datenbank-Zugriffsrechte-Thema. Wenn ich aber sehe, dass MS-Teams, Outlook New und Co. (wenn ich es nicht ganz verpeilt habe), im Nutzerprofil installiert werden, haben wir doch an ganz anderer Stelle die Probleme.
Unabhängig davon habe ich grob mit dem Entwickler diskutiert, dass er in Zukunft irgendwann einen Installer (neben der ZIP-Variante) anbietet, wo im Windows "Programs"-Ordner installiert wird und ggf. die Zugriffsrechte auf die SQLite-Datenbank beschränkt werden. Ist aber noch nicht Prio 1 – wenn ich es richtig sehe.
Abschließend: Habe gerade die Nacht noch einen Kurztest mit der "Rechnungs-Druckerei" (kommt von Prodaro) in einer VM gefahren. Da habe ich Java, wenn ich es richtig gesehen habe. Mit der Benutzerführung stehe ich persönlich bisher auf Kriegsfuß – deutlich komplexer als bei Rechnung Fertig (aber auch mit mehr Funktionen ausgestattet – eine andere Liga). Und meine in der Testversion generierte erste "ZUGFeRD"-Rechnung wurde mit dem Microsoft PDF-Druckertreiber generiert. Bin mir nicht so sicher, ob das überhaupt PDF/A-3 als Format unterstützt. Muss es in Ruhe anschauen, aber validieren ließ sich da mangels faktur-x.xml-Einbettung nichts.
Fazit am Ende des Tages: Ich kann mir viel wünschen – oft muss man sich aber nach der Decke strecken. Wenn ich mir anschaue, wie fix ich im Rechnung Fertig meine Dokument erstelle und wie gut die Software meiner persönlichen Denkrichtung entgegen kommt, wird diese wohl meine Wahl bleiben. Aber die Auswahl wird jeder selbst nach Anforderungsprofile und persönlichen Erfahrungen treffen müssen. Nur sehe ich es ziemlich nüchtern: Von 100 Anwendern wird maximal Einer die Wahl (sofern er eine hat) von irgendwelchen Software-Kriterien wie "JAVA, Elektron-Framework etc." abhängig machen. Selbst die Frage "muss es unter Linux, macOS, Windows laufen" interessiert die Masse nicht die Bohne. Die ist auch "bei Drei in der Cloud", wenn sie nicht aufgehalten wird. Aber möglicherweise täusche ich mich.
Das "ekeltron"-Framework ist PRINZIPIELL übel, nicht nur wegen des typischerweise veralteten Chrome: ES IST BLOATWARE!
Wer unter Windows Zeux nicht mit dem Win32-API frickeln kann, also UNFÄHIG ist, sollte NICHT frickeln, und vor allem seine Frickelei keinen "armen Schweinen" anpreisen oder geben, die solchen Schrott dann sogar ausführen.
JFTR: selbiges gilt auch für mit QT5 verbrochenen SCHROTT wie den OneDrive-Client.
Der PDF-Drucker erzeugt normales PDF, kein PDF/A.
Will man PDF/A3, dann geht das mit der aktuellen Word-Version 2024.
Ältere Word-Versionen, wie z.B. Word 2010 erzeugen PDF/A1.
Hallo, ich hab so ein Tool gebaut, wäre cool wenn sich das mal einer ansehen könnte ist komplett kostenlos. Und mir feedback unter info@frechnung.de geben könnte, das ist noch nicht komplett ausgereift, dass projekt, aber es wäre cool wenn mir einer sagen könnte was man noch ergänzen könnte und was noch wichtig wäre!
Für mehr infos gerne : frechnung.de besuchen
Warum baut eingentlich gerade jeder ein Rechnungstool? Es gibt so viele fertige Rechungsprogramm auf dem Markt, die alles können, was nötig ist. Alle diese neuen Mini-Projekte, die entweder per Vibecoding oder durch einen Einzelentwickler entstehen, der einfach mal denkt "Ich baue mal eben ein Rechnungsprogamm" machen einfach keinen Sinn:
Rechtliche & Compliance-Risiken
-Rechnungssoftware unterliegt strengen gesetzlichen Anforderungen, z.B.:
-GoBD (Grundsätze ordnungsmäßiger Buchführung) in Deutschland
-UStG (Umsatzsteuergesetz) – korrekte Steuerausweise
-E-Rechnungspflicht (XRechnung, ZUGFeRD)
-Aufbewahrungspflichten (10 Jahre, gibt es das Mini-Projekt dann noch?)
-Kundendaten, Bankverbindungen, Umsatzzahlen sind hochsensibel
-DSGVO-konforme Datenhaltung erfordert tiefes Fachwissen
Haftungsfragen
Fehler in Rechnungen (falsche Steuer, fehlende Pflichtangaben nach §14 UStG) können zu:
-Nachzahlungen und Bußgeldern führen
-Rechnungen die nicht zum Vorsteuerabzug berechtigen
-Im schlimmsten Fall strafrechtliche Relevanz haben
Für Rechnungssoftware gilt: Etablierte Lösungen, sind nicht nur bequemer – sie sind im unternehmerischen Kontext faktisch Pflicht, weil sie kontinuierlich rechtlich aktualisiert werden und im Zweifelsfall nachweislich compliant sind.
Peter: Nach deiner Lesart dürfte es genau einen "Trabbi" unter den eRechnungs-Programmen geben. Ich habe mich in den letzten 2 Jahren immer wieder mal mit dem Thema befasst. Und es gibt ja auch eine Menge Kommentare hier im Blog.
Im Sinne deiner Auflistung: Ich habe eine Reihe dieser Lösungen als nicht praktikabel verworfen. Andere passen schlicht nicht. Ich könnte meine Schuhe mit dem fünfjährigen Enkel tauschen. Ihm wären meine Schuhe definitiv zu groß, mir wären seine Schuhe definitiv zu klein. Sprich: Um meine max. 50 Dienstleistungsrechnungen pro Jahr zu stellen, brauche ich schlicht kein ERP-System für 50 Euro pro Monat und Arbeitsplatz, sondern etwas, was die bisherige Rechnungen ZUGFeRD-validierbar macht.
GoBD hängt nicht von der Software ab, sondern von Verfahrensregeln (Nachvollziehbarkeit, nicht änderbar etc.). Gleiches gilt für Aufbewahrungspflichten, DSGVO & Co. Aus dieser Sichtweise ist der Kommentar a bisserl typisch deutsch: Ich greife zu einer "etablierten" Lösung, da wird es schon passen. Ob es einen der zig Cloud-Anbieter, ERP-Anbieter etc. in 10 Jahren noch gibt, wird die Zukunft zeigen. Das Handwerkszeug ist keine Garantie, dass der Handwerker seinen Job ordentlich macht. Mit Handwerker meine ich die Leute, die für die Rechnungserstellung und -verwaltung zuständig sind. Aber mag man anders sehen – und ein Betrieb mit 100 Mitarbeitern und Bilanzpflicht ist sicherlich anders als ein Kleinunternehmer mit 5.000 Euro Jahresumsatz zu betrachten. Just my 2 Cent.
Du sagst "GoBD hängt nicht von der Software ab, sondern von Verfahrensregeln (Nachvollziehbarkeit, nicht änderbar etc.)"
Ja zum Teil von den Verfahrensregeln, zum Teil aber auch von der Software selbst. Die Originalrechnung in der Software darf nach dem Festschreiben nicht änderbar sein. Festschreiben ist Pflicht. Werden z.B. die eigenen Firmendaten geändert, müssen diese versioniert in der Software abgelegt werden. Usw. Ich war 30 Jahre in dem Bereich als Consultant tätig und kann nur den Kopf schütteln, was für Lösungen da jetzt schnell zusammengebastelt werden. Die Entwickler scheinen sich auch keine Gedanke um Haftungsriken zu machen, wenn man mal so in das Impressum schaut. Es reicht wenn, da nur mal ein Kunde mit einem Anwaltsteam kommt. Bei grober Fahrlässgikeit hilft dann auch keine Versicherung mehr. Und nein, es darf nicht genau "ein" Trabbi geben. Es gibt mehrere etablierte Lösungen, mindestens 10 würden mir einfallen.
Wäre da ja gespannt auf die mindestens 10 etablierten Lösungen. Ich bin da ja immer neugierig und habe mir mit großem Interesse die Zusammenstellungen der IHKs angesehen. Da war schon sehr viel Spreu vom Weizen zu trennen – und wer On-Premises als Kauflösung – möglichst für Linux, macOS und Windows – sucht, da wird es schon eng.
Wie bereits erwähnt: Es kommt immer auf den Einzelfall an – sozusagen Kirche im Dorf lassen. Eine 100 Mann-Firma mit 10 Millionen Umsatz wird man anders bewerten müssen als ein kleiner Freiberufler mit Kleinunternehmerregelung und 5.000 Euro Umsatz pro Jahr. Die hier diskutierten Lösung sind definitiv für den Bereich der Kleinunternehmen und umsetzbar. Mir möge auch niemand erzählen, dass Firma A mit einer Horde Anwälte aufkreuzt, wenn bei einer Außenprüfung eine 250 Euro-Rechnung (gerade an der eRechnungsgrenze) bemängelt wird. Also nochmals: Ich plädiere für Augenmaß – die Entscheidung trifft eh jeder Geschäftsführer oder Einzelunternehmer.
Will man die GoDB wirklich komplett umsetzen, dann ist man mehr nur Dokumentation beschäftigt als mit Arbeiten.
Beispielsweise wenn man eine Papierrechnung scannt, muss man dokumentieren, mit welchem Gerät (Hersteller, Typ, FW-Version) die Rechnung gescannt wurde.
Erzeugt man eine Rechnung mit einer Software, muss man dokumentieren, mit welcher Software die Rechnung erstellt wurde und auch mit welcher Version der Software.
etc. etc.
Macht man die Verfahrensdokumentation das richtig und vollständig, kommt pro Rechnung (egal ob Eingangs- oder Ausgangsrechnung) noch mindestens 1 DIN A4-Seite Dokumentation dazu!
Das macht in der Praxis niemand!
Und die Praxis sieht auch ganz anders aus.
Hier Erfahrung aus den letzten Steuerprüfungen im Haus:
Steuerprüfer vom Finanzamt will die Original Papierrechnungen von Lieferanten nicht sehen, sondern man soll ihm die einscannen.
Ansonsten schaut der nur, was in der Finanzbuchhaltung verbucht wurde.
In die Scans schaut er nur stichprobenweise rein.
Die ganze Verfahrensdokumentation etc. hat den noch nie interessiert. Was auch verständlich ist, denn wenn er die durcharbeiten würde, würde die Steuerprüfung doppelt so lange dauern. Das macht kein Steuerprüfer.
Danke, lieber Günther für den praxisnahen ud erhellenden Bericht. Dein Leidensweg ist nachvollziehbar.
Für kleine Betriebe ist „schnell arbeitsfähig + valide Ausgabe" aus meiner Sicht genau der richtige Fokus.
Was sich bei uns bewährt hat: Erzeugung und Prüfung trennen. Also Rechnung im Favoriten-Tool erstellen und vor dem Versand einen zweiten, unabhängigen Check laufen lassen (PDF/A-3, eingebettete XML, EN16931-Pflichtfelder wie Lieferdatum/Leistungszeitraum, leere XML-Elemente).
Als Gegencheck nutze ich Canary: https://canary.zappmedia.io/canary/
und für den geführten Aufbau: https://canary.zappmedia.io/canary/facturx-assistant.php
Keine Konkurrenz zur Erstellung, eher ein zusätzliches Sicherheitsnetz vor dem Versand. Wie wir getestet haben, ist die Seite sogar DSGVO-konform – ohne Speicherung irgendwelcher Daten.
Ich könnte noch folgende Software empfehlen:
https://einfach-xrechnung.de/produkte/
Die gibt es sowohl als Desktop und auch als Cloud-Version.
Der Hersteller reagierte positiv auf unsere Verbesserungsvorschläge.
Wir sind von Lexware dahin gewechselt, weil bei Lexware notwendige Felder für Rechnungen nach Luxemburg gefehlt haben.