GoBD-konforme Rechnungsstellung

**BlueStarHH**

Ich muss das wichtige Thema nochmal aufgreifen:

Ein Kunde kauft bei einem Softwareentwickler ein Rechnungs-Programm. Die GoDB fordert, dass Veränderungen an Rechnungen nicht möglich sind oder erkannt werden. Dies möchte der Kunde vom Anbieter bestätigt haben, da der Betriebsprüfer vom Finanzamt bei einer Betriebsprüfung prüfen wird, ob die Software diesen Kriterien entspricht. Sollte das nicht der Fall sein, kann die Buchhaltung verworfen werden und es drohen Steuernachzahlungen.

Hier wird nun in einigen Beiträgen behauptet, dass bei Manipulationen keine Gefahr für den Anbieter der Software drohen würden, wenn "solche Manipulationen mit krimineller Energie verbunden wären" (Beitrag #11 von mensch72). Außerdem müsse die "WaWi nur für den Normalgebrauch sicher und gegen fahrlässige Fehlnutzung durch den Softwareanbieter gesetzeskonform realisiert&geschützt sein" (Beitrag #11 von mensch72).

Ich bin hingegen der Meinung, dass die GoDB so ausgelegt werden muss, dass Manipulationen in *allen* Fällen erkannt werden oder ausgeschlossen sind. Sonst kann man als Anbieter nicht behaupten, dass die Software die GoBD einhält. Dazu habe ich ein Urteil gefunden, dass meine Meinung unterstützt. Auf der Seite eines Steuerberaters

http://www.stb-panketal.de/service/3...usgabe-2017-06 gibt es unten unter dem Link Download

http://www.stb-panketal.de/images/ma...nfo_201706.pdf eine PDF-Datei. Dort wird ein Fall beschrieben, wo es zu Steuernachzahlungen kam, denn:

Zitat:

Die Kassen des Klägers waren aber manipulierbar. Dies hat ein Gutachten ergeben, das vom FG eingeholt worden ist. Unbeachtlich ist dabei, ob eine Manipulation einfach ist und von einem PC-Laien durchgeführt werden kann oder ob eine Manipulation schwierig ist und nur von einem EDV-Spezialisten vorgenommen werden kann. Auf eine tatsächliche Manipulation der Kasse kommt es ebenfalls nicht an.

Zu finden in der PDF-Datei auf Seite 3 oben in der linken Spalte und dem zweiten Punkt.

Heißt also: Wenn ein "EDV-Spezialist" die Daten ändern kann, ist die Software nicht GoDB-Konform. Der Kunden könnte dann versuchen, den Anbieter in Regress zu nehmen. Oder der Anbieter kann nicht damit werben, dass die Software GoBD-konform ist. Dann kauft die aber niemand. Evtl. ist auch davon auszugehen, dass die Software GoBD-konform ist, auch wenn dies nicht explizit erwähnt ist. Und der Anbieter wäre dann trotzdem Regresspflichtig.

Lange Rede, kurzer Sinn: Wie kann eine Datenbank so vor Änderungen geschützt werden, dass diese erkennbar sind?

**mensch72**

..."Lange Rede, kurzer Sinn: Wie kann eine Datenbank so vor Änderungen geschützt werden, dass diese erkennbar sind?"...

Kurze&klare Antwort: GARNICHT, solange diese gemeinsam samt der Anwendung die dort liest&schriebt rein auf Kunden (kontrollierter) Hardware liegt

Wenn du das willst baue eine "dumme" WEB-GUI, verschlüssele&authentifiziere alles was via WEB an Anfragen an deine Server oder ein BSI zertifziertes Trustcenter geht.
Gib deiner dummen WEB-GUI nur 1:1 die Möglichkeit deine Antwortdaten zu dekodieren und "readonly" anzuzeigen.

So bist du zwar WostCase oberflächlich eventuell für dumme Leute 1% besser GoDB konform, ABER du nagelst dir damit ein eches Datenschutzproblem selbst ans Knie... sowas hat einen noch viel längeren Rattenschwanz und ist im Gegensatz zur GoBD eine echtes FassOhneBoden!!!
Daher etwas vernünfiges und gut dokumentiertes selbst machen, dann SELBST AKTIV vorab von allen möglichen Klägern (!und immer gegen Geld!) Unbedenklichkeit bestätigen lassen... bis zur nächsten Gesetzesänderung ist dann "RuheImKarton", denn wo kein Kläger, da kein Richter!

@BlueStarHH

Du musst auch den gesamten Kontext lesen und nicht nur die Stellen, die deinen Standpunkt belegen.

Zitat:

Das Finanzamt war zu einer Hinzuschätzung berechtigt, weil die Kassenbuchführung nicht ordnungsgemäß war. So fehlten die Programmierprotokolle, aus denen sich nachträgliche Änderungen der elektronischen Kasse ergeben konnten. Ein Prüfer muss nämlich erkennen können, ob und wie die Programmierung der Kasse verändert worden ist.
Das Fehlen von Programmierprotokollen bei einem bargeldintensiven Betrieb ist nur dann unschädlich, wenn Manipulationsmöglichkeiten ausgeschlossen sind. Die Kassen des Klägers waren aber manipulierbar. Dies hat ein Gutachten ergeben, das vom FG eingeholt worden ist. Unbeachtlich ist dabei, ob eine Manipulation einfach ist und von einem PC-Laien durchgeführt werden kann oder ob eine Manipulation schwierig ist und nur von einem EDV-Spezialisten vorgenommen werden kann. Auf eine tatsächliche Manipulation der Kasse kommt es ebenfalls nicht an.

Weil es keine Programmierprotokolle gab und die Kasse manipulierbar war, darum gab es einen auf den S*ck.

Wären die Programmierprotokolle vorhanden, dann wäre es trotz manipulierbarer Kasse korrekt gewesen.

**Codehunter**

GoBD etc. beziehen sich immer auf den aktuellen Stand der Technik zu der Zeit wo sie in Kraft treten. Du kannst dein Programm zertifizieren lassen, das gibt dir als Anbieter gewisse Sicherheit. Falls du Wartungsverträge anbietest, bist du natürlich in der Pflicht, auch neuere Angriffsvektoren zu verhindern.

Auf der anderen Seite gibt es Straftatbestände, wie z.B. Computersabotage nach 303b StGB oder Kassenmanipulation nach 379 AO. Das

KassenG könnte für dich auch relevant sein. Hier kommst du als lauterer Softwareanbieter aber allenfalls als Störer in Betracht, was im Allgemeinen durch Betriebshaftpflicht abgedeckt sein sollte.

Wie immer gilt: Ich nix Anwalt, alles nur Laienmeinung

**hanvas**

Zitat von mensch72:

..."Lange Rede, kurzer Sinn: Wie kann eine Datenbank so vor Änderungen geschützt werden, dass diese erkennbar sind?"...

Kurze&klare Antwort: GARNICHT, solange diese gemeinsam samt der Anwendung die dort liest&schriebt rein auf Kunden (kontrollierter) Hardware liegt

Man kann ein Protokoll aller Änderungen erstellen, viele DBs führen von Haus auf ein derartiges Transaktionslog. Das Log kann man in regelämäßigen Abständen exportieren, die exportierte Datei digital signieren.

Wenn man die Dateinamen so wählt das Lücken auffallen dann ist man schon ziemlich sicher. Praktisch ganz sicher ist man, wenn man Merkmale des Logs (beispielsweise Erstellungszeit, Dateiname etc.) an einen entfernten Server übermittelt, der diese Eigenschaften protokolliert.

Da nur Daten des Logs übermittelt werden, aber keine Nutzdaten hat man damit auch kein Datenschutzproblem.

cu Ha-Jö

**TiGü**

Und selbst wenn man als GoBD konformer Programmhersteller alles tut, damit alles seine Richtigkeit hat:
Sobald der Kunde zum Zeitpunkt X ein Image vom System zieht, dann irgendwas abrechnet und das Image zurückspielt, hat es diese Rechnung nie gegeben.
Da kannste machen was du willst.

Wirklich helfen kann da nur ein Fiskalisierungssystem, wie es viele europäische Länder inzwischen haben.
Mal sehen was die KassenSichV da bringt.
Es ist ja nur noch wenig Zeit bis zum 01.01.2020.
Ich hoffe ja auf eine Verschiebung wie damals in Österreich.

**Frickler**

Zitat von TiGü:

Und selbst wenn man als GoBD konformer Programmhersteller alles tut, damit alles seine Richtigkeit hat:
Sobald der Kunde zum Zeitpunkt X ein Image vom System zieht, dann irgendwas abrechnet und das Image zurückspielt, hat es diese Rechnung nie gegeben.
Da kannste machen was du willst.

Wirklich helfen kann da nur ein Fiskalisierungssystem, wie es viele europäische Länder inzwischen haben.
Mal sehen was die KassenSichV da bringt.
Es ist ja nur noch wenig Zeit bis zum 01.01.2020.
Ich hoffe ja auf eine Verschiebung wie damals in Österreich.

Genau. Siehe auch die

Stellungnahme der DFKA zum Thema:

Der Knackpunkt bei der Aussage des Gutachters war folgender: die Kassendatenbank war mit Microsoft Access erstellt. Bei dieser "Datenbank" ist eine spurlose Manipulation jederzeit problemlos möglich, dafür braucht man nicht mal "IT Experte" zu sein.

Ein Fiskalisierungssystem ist nicht zwingend notwendig. Die Datev bietet an, Kassenabschlüsse in der Datev Cloud zu speichern. Ich halte dies für hinreichend manipulationssicher.

**TiGü**

Zitat von Frickler:

Ein Fiskalisierungssystem ist nicht zwingend notwendig. Die Datev bietet an, Kassenabschlüsse in der Datev Cloud zu speichern. Ich halte dies für hinreichend manipulationssicher.

Das ist richtig, aber den Kassenabschluss macht man zum Ende des Umsatztages.

Sollte wirklich jemand die kriminelle Energie haben, dann hilft das manipulationssichere Abspeichern des Tagesabschlusses in einer Cloud auch nichts, wenn man beispielsweise ein paar Tausend Euro für ein Hochzeitsbankett mithilfe der "Snapshot erstellen-Rechnung erstellen und ausgeben-Snapshot zurückspielen"-Methode an der Steuer vorbeibringen möchte.

**Frickler**

Zitat von TiGü:

Zitat von Frickler:

Ein Fiskalisierungssystem ist nicht zwingend notwendig. Die Datev bietet an, Kassenabschlüsse in der Datev Cloud zu speichern. Ich halte dies für hinreichend manipulationssicher.

Das ist richtig, aber den Kassenabschluss macht man zum Ende des Umsatztages.

Sollte wirklich jemand die kriminelle Energie haben, dann hilft das manipulationssichere Abspeichern des Tagesabschlusses in einer Cloud auch nichts, wenn man beispielsweise ein paar Tausend Euro für ein Hochzeitsbankett mithilfe der "Snapshot erstellen-Rechnung erstellen und ausgeben-Snapshot zurückspielen"-Methode an der Steuer vorbeibringen möchte.

Gegen "2. Kasse im Hinterstübchen" hilft auch die beste Fiskalisierungslösung nichts. Selbst Systeme wie in Portugal (wo jeder Bon direkt beim Druck in die Finanzamts-Cloud hochgeladen wird) sind da machtlos. Darum gibt es in Ländern mit diesem System ja die Bonlotterie: unter allen ausgegebenen Bons werden am Monatsende Autos verlost. Da sind die Kunden schon scharf hinterher, einen gültigen Bon zu bekommen.

**Rollo62**

Zitat von mensch72:

..."Lange Rede, kurzer Sinn: Wie kann eine Datenbank so vor Änderungen geschützt werden, dass diese erkennbar sind?"...

Kurze&klare Antwort: GARNICHT, solange diese gemeinsam samt der Anwendung die dort liest&schriebt rein auf Kunden (kontrollierter) Hardware liegt

Das denke ich auch, siehe aktuelle Huawei 5G Diskussion um Hintertüren.
Natürlich sollte man besser mit den Behörden zusammenarbeiten, wie Schokohase richtig bemerkt,
sonst kommt es eben so wie in diesem Fall.

Evtl. wäre ein Ausweg die Software einfach entsprechend zertifizieren zu lassen ?
Dann läge die Verantwortung der richtigen Einschätzung bei dem Prüfer, und es muss womöglich keine offene Schnittstelle geben.