GoBD-konforme Rechnungsstellung

**bernau**

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

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

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

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

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

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

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.