GoBD-konforme Rechnungsstellung

**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.

**Neumann**

Wir benutzen zwei Methoden um solche Daten manipulationssicher zu speichern:

1. In teilweise verschlüsselten Tabellen (Schlüssel ist dem Anwender nicht bekannt)

2. Parallel zur Speicherung in der Datenbank werden werden die wichtigsten Daten als CSV-Datensätze auf einen speziellen USB-Stick geschrieben, von dem sie nur noch gelesen werden können, löschen und ändern ist nicht möglich. Ist nicht ganz billig, meine so 80 € für 4GB Stick der etwa 1 Jahr beschrieben werden kann. Gelesen kann er garantiert 10 Jahre.

Aber wesentlich billiger als eine Steuerschätzung, so kaufen doch viele unserer Kunden diese Sticks.

Ganz problemlos ist das leider nicht immer, es gibt auch die üblichen Probleme, angefangen mit Stick liegt im Schrank oder wird nicht erkannt usw.

**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

**Hobbycoder**

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.

Garantieren kann man als Softwareanbieter hier schon mal gar nichts. Und sofern man von einem "normalen" Programm ausgehen kann, welches dem Nutzer auf seiner eigenen Hardware zur Verfügung stellt und dessen DB ebenfalls auf dem Nutzereigenen Server liegt, kann man generell keine Manipulation der Daten zu 100% verhindern oder ausschließen.
Was die Checksum und den Hash angeht, so hängt es ja auch davon ab wie dieser gebildet wird. Man kann an dieser Stelle dem potentiellen Angreifer nur das ganze erschweren. Sollte der Nutzer extrem gute Reverse-Engineering-Fähigkeiten haben und den Algorithmus aus deinem Programm ermitteln, so setzt auch das eine kriminelle Energie voraus. Auch wenn du die DB mittels Kennwort schützt und den Zugriff auf diese mittels DB-Benutzer absicherst, kann er das mit entsprechendem Aufwand knacken oder umgehen. Und in dem Fall müsstest du dich auf den DB-Hersteller verlassen, ob den seine Sicherheitsmaßnahmen wirklich nicht zu umgehen sind.
Als Softwareanbieter dieses zu 100% zu garantieren ist schlichtweg unmöglich.

Das einzige, was du nachweisen können musst, ist dass Manipulationen nicht in deinem Programm getätigt werden können, und vielleicht noch das externe Manipulation mit handelsüblichen Mitteln feststellbar sind.
Ansonsten wird es auf der Welt irgendwo immer eine Hacker geben, der in der Lage ist die Daten so zu Verändern, dass sie wie Original aussehen.

Natürlich könnte man noch ein Historie-Log mit schreiben und dieses mit 2048-Bit verschlüsseln. Wenn das dann aber der Angreifer einfach löscht nützt das auch nichts.

Man kann also nur soweit absichern, wie es in dem eigenen Einflussbereich liegt. Darüber hinaus geht das nicht, und darüber zu diskutieren wird nie zu einem Ergebnis führen.
Die Verwendung von "unveränderbare und fälschungssichere Datenträger" kann man ja bei frei verkäuflicher Software vergessen, bzw. deren Einsatz würde wieder außerhalb des eigenen Einflussbereichs liegen.

Das Problem liegt m.M.n. in der GoBD selbst. Diese ist so definiert, dass es letztlich keine wirklich eindeutigen Vorschriften, Verfahrensanweisungen und Grenzen festgelegt sind, und diese im Einzelfall so ausgelegt werden können wie es den Behörden passt. Auch eine "Freigabe" von FA oder ZA sind unverbindlich. Darin wird zwar bestätigt, dass man mit einem dargelegten Verfahren einverstanden ist, gleichzeitig wird sich dabei auf die GoBD berufen und das dieses im Einzelfall dann von einem Gericht wieder anders ausgelegt werden kann. Somit wäre die die Bestätigung ab dem Zeitpunkt wieder ungültig.
Heißt, die wirkliche Einhaltung der GoBD kann erst bestätigt werden, wenn in einem Einzelfall diese von einem Gericht als Eingehalten bestätigt wurde.
So sind meine Erkenntnisse nach Rückfragen bei FA und StB.

**Codehunter**

Zitat von Hobbycoder:

Heißt, die wirkliche Einhaltung der GoBD kann erst bestätigt werden, wenn in einem Einzelfall diese von einem Gericht als Eingehalten bestätigt wurde.

Ach schön wärs. Im Zweifel durch die Instanzen bis rauf zum EuGH und wieder runter zum OLG. Das zieht sich schon mal über eine Dekade. So viel Durchhaltevermögen haben doch nur die Konzerne mit eigenen Rechtsabteilungen, weil die Anwälte ja eine Existenzberechtigung brauchen. In der Praxis sieht es doch zumeist so aus, dass kleine Softwarebuden den außergerichtlichen Vergleich suchen. Denn andernfalls gehen dir deine Kreditlinien zum Teufel wenn dir 10+ Jahre so ein Verfahren anhängt.

**galex9**

Zitat von Hobbycoder:

Das Problem liegt m.M.n. in der GoBD selbst. Diese ist so definiert, dass es letztlich keine wirklich eindeutigen Vorschriften, Verfahrensanweisungen und Grenzen festgelegt sind, und diese im Einzelfall so ausgelegt werden können wie es den Behörden passt. Auch eine "Freigabe" von FA oder ZA sind unverbindlich.

Auf den Punkt gebracht!

**jaenicke**

Solange man grob zusammengefasst jede einzelne Buchung und jede Stammdatenänderung (vor allem Preisänderungen, aber auch Konfigurationsänderungen) zeitlich und genau nachvollziehen kann, die historischen Daten soweit möglich gegen Veränderungen geschützt sind, die Handbücher vorliegen und die Einrichtung usw. sauber dokumentiert ist, ist man schon sehr weit.

Der entscheidende Punkt ist, dass das Finanzamt sehen sollte, dass man aktiv bemüht ist keine Lücken offen zu lassen und sich an die Regeln zu halten. Damit schützt man die ehrlichen Kunden am besten.

Richtig ist aber auch, dass jeder Prüfer trotzdem genau hinschauen und zweifeln kann.