GoBD-konforme Rechnungsstellung

[bcvs]

Hallo zusammen,

mein Hauptprojekt ist ein Projektcontrolling mit Zeiterfassung für Planungsbüros. Damit kann man auch Rechnungen schreiben.

Jetzt stellt sich die Frage nach der GoBD-Konformität dieser Rechnungsstellung. Demnach dürfen die Rechnungen nur noch verändert werden können, solange sie noch nicht abgeschickt sind und die Änderungen müssen dokumentiert werden.

Das ist momentan nicht gegeben. Meine derzeitige Lösung sieht so aus: Der Anwender erstellt sich Rechnungsvorlagen als Word-Dateien, die die entsprechenden Textfelder für die verschiedenen Rechnungsarten beinhalten. Bei der Rechnungsstellung parst meine Software die docx-Datei nach den Textfeldern und befüllt diese mit den aktuellen Werten. Das Ergebnis ist eine neue Docx-Datei, die dann im Dateisystem gespeichert und in Word angezeigt wird. Hier wird die Rechnung in der Regel noch bearbeitet (freie Zusatztexte hinzufügen / überflüssige Textfelder entfernen). Das ist natürlich alles andere als GoBD-konform, da man die Rechnungen jederzeit nachträglich ändern kann.

Ich könnte jetzt natürlich die Rechnung in einem Blob-Feld speichern und eine Historie mit Dokumentation der Änderungen einbauen. Damit wäre der GoBD Genüge getan, denke ich. Aber: dann darf ich für die Änderung einer Rechnung nicht mehr Word verwenden, denn dann könnte man sie ja mit "Speichern unter" wieder ins Dateisystem zurückholen. Ich bräuchte also einen alternativen Doxc-Editor, der komplett in meine Software integriert werden müsste.
WPtools wäre so ein Kandidat, oder gibt es da noch etwas anderes?


Habt ihr vielleicht noch andere Ideen? Wie macht ihr das ?

[rapante]

Moin,
eine "Rechnungsarchivierung" im DOC Format finde ich mehr als unglücklich.

Was spricht denn gegen PDF?

Ich habe das Beispielsweise so gelöst:
-Der User erstellt seine Rechnung (über ein Baukastensystem mit Reportgenerator), kann sich diese ausdrucken, anzeigen, speichern etc.
-Wenn die Rechnung "fertig" ist wird Sie vom User "freigegeben". Dabei wird eine Rechnungsnummer vergeben und ein PDF erstellt. Jede weitere Änderung an der Rechnung wird vom System unterbunden.

[Hobbycoder]

Das Änderungen vor der Fakturierung dokumentiert werden müssen ist mir neu. Das kann ggf. ein intern genutztes Leistungsmerkmal sein, aber das das von der GoBD gefordert wäre kann ich mir nicht vorstellen.
Nach der Fakturierung darf eine Rechnung generell nicht mehr geändert werden. Es wird eine Stornorechnung geschrieben, die im Grunde identisch mit der Rechnung ist, so dass sie den Rechnungsbetrag zu 100% wieder ausgleicht.
Danach wird eine neue Rechnung mit den Änderungen erzeugt.
So wird das auch vom Steuerberater oder der Buchhaltung gebucht und ist dann zu 100% nachvollziehbar.

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.

Rechnungen lediglich als Datei (PDF oder DOC ist erstmal egal) halte ich für grob fahrlässig, da so immer ein Filezugriff für den Nutzer vorhanden sein muss und ich nicht spezifische Rechte auf Datensatzebene kontrollieren kann. Weiterhin schreibt die GoBD ja auch vor, dass die Software die Daten zwecks Steuerprüfung in digitaler Form zur Verfügung stellen muss. Das kann z.B. auch als CSV geschehen. Solche Listen dann aber aus PDF oder DOC wieder auszulesen dürfte schwierig werden.

In wie weit allerdings die GoBD vorschreibt ob eine Rechnung auch in gedruckter Form vorzuliegen hat, bzw. ob da eine PDF-Datei-Ablage ausreicht, entzieht sich meiner Kenntnis. GGf. kann dort eine Dokumentenarchivierung zu Einsatz kommen, wobei auch dabei darauf zu achten ist, dass einen direkter Filezugriff Sicherheitsrisiken birgt.
Meine Kunden drucken ihre Ausgangsrechnungen ausnahmslos aus und archivieren herkömmlich in Ordner, wie sie das schon seit Jahren gewohnt sind und sich nicht bei einer Steuerprüfung in den Nesseln setzen wollen. Eine eindeutige Aussage vom Finanzamt oder vom Steuerberater ist, was die GoBD angeht, nicht zu kriegen (geschweige denn eine verbindliche).
Mit großen Unternehmen, die mit Sicherheit hier schon papierlos(er) arbeiten, habe ich keine Erfahrung.

[bcvs]

Zitat:

Zitat von Hobbycoder (Beitrag 1394460)

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?

[p80286]

Zitat:

Zitat von bcvs (Beitrag 1394473)

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?

Was passiert wenn du bemerkst, daß in die Nachbarwohnung eingebrochen wird?
Natürlich kannst Du das ignorieren, und hoffen, daß das keiner bemerkt. Software kann Dir die Entscheidung ob Du Gesetze einhältst oder ignorierst, nicht abnehmen. Blöd nur wenn Dir nachgewiesen wird, daß Du wußtest, daß da manipuliert wurde.

Gruß
K-H

[Hobbycoder]

Zitat:

Zitat von bcvs (Beitrag 1394473)

Zitat:

Zitat von Hobbycoder (Beitrag 1394460)

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 :shock:

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

[Frickler]

Zitat:

Zitat von Codehunter (Beitrag 1394506)

Leider kann ich im Moment nicht direkt auf den Quellennachweis verweisen, weil das Bundesfinanzministerium den Download versemmelt hat :shock:

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:

Zitat von Frickler (Beitrag 1394529)

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:

Zitat von Hobbycoder (Beitrag 1394487)

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.

[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:

Zitat von mensch72 (Beitrag 1394554)

..."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:

Zitat von BlueStarHH (Beitrag 1394559)

Zitat:

Zitat von mensch72 (Beitrag 1394554)

..."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:

Zitat von BlueStarHH (Beitrag 1394559)

Zitat:

Zitat von mensch72 (Beitrag 1394554)

..."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:

Zitat von Hobbycoder (Beitrag 1394657)

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:

Zitat von Hobbycoder (Beitrag 1394657)

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.

[bernau]

Zitat:

Zitat von jaenicke (Beitrag 1394788)

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.

Nützt aber nichts, wenn der Steuerprüfer einen Grund sucht dem Geprüften was anzuhängen. Die Software ist das schwächste Glied, weil die GoBD so schwammig ausgelegt ist.

Ein Anruf beim BMF war zwar aufschlussreich. Schriftlich bekommt man aber nichts. Bund und Länder schieben sich den schwarzen Peter zu. Für die Gesetzgebung ist der Bund zuständig. Für die Ausführung sind die Länder zuständig. Also gibt das BMF keine konkrete Auskunft sondern verweist auf die Länder. Eine Auskunft bei einem Landesministerium hat aber keine bindene Wirkung für ein anderes Bundesland. (Wenn man mal was schriftliches bekommt)

Stichpunkt Handbücher. Die Handbücher müssen Vorliegen. Soweit klar. In welcher Form ist nicht definiert. Ausgedruckt, PDF, Hilfedatei etc. Die Aussage ist meist, es ist mir überlassen, wie ich die Handbücher bereit stelle. Ein Ministerium sagte mir, dass es wichtig ist, dass das Hadbuch zur "damaligen" Version der Sofware past, damit der Prüfer sehen kann, was mit der Software gemacht werden konnte. Also bist du gezwungen sämtliche Versionen des Handbuches aufzubewahren und nicht nur die neuste. Aber schriftlich habe ich dies nicht bekommen.

Bei einer Prüfung kann dann der Prüfer sagen "reicht mir nicht" und schon bist du dran. Aber nur über Umwege. Dein Kunde muss erst mal dafür grade stehen. Dem wird gesagt, die Nachschätzung ergibt 200TEU. Wir sind aber großzügig wir machen einen Vergleich über 10TEUR. Was meinst du was der Kunde macht? Ich hätte gerne dagegen geklagt. Das kann aber nur der Kunde, weil es ein Rechtstreit zwischen Ihm und dem FA ist. Der Kunde kann dich dann verklagen. usw. Macht nicht wirklich Spaß.

[Hobbycoder]

Zitat:

Zitat von bernau (Beitrag 1394793)

Ein Anruf beim BMF war zwar aufschlussreich. Schriftlich bekommt man aber nichts. Bund und Länder schieben sich den schwarzen Peter zu. Für die Gesetzgebung ist der Bund zuständig. Für die Ausführung sind die Länder zuständig. Also gibt das BMF keine konkrete Auskunft sondern verweist auf die Länder. Eine Auskunft bei einem Landesministerium hat aber keine bindene Wirkung für ein anderes Bundesland. (Wenn man mal was schriftliches bekommt)

Man könnte fast denken die GoBD wäre ein politisches Statement. ;-)

[Codehunter]

Zitat:

Zitat von Hobbycoder (Beitrag 1394796)

Man könnte fast denken die GoBD wäre ein politisches Statement. ;-)

Ich glaube, Amazon, Apple, Google, Microsoft, Oracle, Samsung, SAP usw. könnten selbst mit vereinten Kräften keine KI bauen, die das deutsche Finanzrecht versteht. Durch die absurde Komplexität und dem "Allenallesrechtmacherismus" werden jedes Jahr Milliarden verbrannt. Für Beamte, Gerichte und Steuerfahnder auf der einen und für Steuerberater, Anwälte und Finanzdienstleister a la Panama auf der anderen Seite. Und die kleinen Softwareschmieden sitzen zwischen den Fronten.

[mensch72]

für das teils Länder spezifisch ausgelegte Finanzrecht braucht es keine KI, das geht durchaus noch "zu Fuß"(nur eben NICHT mit purer Logik!).

Bei uns hier in Thüringen haben FA und Zoll nicht die besten, aber auch nicht die schlechtesten Analysewerkzeuge um "Bösewichten" auf die Spur zu kommen. Die "Bundes-Bafin" orientiert sich stark an Hessen, Bayern und B-W, das ist per "vorausschauendem" VorabSoftwareCheck lösbar.

Es gibt durchaus einen sagen wir GrauMarkt für "kommerzielle Unbedenklichkeitschecks". Nach dessen Tests und Angaben ist unsere in/für Thüringen voll aktuell bestätigte Software z.B. fürs Saarland nicht zu gebrauchen, weil ein paar dort beobachtete statistische Parameter nicht sicher eingehalten werden, was dort bis zum Initial-Trigger für eine Tiefenprüfung führen kann.

Was soll's... ich kenne mittlerweile die dortige Analyse-&Prüflogik... ich wüsste wie aktuell es buchungstechnisch auch dort zu umgehen wäre, nur genau das wäre ein angreifbarer Umgehungstatbestand für die Softwareanwender wie auch für mich als Softwarelieferant... werde ich also weder zur Vorabprüfung und schon gar nicht zur Umgehung implementieren.


..."kleinen Softwareschmieden sitzen zwischen den Fronten"...
NEIN... genau das sehe ich anders!
Wer seinen Kunden dokumentierte Grenzen(für Funktions&Analyse) aufzeigt und per Software sauber und hart umsetzt, dem kann auch WorstCase bis auf den ev. notwendigen Nachweisaufwand nicht viel passieren.
Schon pure eventuelle Warnfunktionen je nach Bundesland bzgl. "Wissensstand X" werde ich NIE in die Standardsoftware einbauen.
Eigene Kompatibilität zu Standards hat dann für mutige Anwender in speziellen Bundesländern den Vorteil, das die sich selbst im INet zusätzlich passende Analyse&Hilfs-Tools besorgen und nutzen können.
Wenn Sage, Lexware usw. das nicht aktiv verhindern, mache ich mir keinen Kopf wenn Daten meiner Software so auch nutzbar sind.

[BlueStarHH]

Zitat:

Zitat von mensch72 (Beitrag 1394877)

Schon pure eventuelle Warnfunktionen je nach Bundesland bzgl. "Wissensstand X" werde ich NIE in die Standardsoftware einbauen.

Wie genau meinst Du das? Angenommen, der Nutzer schaltet die automatisch lückenlose Generieung der Rechnungsnummern ab oder er deaktiviert die Funktion, dass gebuchte Rechnungen nicht mehr verändert werden können. (Edit: Oder andere Funktionen, wo das rechtlich nicht so eindeutig ist) In diesem Fall würdes Du keine Warnmeldungen anzeigen? Warum nicht? Ich würde es machen, damit der Nutzer später nicht behaupten kann von nichts gewußt zu haben und das Programm sei schuld, da es ja seine Aktionen zugelassen hätte.

[Hobbycoder]

Zitat:

Zitat von BlueStarHH (Beitrag 1394897)

Angenommen, der Nutzer schaltet die automatisch lückenlose Generieung der Rechnungsnummern ab oder er deaktiviert die Funktion, dass gebuchte Rechnungen nicht mehr verändert werden können.

Ich würde eine solche Funktion zum beschalten automatischer Rechnungsnummerngenrierung und nachträgliches Ändern von fakturierten Rechnungen erst gar nicht in ein Programm einbauen.
Es gibt keine Notwendigkeit für solche Funktionen.

[BlueStarHH]

Zitat:

Zitat von Hobbycoder (Beitrag 1394899)

Ich würde eine solche Funktion zum beschalten automatischer Rechnungsnummerngenrierung und nachträgliches Ändern von fakturierten Rechnungen erst gar nicht in ein Programm einbauen.

OK, nicht ganz glückliches Beispiel. Dann nehme eine beliebige andere Fragestellung, wo es rechtlich nicht so eindeutig ist. Dort ist dann die Frage: Warnmeldung oder nicht?

[Codehunter]

Zitat:

Zitat von BlueStarHH (Beitrag 1394914)

Warnmeldung oder nicht?

Das ist doch genau die Frage: Wo fängst du an mit dem Warnen? Wie wir erfahren haben, gibt es landesspezifische Unterscheidungen. Jetzt hast du ein Unternehmen mit Filialen in verschiedenen Ländern, die z.B. über VPN das selbe Wawi benutzen. Bekommt dann jeder die Warnungen der anderen Länder mit angezeigt? Das nur mal als praktisches Beispiel. Würde ich auch nicht einbauen wollen. Zumal du dann ja mit Updates nicht mehr hinterher kommst wenn es mal wieder irgendwo ein LG-Urteil gibt. Für sowas haben die Unternehmen Steuerberater um zu klären was geht und was nicht.

[Hobbycoder]

Ich weiß nicht genau worauf du hinaus willst.
Wofür willst du Warnmeldungen anzeigen? Wenn du eine Änderung fakturierter Rechnungen aus dem Programm heraus ausschließt und auch die Rechnungsnummernvergabe immer automatisch laufen lässt, dann sollten bestimmte Fälle nie vorkommen können.
Auf eine externe Manipulation der Daten würde ich sehr eingeschränkt reagieren. Wer externe an den Daten Veränderungen vornimmt geht selbst das Risiko ein, dass er dabei möglicherweise gegen geltendes Recht verstößt. Wenn du dann eine Warnmeldung ausgibt, weiß der Angreifer, dass er weitere Manipulationen durchführen muss, um es später auf eine Fehlfunktion der Software zu schieben, und ggf. sogar, wo in der DB noch Änderungen machen muss. Damit würdest du dir evtl. die Möglichkeit nehmen später zu beweisen, dass es eben nicht an der Software gelegen hat.

Evtl. könnte man bei der Datenübergabe an Datev o. ä. allgemein auf eine Inkonsistenz hinweisen.

[Codehunter]

Von böswilliger Manipulation mal abgesehen: Ich hatte schon Fälle, wo ganz simple Fehler passiert sind. Der Anwender hatte bei einem Textfeld ein abschließendes Leerzeichen eingegeben. Es wurde auch so gespeichert in der DB. Nach GoBD würde es auch in Hashes mit einfließen. Bei einem Update des DBMS wurde das Leerzeichen weggetrimmt, weil bei der Erstellung des Updates nicht aufgepasst wurde. Der Hash wird ungültig, also erstmal verdächtig. Heißt, wir Softwareleute müssen immer an solche Möglichkeiten denken. Im konkreten Fall solche Leerzeichen schon bei der Eingabe und vor der Speicherung in der DB trimmen, nicht erst nachträglich.

[mensch72]

(Nachträgliche)Rechnungsmanipulation ist nicht das uns bekannte Hauptproblem.

Viel aufregender sind Blockbuchungen... also Rechnungen werden wie/wo auch immer gesammelt und erst später quasi alle auf einmal eingegeben und gestellt.
Das schafft sagen wir etwas Flexibilität bei Lager<->WaWi<->FiBu<->Bilanzierung nach Steuergesetz und betriebswirtschaftlicher Abrechnung nach Handelsgesetz.
Das suchen nach Blockbuchungen gehört im Saarland zum Standard bei normalen Prüfungen, weil es in Frankreich stark verbreitet ist. Unsere Software verhindert oder meldet das nicht.

Wir haben hier ein öffentliches Forum, da ist es nicht sinnvoll und möglich noch genauer auf "kreative Buchungstechniken für Lager/WaWi/FiBu&BAB" einzugehen, ganz ohne nachträgliche Manipulationen... letztendlich ist das ja auch der Grund warum es eben doch solche Software auch von Klein und/oder Nischenanbietern gibt, und sowas auch gut bezahlt wird :)

[sh17]

Ich finde schon, das wir das hier öffentlich diskutieren können. Wir lernen alle davon und vielleicht kann man so von Softwareseite einen praktikablen Ansatz schaffen, der allen Entwicklern hilft ohne jedes mal bei 0 anzufangen. Hier könnte man durchaus auch mal als "Konkurrent" in der Branche zusammen arbeiten. Sind wir doch mal ehrlich ... wollen wir uns mit dem "Mist" eigentlich beschäftigen? Nein. Wir wolle innovative Software für den Benutzer schaffen. Gesetzliche Auswüchse sind einfach nur nervig.

[Hobbycoder]

Zitat:

Zitat von mensch72 (Beitrag 1394924)

(Nachträgliche)Rechnungsmanipulation ist nicht das uns bekannte Hauptproblem.

Aber, wenn ich mich nicht irre, der Kern der Thread-Frage.

[Hobbycoder]

Wir sprechen hier ja über die Rechnungserstellung und weniger über das Buchen in der Finanzbuchhaltung.
Was aber nun wirklich immer mal wieder vorkommt ist folgender Ablauf:
Lieferant A erstellt eine Rechnung für Kunde B.
Kunde B. wartet mit der Bezahlung bis zum maximalen Zahlungsziel und ggf. etwas darüber hinaus bis zu ersten Mahnung.
Dann ruf Kunde B. bei Lieferant A. an und moniert die Rechnung, es wären z.B. Fehler im Adressfeld Rechnungsempfänger oder eine Rechnungsposition wäre nicht ganz korrekt und er könnte die Rechnung so nicht bezahlen.
Lieferant A will Kunde B behalten und nimmt den Mängel auf und möchte die Rechnung der Richtigkeit halber korrigieren.
Nun hätten wir ein Fall, wo der Rechnungsersteller gerne seine Rechnung nachträglich bearbeiten möchte. Im günstigsten Fall betrifft es "nur" die Rechnungsanschrift, aber im schlechten Fall eben auch Rechnungspositionen und damit Summen und MwSt.
Nun könnte der Softwareanbieter natürlich dem Programmnutzer erlauben diese Änderungen zu tätigen, denn die Rechnung ist noch nicht bezahlt und möglicherweise auch noch nicht in der Buchhaltung. Der Rechnungsempfänger könnte die fehlerhafte Rechnung einfach vernichten, bekommt eine neue und alles ist gut.
Nun könnte aber die Eingangsrechnung bei Kunde B. bereit in der Buchhaltung angekommen sein, und die Ausgaben, Vorsteuer, etc. bereits gebucht sein. Und was weiß ich, was noch alles für Möglichkeiten existieren, damit jetzt gezielt Abgaben am Fiskus vorbei zu schleusen.

Richtig wäre, die originale, fehlerhafte Rechnung, so wie sie ist, als Stornorechnung zu schreiben, und ggf. automatisch eine neue Rechnung "mit neuer Rechnungsnummer" zu erzeugen. Nur so ist meiner Meinung nach der ganze Vorgang lückenlos dokumentiert und kann auf beiden Seite entsprechend verbucht werden, und ist somit auch für eine Prüfung nachvollziehbar.

[sh17]

richtig, so muss es laufen. Ich sag immer, man kann sich an den Ablauf der Rechnungserstellung vor 100 Jahren orientieren, wo wirklich alles per Papier und Brief ging. Da gab es Rechnungsbücher usw wo man sich die Rechnungsnummer "abholen" musste und so weiter. Wenn man das so abbildet ist man auf der nachvollziehbaren Seite. Und wenn die Rechnung falsch war, dann muss man sie eben kommentiert im Original zurück schicken und sie wird storniert und es gibt einen neuen Zettel mit neuer Nummer

[bernau]

Zitat:

Zitat von Hobbycoder (Beitrag 1394929)

Richtig wäre, die originale, fehlerhafte Rechnung, so wie sie ist, als Stornorechnung zu schreiben, und ggf. automatisch eine neue Rechnung "mit neuer Rechnungsnummer" zu erzeugen. Nur so ist meiner Meinung nach der ganze Vorgang lückenlos dokumentiert und kann auf beiden Seite entsprechend verbucht werden, und ist somit auch für eine Prüfung nachvollziehbar.

Genau so ist es :thumb:

[bcvs]

Danke für die lebhafte Diskussion. Hat mir einige interessante Aspekte aufgezeigt.

Ich werde es jetzt voraussichtlich so lösen:

Die Rechnung wird wie bisher als .Docx erstellt aus den in der DB gespeicherten Daten auf der Basis einer vom Benutzer definierten Vorlage. Das Ergebnis wird allerdings nicht im Dateisystem gespeichert, sondern als Blob-Feld in der DB.

Die Rechnungsnummer wird zunächst nicht vergeben. Solange das noch nicht geschehen ist, kann die Rechnung noch geändert werden um z.B. Schreibfehler in Zusatztexten auszubessern. Abschicken kann der User die Rg in diesem Zustand nicht, da sie noch keine Rechnungsnummer hat. Erst wenn man auf "Fertig" klickt, oder "Fakturieren" oder wie auch immer man das nennt, wird die Rechnungsnummer vergeben, ins Dokument eingesetzt und die Rechnung zum Ändern gesperrt.

Ab jetzt kann die Rechnung nur noch ausgedruckt werden. Bei Änderugnen muss storniert und neu geschrieben werden (mit neuer Rg-Nummer)

Spricht da aus eurer Erfahrung etwas dagegen?

[Codehunter]

Zitat:

Zitat von bcvs (Beitrag 1394944)

Spricht da aus eurer Erfahrung etwas dagegen?

Wenn du über das BLOB-Feld noch nen Hash legst bei der Fakturierung, könnte das so gehen. Wenngleich ich es auch ein wenig umständlich finde.

[Hobbycoder]

Umständlich sicherlich. Ich würd‘s Auch nicht so machen.
Aber ein Hash über Blob hat zumindest den Vorteil, dass man sich um bei Export/Import der DB entstehende abgeschrittene Leerzeichen, welche den Hash ungültig machen würden, keine Gedanken mehr machen muss.

[bcvs]

Zitat:

Zitat von Hobbycoder (Beitrag 1394968)

Umständlich sicherlich.

Mag sein, dass das etwas umständlich ist. Ich möchte allerdings nur so wenig wie möglich am bisherigen Workflow für die Anwender ändern.
Und die sind es gewohnt, mit den Word-Vorlagen volle Kontrolle über das Layout der gedruckten Rechnung zu haben. Deshalb will ich dieses Konzept beibehalten.