Probleme durch Programmierung eines inkorrekten Rechnungsprogramms zu erwarten?

[fkerber]

Hi,

ich habe als Auftragsarbeit für einen Kunden ein Verwaltungsprogramm (d.h. Kundenverwaltung, Produktverwaltung, Rechnungserstellung etc.) geschrieben.
Hinsichtlich der Rechnungsstellung habe ich mich an die gesetzliche "Vorgabe" gehalten, dass eine einmal geschriebene Rechnung nicht mehr verändert werden kann (Sonderfälle wie Tippfehler, offensichtlich falsches Rechnungsdatum etc. lassen wir mal außen vor). Aufgrund der internen Geschäftsabläufe ist allerdings oftmals eine Rechnungskorrektur wünschenswert. Aktuell muss dann die geschriebene Rechnung storniert werden und eine neue erstellt werden oder eine zusätzliche Rechnung geschrieben werden (je nach Situation).

Mein Kunde ist nun mit dem Wunsch an mich herangetreten, dass er gerne Rechnungen "nachträglich" editieren möchte, da das den Aufwand im Tagesgeschäft angeblich deutlich reduzieren würde.
Aus technischer Sicht ist das natürlich möglich - auf die möglichen rechtlichen Probleme (für meinen Kunden) habe ich (mündlich) hingewiesen.

Wenn ich nun diese Änderung am Programm umsetze - habe ich (aus eurer Sicht, ich weiß, keine Anwälte hier, keine Online-Rechtsberatung ) als Programmierer rechtlicherseits mit Problemen zu rechnen?
Irgendwas in Richtung "Ermöglichen von Steuerbetrug" oder was auch immer sich da irgendjemand ausdenken könnte?!

Ich will es mir mit dem Kunden nicht "verscherzen", sodass ich theoretisch kaum um die Änderung herumkomme - sollte ich mich irgendwie zusätzlich absichern? Wenn ja, wie?


Für ein paar Tipps (aus der Praxis) wäre ich dankbar!


Viele Grüße,
Frederic

[RandomDD]

Ich lehne mich jetzt mal GANZ weit aus dem Fenster:

da du die Situation genau kennst und weißt was er machen möchte (Rechnungen nachträglich editieren), würde ich sagen ist es im Fall des Falles eine Art Beihilfe zu X Y oder Z.

Ich bin kein Anwalt. Aber das erscheint mir recht logisch.

[fkerber]

Danke für deine Einschätzung.

Kurz noch, damit es da keine Missverständnisse gibt:
Es soll dabei nicht um Steuerbetrug gehen o.Ä. - also der Kunde hat nicht vor, dass zu tun.
Es geht mir nur um die Frage, ob es für mich problematisch sein könnte, dass man es rein theoretisch zu diesem Zweck "missbrauchen" könnte.
Natürlich kann man das als Unternehmer auch, wenn man seine Rechnungen in Word schreibt ...

Viele Grüße,
Frederic

[Uwe Raabe]

Mein Rechnungsprogramm, das laut eigener Angabe GoBD-konform ist, bietet mir das nachträgliche Ändern einer Rechnung mit folgender Frage an:

[CHackbart]

Was spricht dagegen einen Warnhinweis zu platzieren?

[fkerber]

Das ist ein guter Punkt - danke für den Input!
Wenn es ja einen (zumindest theoretischen) Grund gibt, in dem man die Rechnung noch "legal" editieren kann, dann ist ja gegen die Funktionalität an sich nichts zu sagen.
Das mit dem Hinweis werde ich dann auf jeden Fall aufnehmen.

Super, dass man selbst an einem sonnigen Sonntagmittag hier so schnell passende Antworten bekommt!


Viele Grüße,
Frederic

[jaenicke]

Wir machen das ganz einfach... die Rechnung wird im Hintergrund storniert und 1:1 neu erstellt. Die kann man dann normal editieren.

Wichtig ist aber nur, dass keine Rechnung editiert wird, zu der der Ausdruck bereits beim Kunden ist. Wenn der diese Rechnung wieder zurückgibt, sollte es auch in Ordnung sein.

Wenn ein entsprechender Warn hinweisen angezeigt wird, ist aber der Betreiber dafür verantwortlich.

Trotzdem sehe ich keinen Grund die Rechnung nicht im Hintergrund zu stornieren und eine neue zum Editieren anzubieten.

[mensch72]

wenn "Edit", dann macht es nur in der org. Rechnung Sinn, denn internes Storno + neue Rechnung ergäbe das (zusätzliche)Problem, das eine neue Rechnungsnummer vergeben werden müßte und diese eine "Rückwärtsrechnung" ist, wenn schon andere Sachen passiert sind und es gesamt nicht mehr chronologisch stimmig ist.

Ich hoffe, das es sich "nur" um Freitext Rechnungen handelt!... Bei Rechnungen welche mit Artikelpositionen aus einer WaWi korrespondieren zerhaut es bei Mengenänderungen den Bestand und bei Preisänderungen die Statistik der Durchschnitte z.B. vom Rohertrag... FA Prüfer sind nicht dummm und wissen wie sie schnell abtesten ob da eventuell was unpassend ist.

Für Sage/KHK gibt es spezielle "Korrektur-Tools", welche aber ganz tief im SQL-Server ansetzen, weil da dann zig Standard-Trigger und sonstige interne (Sicherheits)Funktionen der DB hart umgangen werden. Sowas als Bestandteil des normalen WorkFlow zu planen/nutzen... ich weiß nicht!

-> Eventuell wäre es besser, das Rechnungswesen dort auf "ProformaRechnungen" umzustellen und erst bei Zahlungseingang echte und zum Geldeingang passende Rechnungen zu erstellen.
-> "Sauber&Sicher" geht das aber eigentlich auch nur, wenn man mit "IST-Versteuerung" veranlagt wird. Da fällt im Gegensatz zur Sollversteuerung die Umsatzsteuer erst bei Geldeingang an. Die Umsatzsteuer ist allgemein das Hauptproblem bei Rechnungsänderungen, denn bei solch indirekten Steuern versteht das FA keinen Spaß.

[mm1256]

Zitat von Uwe Raabe:

Mein Rechnungsprogramm, das laut eigener Angabe GoBD-konform ist, bietet mir das nachträgliche Ändern einer Rechnung mit folgender Frage an:

Genauso handhabe ich das auch. Zusätzlich kann ich in meiner Software noch einstellen, bis zu welchem Rechnungsbetrag die Editierung erlaubt ist und wie viele Tage (1-5) nach dem Rechnungsdruck man den Editiervorgang starten kann. Diese Regelung ist auch benutzerabhängig konfigurierbar, d.h. der Anwender bzw. sein Administrator kann entscheiden, welche Benutzer überhaupt das Recht zum Editieren haben, und wie viele Tage. Somit kann man z.B. den Editiervorgang zur Chefsache machen, und nur von seinem Arbeitsplatz aus erlauben.

Anmerkung: Der konfigurierbare Zeitraum hat den Vorteil, dass man hier besser auf die individuellen Anforderungen im Betrieb eingehen kann. In einem Online-Handel ticken die Uhren anders als beispielsweise in einem Handwerksbetrieb.

2. Anmerkung: Rechnungs-Änderungen werden selbstverständlich protokolliert. Technische Umsetzung: Datum, Zeit, Benutzername und Arbeitsplatz werden in einem Memo-Feld bei den Auftragsdaten gespeichert.

Zitat von mensch72:

Ich hoffe, das es sich "nur" um Freitext Rechnungen handelt!... Bei Rechnungen welche mit Artikelpositionen aus einer WaWi korrespondieren zerhaut es bei Mengenänderungen den Bestand und bei Preisänderungen die Statistik der Durchschnitte z.B. vom Rohertrag... FA Prüfer sind nicht dummm und wissen wie sie schnell abtesten ob da eventuell was unpassend ist.

Das Problem hatte ich früher auch, es ist aber einfach lösbar. Bei jeder Position wird die (ab)gebuchte Menge zusätzlich mit geführt. Einfaches Beispiel: Der Kunde druckt eine Rechnung aus. Beim Gegenlesen/Einpacken der Ware/Kuvertieren stellt er fest, dass die Menge bei einer Position nicht passt. Also muss die Rechnung nochmals editiert und die Menge geändert werden. Und natürlich darf dann auch nur die Differenz-Menge gebucht werden. Das ist ein fast alltäglicher Vorgang den eine vernünftige WaWi können muss!

[bernau]

Zitat von Uwe Raabe:

Mein Rechnungsprogramm, das laut eigener Angabe GoBD-konform ist, bietet mir das nachträgliche Ändern einer Rechnung mit folgender Frage an:

Was ist schon GoDB-Konform. Ich habe noch nicht wirklich ein Dokument gesehen, in dem definitiv gesagt wird, wie ein Programm zu arbeiten hat. Letztendlich ist es immer eine Auslegungssache des Steuerprüfers.

Ein Kunde von mir wird grade geschätzt, weil mein Ladenkassenprogramm anscheinend nicht alles protokolliert. Ich protokolliere alle umsatzrelevanten Daten. Weil dort alles OK ist, wird eben die Mitarbeiterverwaltung bemängelt. Der Steuerprüfer wollte wissen, wann welcher Mitarbeiter angelegt wurde, wann dieser geändert wurde, welche Berechtigungen er zu welchem Zeitpunkt hatte.

Man kann eigentlich aus allen Buchungsdaten ersehen, welcher Mitarbeiter kassiert, storniert oder sonst was gemacht hat. Daraus kann man auch eigentlich herausfinden, wann der Mitarbeiter angelegt wurde und ober er bestimmte Berechtigungen hat. (Macht ja keinen Sinn, einen Mitarbeiter 12 Monate vor dem ersten Kassiervorgang anzulegen) Aber das war nicht gültig. Es muss der Zeitpunkt der Änderung ersichtlich sein.

Es wird sich auf ein Gerichtsurteil des BFH berufen, welches von 1995 ist. Da haben die Kassensysteme noch ganz anders ausgesehen.

Bei bisherigen Steuerprüfungen nie ein Problem. Jetzt aber schon.