GoBD-konforme Rechnungsstellung

**Hobbycoder**

Die Rechnung muss nicht zwingend als PDF gespeichert werden. Es muss lediglich sichergestellt sein, dass eine nachträgliche Veränderung durch den Benutzer ausgeschlossen ist (auch PDF's lassen sich ändern), oder eben, wenn dieser sich von "außen" an den Daten zu schaffen macht, diese Manipulation feststellbar ist. Ich löse diese mittels einer Checksumme und einem Hash über die kompletten Daten einer Rechnung.
Wichtig ist halt, dass du als Softwarehersteller über dein Programm dem Nutzer nicht die Möglichkeit der Manipulation fakturierter Rechnung in die Hand gibt's, und eben eine Manipulation ggf. feststellen kannst. Für die Sicherheit seiner Datenbank (o.ä.) ist der Nutzer selbst zuständig, in welcher Form (Zugriffsrechte etc.) er Manipulation durch Angestellte unterbindet.

Das ist ein interessanter Aspekt.
Aber was passiert, wenn deine Software eine Manipulation feststellt? Kommt dann einfach ein Warnhinweis? Kann man dann nicht trotzdem die Rechnung manipulieren und den Warnhinweis einfach ignorieren?

Bei der Bildung von Checksum und Hash geht es weniger darum, dass ich dem Nutzer zeige das Manipuliert wurde, sondern eher darum, dass ich auf Verlangen nachweisen kann, dass eine Manipulation stattgefunden hat. In welcher Form ist mir dabei eigentlich egal.

Nehmen wir mal an, ein Mitarbeiter (oder der Chef selbst) manipuliert nachträglich Rechnungsdaten direkt in der DB. Das geht ein paar Jahre gut. Dann kommt eine Steuerprüfung und es werden Ungereimtheiten festgestellt. Dann würde der Mitarbeiter und/oder der Chef sämtliche Vorwürfe von sich weisen und es letztlich auf ein Fehler in der Software schieben, weil das so schön einfach ist, und das Gegenteil schwer zu beweisen ist. Also würde der Steuerprüfer, das FA oder ein Rechtsanwalt möglicherweise an mich herantreten. Mit den Daten und dem Sourcecode kann ich dann Beweisen, dass eine Veränderung von außen stattgefunden hat und bin aus der Sache schadensfrei raus.
Natürlich könnte man eine Manipulation auch innerhalb des Programms darstellen. Das ist dem Entwickler überlassen. Er kann es tun, muss es aber nicht.

Grundsätzlich lasse ich eine nachträgliche Manipulation von fakturierten Rechnungen über meine Software nicht zu, sondern biete lediglich den Weg über eine Storno an. Würde ein Kunde das von mir verlangen würde ich das ablehnen, denn damit allein würde ich mich schon auf dünnes Eis begeben.
Weiterhin bin ich aber der Meinung, dass eine Datenbank für den Nutzer offen sein sollte. Heißt, z.B. im Falle von MSSQL, dass der Nutzer das sa-Kennwort selbst kennt, und auch für seine Datensicherung aber auch der Datensicherheit selbst zuständig ist. Benutzer verwalte ich immer auf Programmebene, auch wenn ich diese aus Windows übernehme. Ich arbeite also immer nur mit einem SQL-Benutzer, der volle Rechte auf den DB hat, und teile die Rechte ja nach Anmeldung dann im Programm zu.
Wer dann im Unternehmen das SA-Kennwort kennt ist dem Nutzer überlassen.
Somit ist die Rechtevergabe und die Datensicherung Kundensache. Ich weise meine Kunden in der Dokumentation entsprechend darauf hin.

Wie p80286 schon sagte, wie und von wem auf eine externe Manipulation reagiert wird, interessiert mich nicht. Ist immer besser, wenn man sich aus sowas heraushält.

**Codehunter**

So wie ich die GoBD verstanden habe, ist der Beleg (in welcher Form auch immer, sei es PDF oder DOCX oder sonstwas) gar nicht mehr der ausschlaggebende Punkt. Vielmehr liegt der Beleg-Ursprung in der Datenbank. Dort werden Belegdatensätze als "fakturiert" gekennzeichnet und dürfen dann nicht mehr bzw. nur noch in engen Grenzen verändert werden. Ausgegebene Belege sind quasi Abzüge. Bei Buchprüfungen wird dann geschaut, ob die Belege mit den Belegdatensätzen überein stimmen.

Eine reine Belegablage im Dateisystem wird in der GoBD selbst schon mehr oder weniger ausgeschlossen. Leider kann ich im Moment nicht direkt auf den

Quellennachweis verweisen, weil das Bundesfinanzministerium den Download versemmelt hat

Aus dem Gedächtnis zitiert: "Eine Ablage in einem Dateisystem genügt den Anforderungen der GoBD regelmäßig nicht".

**Frickler**

Zitat von Codehunter:

Leider kann ich im Moment nicht direkt auf den

Quellennachweis verweisen, weil das Bundesfinanzministerium den Download versemmelt hat

Aus dem Gedächtnis zitiert: "Eine Ablage in einem Dateisystem genügt den Anforderungen der GoBD regelmäßig nicht".

Was meinst Du mit "den Download versemmelt?" Funktioniert doch problemlos...

Punkt 110 auf Seite 24:

Die Unveränderbarkeit der Daten, Datensätze, elektronischen Dokumente und elektronischen Unterlagen (vgl. Rzn. 3 bis 5) kann sowohl hardwaremäßig (z. B. unveränderbare und fälschungssichere Datenträger) als auch softwaremäßig (z. B. Sicherungen, Sperren, Festschreibung, Löschmerker, automatische Protokollierung, Historisierungen, Versionierungen) als auch organisatorisch (z. B. mittels Zugriffsberechtigungskonzepten) gewährleistet werden. Die Ablage von Daten und elektronischen Dokumenten in einem Dateisystem erfüllt die Anforderungen der Unveränderbarkeit regelmäßig nicht, soweit nicht zusätzliche Maßnahmen ergriffen werden, die eine Unveränderbarkeit gewährleisten.

**Codehunter**

Zitat von Frickler:

Was meinst Du mit "den Download versemmelt?" Funktioniert doch problemlos...

Jetzt wieder. Als ich es abrufen wollte endete der Browser in einer Weiterleitungsschleife.

**BlueStarHH**

Zitat von Hobbycoder:

Bei der Bildung von Checksum und Hash geht es weniger darum, dass ich dem Nutzer zeige das Manipuliert wurde, sondern eher darum, dass ich auf Verlangen nachweisen kann, dass eine Manipulation stattgefunden hat.

Was passiert, wenn die Checksum/Hash passend zu den Daten manipuliert werden? (Dann sind Änderungen an den Daten nicht mehr feststellbar) Deine User haben ja Vollzugriff auf die DB und Deine EXE. In der EXE kann Dein Checksum/Hash-Algorithmus nachgeschaut werden (Entsprechendes Wissen vorrausgesetzt).

**mensch72**

..."Was passiert, wenn die Checksum/Hash passend zu den Daten manipuliert werden?"...
- gar nix passiert dem Softwareanbieter, denn solche Änderungen sind Vorsatz, weil mit krimineller Energie verbunden(zusätzlich die untersagte EXE Analyse)
- WaWi und FiBu müssen nur für den Normalgebrauch sicher und gegen fahrlässige Fehlnutzung durch den Softwareanbieter gesetzeskonform realisiert&geschützt sein
- der/die KundenAdmins können das Warnlevel zur Anzeige von Veränderungen auch auf 0 stellen und so auch für alle incl. sich deaktivieren(die Erkennung findet weiterhin statt)
- wir interessieren uns nur für die Gesetzeslage aus Anbietersicht, wir ignorieren uns ev. auffallende vorsätzliche Änderungen, wenn ein KundenAdmin dort das Warnlevel auf 0 hat
- wenn wir unabwendbar durch eine staatliche Gewalt zur Erstellung und eines Herausgabe einer Prüfliste gezwungen werden, dann machen wir das auch nur soweit wie es zu unserem Eigenschutz "z.B. zur Abwendung des Verdachts auf Beihilfe" notwendig ist.

Das Gesetz ist so schon OK, es schützt letztendlich die normalen Softwareanbieter. Nur wenige waren so verrückt+dumm und haben z.B. bei/für (Gastro)Registrierkassen gleich die quasi Doppelte Buchführung voll mit integriert.

Wenn man für Test und Debugzwecke selbst Tools braucht, wo sich gleiche Buchungsvorgänge mehrfach "verschieden" durchspielen lassen, dann gehört sowas in ein externes Programm was entweder niemals das eigene Haus verlässt, oder wenn es an Systempartner geht dann nur Online mit Liveprotokoll durch den eigenen WebService funktioniert(das ist bei allen Autowerkstätten heute so... vieles geht im Softwareservice nur noch wenn Auto über das WerkstattSystem live mit der Herstellerzentrale verbunden wird).

Für Kundenanwendungen lehne ich selbst jeglichen Onlinezwang ab, aber für Service- und Partnertools ist es der richtige (Kontroll)Weg.

**BlueStarHH**

Zitat von mensch72:

..."Was passiert, wenn die Checksum/Hash passend zu den Daten manipuliert werden?"...
- gar nix passiert dem Softwareanbieter, denn solche Änderungen sind Vorsatz, weil mit krimineller Energie verbunden(zusätzlich die untersagte EXE Analyse)
- WaWi und FiBu müssen nur für den Normalgebrauch sicher und gegen fahrlässige Fehlnutzung durch den Softwareanbieter gesetzeskonform realisiert&geschützt sein
- ...

Bis Du Dir sicher, dass man das so einfach sehen kann? Welchen Sinn hat dann eine Checksum/Hash, wenn damit nicht *garantiert* werden kann, dass die Daten nicht verändert wurden? Die GoBD schreiben doch vor, dass Änderungen erkennbar oder nicht möglich sein *müssen*. Selbst wenn man den Algorithmus/EXE nicht analysiert (um da nichts verbotenes zu tun), könnte man sich noch immer mit einem Datenbank-Admin-Tool mit der Datenbank verbinden, den Datensatz per SQL löschen und mit Deiner Software einen neuen (abgeänderten) Datensatz erstellen, der dann eine gültige Checksum/Hash bekommt.

**mensch72**

...Punkt 110 auf Seite 24:
Die Unveränderbarkeit der Daten, Datensätze, elektronischen Dokumente und elektronischen Unterlagen (vgl. Rzn. 3 bis 5) kann sowohl hardwaremäßig (z. B. unveränderbare und fälschungssichere Datenträger) als auch softwaremäßig (z. B. Sicherungen, Sperren, Festschreibung, Löschmerker, automatische Protokollierung, Historisierungen, Versionierungen) als auch organisatorisch (z. B. mittels Zugriffsberechtigungskonzepten) !!!gewährleistet!!! werden."...
-> "gewährleistet" gilt für den Normalbetrieb und nicht bei vorsätzlicher&multibler Manipulation... allein weil Erfüllung "auch organisatorisch" möglich, schließt das jeden Zwang zum Aufwand für absolut eineindeutige voll eigensichere und hoch manipulationsresistente Verfahren aus

..."Bis Du Dir sicher"...
ja, "ich" habe für unser simples Konzept jeweils bestätigte(und nebenbei auch selbst bezahlte) Feststellungsanfragen.. heißt Thüringer Finanzbehörden und Hauptzollamt reicht meine realisierte Sicherung der "Unveränderbarkeit".
(weil es bei uns auch um Abrechnung/Prüfung spezieller Formen von BAFIN regulierten Finanztransaktionen geht, habe ich mir auch dafür das Konzept per bezahlter Einzelfreigabe noch separat bestätigen lassen)

..."gilt das allgemein"...
NEIN!!!... entweder man beauftrage Fachanwälte mit der Vorabprüfung, oder man investiere weniger Geld aber mehr Zeit und Geduld zur Frage an die, welche es WorstCase später ev. kontrollieren

**HolgerX**

Hmm..

Zitat von BlueStarHH:

Zitat von mensch72:

..."Was passiert, wenn die Checksum/Hash passend zu den Daten manipuliert werden?"...
- gar nix passiert dem Softwareanbieter, denn solche Änderungen sind Vorsatz, weil mit krimineller Energie verbunden(zusätzlich die untersagte EXE Analyse)
- WaWi und FiBu müssen nur für den Normalgebrauch sicher und gegen fahrlässige Fehlnutzung durch den Softwareanbieter gesetzeskonform realisiert&geschützt sein
- ...

Bis Du Dir sicher, dass man das so einfach sehen kann? Welchen Sinn hat dann eine Checksum/Hash, wenn damit nicht *garantiert* werden kann, dass die Daten nicht verändert wurden? Die GoBD schreiben doch vor, dass Änderungen erkennbar oder nicht möglich sein *müssen*. Selbst wenn man den Algorithmus/EXE nicht analysiert (um da nichts verbotenes zu tun), könnte man sich noch immer mit einem Datenbank-Admin-Tool mit der Datenbank verbinden, den Datensatz per SQL löschen und mit Deiner Software einen neuen (abgeänderten) Datensatz erstellen, der dann eine gültige Checksum/Hash bekommt.

Hatte da mal was gesehen:

https://www.youtube.com/watch?v=Rv2oGH-wfmA

Hier könnte das Beispiel der BlockChain als Sicherung dienen, denn wenn ein Eintrag verändert/ersetzt würde, dann währen alle nachfolgenden Datensätze ungültig. Es könnte nachgewiesen werden, dass eine Veränderung stattgefunden hat.

(So habe ich das zumindestens beim 'Überfliegen' verstanden

)

**Rollo62**

Siehe auch mein

Tread zu Anwendungen hier.

Ich denke mittlerweile Blockchain ist nur ein Hype, der wenig realistisch ist.
Weil einfach keiner da irgendein konkretes Szenario ohne massive Nachteile nennen konnte, die man nicht anders viel simpler hinbekommen könnte.

Erschwerend kommt hinzu das die

Blockchain extrem anwächst, und man das nicht "mal eben" runterladen und lokal speichern kann.
Ebenfalls

wächst die

Blochchain Berechnung

exponentiell an.

Rollo