Hallo Julian,

könntest Du uns auch etwas genaueres zu der von Deinem StB behaupteten "Nichtkonformität" mitteilen?

Was soll der Grund sein?

Bei mir meckert zwar DATEV bei der Buchung, dass im Pflichtfeld BT-10 die GLN nicht enthalten ist, es heisst aber, dass man hier die USt.-ID des RG-Empfängers eintragen kann. Allerdings heisst es noch ergänzend, die RG (ZUGFeRD) sei dennoch steuerlich korrekt.

Ich bin gespannt....

Dank für weitere Details im Voraus.

VG

Richard

Abend zusammen,

also es ist im wesentlichen das Problem, dass man die Rechnungen Manipulieren kann oder änderungen vorgenommen werden können. So laut meinen Recheren. Der Steuerberater sagte mir das Fakturama nicht GoBD Zertifiziert ist aber es kann mir nicht sagen warum oder was fehlt, da das nicht in deren Aufgabenbereich fällt.

Ich hab also mal gegoogelt und folgende Punkte sollten fehlen:

1. Ein Audit-Log (zur lückenlosen Protokollierung aller Änderungen)

2. WORM-Speicher (Write Once Read Many – ein Speicher, der beschrieben, aber nachträglich nicht verändert oder gelöscht werden kann)

Ich glaube wenn diese beiden Punkte von mir oder dem Programm noch gewährleistet werden können dann geht das auch ohne Probleme.

Das Problem an sich ist halt, wenn ein Betriebsprüfungen vorbei kommt und fragt welches Rechnungsprogramm wir benutzen? Und es nicht GoBD Zertifiziert ist nimmt er den Laden auseinander. Und sollte er auch nur einen Fehler finden kann er wohl alle Rechnungen als nichtig erklären und dann hätte man ein RIESEN RIESEN Problem.

Wie machen das die Anderen denn hier? Über Infos würde ich mich wirklich Sehr Sehr freuen.

Schönen Abend allen.

Moin moin,

zum Thema "Laden auseinandernehmen": ich wäre hier entspannt. Die Rechnungen werden korrekt erstellt und sind entsprechend archiviert. Ja, es ist wahr, dass es nicht entsprechend zertifiziert ist, aber was besagt die Zertifizierung und wer stellt diese aus? Es ist genauso wahr, dass wenn man SAP oder Datev nutzt, deutlich weniger in der Nachweispflicht ist, da die Finanzämter hier "vertrauen", auch wenn die Algorithmen proprietär sind. Aber da es Brachenstandards sind, wird hier nicht gemeckert. Zum Thema "digitale Buchführung" kann Dir KEINE Behörde eine letztverbindliche Auskunft geben, da es viele Pflichten für Dich gibt, aber eben keine verbindliche Anleitung, wie diese umgesetzt werden sollen, Beispiel Thema "digitale Signatur" oder "ersetzender Scan". Im Zweifel bist Du hinterher immer der Dödel. Das würde ich aber nicht zum Anlass nehmen, nicht auf Fakturama zu setzen: damit die Rechnungen für nichtig erklärt werden, müsste ja erstmal ein Fehler in der Rechnung sein. Und den erhälst Du ja nur, wenn Du Dir wirklich Mühe gibst, zu manipulieren und dann bekommst Du zu Recht Ärger. Wenn Du wirklich mal einen Fehler hast, z. B. eine nicht rückholbare, aber nie rausgegangene REchnung, dann dokumentier das und mach ein Begleitschreiben bei der nächsten Steuererklärung, warum Rechnung Nr. XXX fehlt. Schlimm wird es nur, wenn es nicht nachvollziehbar ist und offensichtliche Fehler festgestellt werden. Solange man nach besten Wissen und Gewissen arbeitet, habe ich noch keinen Finanzbeamten erlebt, der einem wirklich böses will. Mag es geben, aber das ist wie bei einer allgemeinen Polizeikontrolle: wenn jemand pissig ist, dann kann man da wenig machen und die finden irgendetwas, wie absurd es auch sei, meist reicht aber einfach ein angemessener Umgangston, alles "normal" laufen zu lassen.

Ich nutze weiterhin Fakturama und weiß, dass viele Behörden deutlich hemdsärmeliger arbeiten, als wir mit Fakturama. (War mal auf einem Vortrag der Berliner Jusitzbehörde zum Thema "digitale Akte"). PDF ist nicht GoBD-Konform, auch wenn häufig etwas anderes behauptet wird. Viele Signaturen sind es nicht und die Hürden sinken eher, als dass auf einer qualifizierten Signatur bestanden wird. Die Gesetzgebung nimmt auch die Realität wahr: solange die Behörde nicht selbst abschließend einen "korrekten Ablauf" benennen kann, kann alles als falsch gelten, wenn es jemand so auslegen will. Deshalb muss keiner auf SAP umsteigen, auch wenn Gerichte deren Doku meist problemlos anerkennen.

Meine Meinung dazu...

Danke @finn_W für die ausführliche Antwort. Ich stimme dem voll zu. So richtig kann nämlich wirklich keiner sagen, was "GoBD-konform" denn nun wirklich konkret heißt. Es stimmt, daß man im Fakturama Rechnungen nach dem Drucken noch verändern kann. Das hat aber zumindest in den letzten 13 Jahren, in denen Fakturama am Markt ist, niemanden gestört. Wenn man unter "GoBD-konform" versteht, daß Rechnungen nicht mehr geändert werden können nach dem Drucken, dann kann man sie automatisch in dein DMS überführen, in dem sie revisionssicher aufbewahrt werden (dafür gibt es eine Lösung mit ecoDMS). Generell kannst du bei allen Offline-Programmen irgendwie mit genügend krimineller Energie an die Datenbank rankommen und die Rechnung ändern. Das geht natürlich bei Online-Lösungen nicht mehr so einfach, aber der Vorteil von Fakturama ist ja eben genau diese Form der Datenhaltung. 

Ich habe mir zu dem Thema auch schon paar Gedanken gemacht, bin aber noch zu keiner wirklich schlüssigen Lösung gekommen. Selbst ein Sperrkennzeichen läßt sich ja direkt in der Datenbank wieder zurückändern. 

Wenn hier jemand noch einen praktikablen Vorschlag hat, wie man das Problem lösen kann, dann bin ich gerne dafür offen. Aktuell habe ich aber noch andere Baustellen, die ich noch beackern muß (hier bei Fakturama). Übrigens ist das Thema hier im Forum auch schon ab und zu mal diskutiert worden, vielleicht kann man das ja als Diskussionsgrundlage mit verwenden.

Abend zusammen,

Ich habe mal mit einem Steuerberater gesprochen. Er meinte, ein Sperrkennzeichen sei zwar nicht die perfekte Lösung, würde aber schon einmal in die richtige Richtung gehen. Soweit ich weiß, geht es letztendlich nur darum, dass ein normaler Benutzer nichts mehr an einer Rechnung ändern kann.

Wenn man das Ganze einmal etwas größer betrachtet, kann man in jedem Programm irgendwie Änderungen vornehmen. Selbst bei Online-Programmen können mit den entsprechenden Kenntnissen ein Audit-Log oder die Datenbank manipuliert werden. Mit den richtigen Skills könnte man vermutlich sogar ein DMS anpassen. Das würde allerdings deutlich mehr Aufwand erfordern.

Ich glaube aber nicht, dass das der eigentliche Punkt ist. Es geht vielmehr darum, sich selbst abzusichern und nachweisen zu können, dass eine Rechnung nach ihrer Fertigstellung nicht mehr verändert werden kann.

Ich bin mir ziemlich sicher, dass bereits ein Sperrkennzeichen helfen würde. Man könnte das zusätzlich mit einem Hashwert (erstellt mit der Uhrzeit zu dem Zeitpunkt wo die Rechnung abgeschlossen worden ist unter der Nummer) absichern. Dann würde selbst dann, wenn jemand die Sperre wieder aufhebt, der Hashwert nicht mehr stimmen und eine Manipulation wäre erkennbar.

Wenn man das Ganze zusätzlich noch mit einem Audit-Log kombiniert, wäre das meiner Meinung nach bereits eine sehr gute Lösung.

Beispiel:

Rechnung: 2026-00123
Datum: 01.06.2026
Betrag: 119,00 €
Zeitstempel: 2026-06-01 10:15:33

Hash:
A7F3B2D9...

Später kann Fakturama dann prüfen:

Hash neu berechnen
=
gespeicherter Hash?

Wenn ja:

Rechnung unverändert.

Wenn nein:

Rechnung wurde nachträglich verändert.

Der Vorteil gegenüber einem reinen Sperrkennzeichen ist:

• Sperrkennzeichen verhindert Änderungen nur im Programm.
• Ein Hash erkennt Änderungen auch dann, wenn jemand direkt in der Datenbank herumspielt.

Hmmm ... jetzt ist schon die Frage, ob das Programm – hier Fakturama – mit dem die Rechnung erstellt wird, schon sicherstellen muss, dass die endgültige Rechnung nicht mehr verändert werden kann – es ist ja am Ende das PDF und die XML-Datei, die nicht mehr verändert werden darf, oder ob ich das erst bei der endgültigen Speicherung der Rechnung gewährleisten muss. Ich darf ja durchaus die Rechnung nach dem Drucken noch mal verändern, wenn mir auffällt, dass ich zum Beispiel den Steuersatz falsch gesetzt habe, oder ein falsches Leistungsdatum drin ist, oder halt irgendein anderer Fehler, den Menschen machen können. Und ich muss die durchaus auch noch einmal verändern, wenn zum Beispiel in der X-Rechnung die korrekten Maßeinheiten gefordert werden (Liter, Stück, Stunde), was Fakturama derzeit noch gar nicht abbilden kann.

Die Rechnung ist ja nach dem Drucken – also dem Erstellen der ODF, PDF und XML-Datei – noch nicht versandt oder in der Buchhaltung verbucht. Das passiert ja erst, wenn ich die Rechnung dann endgültig freigebe und dieses endgültige Dokument müsste dann unveränderbar sein. Ich müsste also auch in Fakturama dann noch eine Option haben, dass die Rechnung geprüft und endgültig freigeben wurde, bevor sie dann unveränderbar wird und für den Hashwert müsste dann ja die endgültige PDF-, XML-, und/oder ZugPferd-Datei herangezogen werden.

Für mich stellt sich dann auch die Frage, welche Daten du bei einer Betriebsprüfung zur Verfügung stellst. Gibst du die Datenbank von Fakturama weiter oder die XML- bzw. PDF-Dateien. Sind es die zuletzt genannten, dann musst du ja nachweisen, dass diese unverändert sind, so ein Hash-Wert in der Datenbank könnte da ein Ansatz sein, aber was machen dann Leute, die ihre Rechnungen zum Beispiel mit LibreOffice erstellen? Bei Kleinbetragsrechnungen bis 250,- Euro gibt es ja noch keine X-Rechnungspflicht, wären da die Rechnungen auch sofort komplett ungültig, wenn das Programm entscheidend ist, mit dem die Rechnungen erstellt werden? Und wer manipulieren möchte, könnte dann ja einfach die PDF-, XML-, oder ZugPferd-Datei verändern und verheimlichen, dass diese mit Fakturama erstellt wurden. 

Ich glaube, dass diese Funktion eher durch ein DMS abgebildet werden sollte und selbst das wäre manipulierbar, wenn genügend kriminelle Energie vorhanden ist. Und dann gibt es ja noch die Buchhaltungssoftware, die im Notfall die Belege in GoBD-Konformen Containern ablegen kann – MS Buchhalter kann das zum Beispiel – und dann wäre ja auch wieder egal, ob Fakturama das kann. Und wo ich die Buchhaltungssoftware erwähne, ist auch die Frage, ob Fakturama überhaupt GoBD konform sein muss, denn es ist kein Buchhaltungsprogramm. Es wird nichts verbucht, es sind keine Kontenpläne hinterlegt, es ist einfach nur ein Werkzeug, um relevante Dokumente für die Buchhaltung zu erstellen, die eigentliche Unveränderbarkeit muss doch aber erst für die Dokumente selbst gesichert sein und die könnte ich ja problemlos auch ohne Fakturama verändern. 

Ich vermute, der viel wichtigere Punkt ist, dass deine Buchhaltung am Ende auch plausibel ist. Wenn du die Dokumente selbst im Nachhinein veränderst, dann musst du ja auch die ganzen Buchungen in der Buchhaltung nachträglich verändern und ich glaube, hier wirst du sehr schnell an den Punkt kommen, wo die Plausibilität nicht mehr gegeben ist und dann wäre es auch richtig, dass dir dann deine gesamte Buchführung um die Ohren fliegt. 

Es gibt ja am Ende auch keine Pflicht, Rechnungen mit einem Tool wie Fakturama zu erstellen. Du könntest das Ganze ja auch manuell machen, also die XML-Datei mit einem XML-Editor und müsstest ja auch dann dafür sorgen, dass diese Datei unveränderbar ist. Ich glaube, dieser Punkt wäre erst dann sicher zu gewährleisten, wenn du deine Rechnungen über ein staatliches Portal versenden müssest, wo diese dann für dich unveränderbar wäre. Also zum Beispiel über das Elster-Portal des Finanzamtes. 

Meiner Meinung nach fliegt dir deine Buchhaltung also nicht um die Ohren, nur weil du Fakturama nutzt. Du musst halt am Ende sicherstellen, dass du die Grundsätze der ordnungsgemäßen Buchführung Digital so gut wie möglich umsetzt, aber das muss nicht durch ein einziges Programm abgebildet werden. Am Ende aber alles nur Vermutungen, keine Fakten und am Ende sind wir wohl alle erst schlauer, wenn die ersten Berichte zur Betriebsprüfung kommen. 

EDIT: Ich habe jetzt soviel rumeditiert, und hoffe, dass es lesbar ist und der Punkt, der mich bewegt, rüberkommt. 

Danke für den ausführlichen Beitrag. Ich glaube, das Thema wird uns noch eine Weile beschäftigen. Die Idee mit dem Hashwert hatte ich auch schon, das wäre zumindest ein erster Ansatz, um die Rechnung ein bißchen änderungssicherer zu machen. Die Funktion zum Festschreiben gibt es ja auch schon in anderen Programmen, das könnte man auch mit einbauen. Das ist halt bloß bislang nie ein Thema gewesen. Und vor allem - was mache ich denn, wenn nach dem Festschreiben auffällt, daß trotzdem noch was falsch war? Dann muß ich eine Korrekturrechnung erstellen? Irgendwie kann man das beliebig komplex gestalten, wie so vieles. Ich hatte auch schon die Idee, die Rechnungen über eine Blockchain abzusichern, aber das wäre dann vermutlich doch bißchen too much... 😀

@rheydenr aber am Ende bleibt doch die Frage, welche Dateien am Ende vor Änderungen geschützt werden müssen. Ist es der Eintrag in der Datenbank oder sind es die Dateien, die Fakturama am Ende als Dokumente ausgibt? Am Ende müssten doch genau die Dokumente vor Änderungen geschützt werden, also die XML-, PDF-, ZugPfert und ODF-Dateien. Die müsstest du in einen Container legen, wo sie nur noch lesbar wären und da würde ich dann Fragen, wie bekomme ich diese Dateien dann zum Buchhaltungsbüro, wenn ich das nicht selbst mache und wie versende ich die an die Kund*Innen? Ist nicht die grundlegende Frage: Muss Fakturama als Programm, womit die Dokumente erstellt werden – wobei die Dokumente ja dann eigentlich mit LibreOffice erstellt werden – schon die Unveränderbarkeit garantieren, oder muss das am Ende nicht durch die Buchhaltungssoftware oder ein DMS umgesetzt werden? 

Nehmen wir einmal an, du würdest das jetzt hinbekommen, was wären dann mit den Sonderfällen, wo ich die X-Rechnung anpassen muss. Sei es, dass noch eine Dokumentenspezifikation reinmuss, damit ich es in das Portal für öffentliche Auftraggeber hochladen kann – da fehlt nämlich noch eine Definition, damit es angenommen wird, oder wenn Kunden in der X-Rechnung die genauen Einheiten (Stunde, Liter, Stück, Portion) drin haben möchten, was Fakturama ja derzeit auch nicht kann. In beiden Fällen wäre der Hashwert, den du speichern kannst, schon nicht mehr korrekt, die Rechnungen selbst wären es aber.

Und um den Gedanken noch abzurunden, kommt ja auch hinzu, dass wir derzeit nur über Ausgangsrechnungen sprechen, dieselbe Pflicht besteht aber auch für Eingangsrechnungen. Auch die müssen unveränderbar gespeichert werden, wenn ich diese Digital empfange und dann wird doch deutlich, dass das die Aufgabe der Buchhaltungssoftware oder eines DMS ist und nicht die Aufgabe von Fakturama. Was anderes wäre es ja, wenn Fakturama die gesamte Buchhaltung abdecken würde, aber das macht das Programm ja nicht. 

Oder, anders. Ich könnte ja auch ein anderes Programm zur Erstellung von Rechnungen finden, welches besser zu meinen Bedürfnissen passt. Dann würde ich ja nur die Rechnungsdokumente (PDF und Co.) aufbewahren, Fakturama und seine Datenbank aber löschen. Auch dann müsste ich ja gewährleisten, dass die Dateien so gespeichert sind, dass sie unveränderbar sind. Hier wird vermutlich am deutlichsten, dass es nicht Aufgabe von Fakturama sein kann, dies sicherzustellen, sondern der endgültige Speicherort muss so gestaltet sein, dass die Dokumente nicht verändert werden können und dieser befindet sich ja meist in einem Container der Buchhaltungssoftware, oder eben in einem DMS. Deswegen weiß ich nicht, ob du dir da die Mühe machen musst, um es im Programm zu implementieren. 

Aber noch mal zum Ausgangspost:

Da falls eine Betriebsprüfung anstehen würde, dann würde das Finanzamt sobald die einen Fehler finden mir alle Rechnungen als nicht ordnungsgemäß anerkennen.

Wenn das Finanzamt Fehler findet, die vom Programm verursacht werden und welche die Rechnungen Steuerrechtlich unbrauchbar machen, weil zum Beispiel Pflichtangaben fehlen, dann wäre auch uninteressant, ob die Rechnungen unveränderbar wären, sie wären halt dennoch Fehlerhaft und müssten korrigiert werden, wobei dann ja die Kund*Innen das größere Problem hätten, weil die notfalls den Vorsteuerabzug rückgängig machen müssten und bis zu dem Zeitpunkt, wo sie dann die korrigierte Rechnung bekommen, auf diesen Fehlerhaften Vorsteuerabzug Zinsen zahlen müssten. Wenn nur eine Rechnung fehlerhaft wäre, was durchaus passieren kann, wüsste ich nicht, warum die dann alle anderen nicht anerkennen sollten. Das hat dann zwar auch mit den GoBD zu tun, aber nicht unbedingt mit der Unveränderbarkeit. 

Aber gut, auch hier nur meine Laienmeinung. Ganz sicher könnte es wohl nur das Finanzamt selbst beurteilen. 

Hm, das klingt auch wieder plausibel. Die Anbindung an ein DMS funktioniert übrigens schon, ich hab das mal mit ecoDMS gemacht. Da kann man einen Dateipfad angeben, der permanent überwacht wird. Wenn dort ein PDF reingeschrieben wird, dann wird das automatisch ins DMS geschoben (das ist die Einstellung für den zweiten Pfad für das PDF).

Danke für die wichtige Diskussion.

Zu WORM-Speicher: es gibt WORM-Tapes und WORM-USB-Sticks. Hat da jemand Erfahrungen gesammelt?

Wenn ich mir die Preise ansehe, dann ist die Tape-Lösung für viele zu teuer. Ich prüfe nun Lösungen mit Object Storage und passendem Löschschutz, z.B. https://docs.hetzner.com/de/storage/object-storage/faq/buckets-objects/