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 von 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?

[p80286]

Zitat von bcvs:

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 von bcvs:

Zitat von 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).