Wenn ein Update Ihre Rechnungen ändert: ein GoBD-Risiko

Ein Fall aus der Praxis, anonymisiert und auf das Lehrhafte reduziert: Ein Software-Update verändert bereits verschickte, fertige Rechnungen nachträglich. Nicht das Layout. Den Inhalt. In dem Fall, der mir begegnet ist, traf es gleich vier Belege auf einmal, durch ein einziges Update erneut an Kunden verschickt und inhaltlich verändert.

Die Reaktion des Anbieters ging am Kern vorbei. Sinngemäß: Es sei ein Einzelfall, nur ein Dokument, und im System sei die Rechnung ohnehin nicht als „gedruckt“ markiert gewesen. Dabei zählt nicht, was das System behauptet. Es zählt, was real existiert: Die Belege wurden erstellt, verschickt, gebucht, beim Kunden verarbeitet und liegen beim Steuerberater. Ein Druckstatus im System ändert daran nichts.

Ich sehe so etwas mit zwei Brillen: als Geschäftsführer, der weiß, was es heißt, für die eigenen Bücher geradezustehen und als Auditor, der die Integrität von Daten zum Beruf gemacht hat. Beide Brillen zeigen dasselbe Bild. Das ist kein Schönheitsfehler in der Software. Das ist ein Compliance-Problem mit Ansage.

Was eine Rechnung zu einer Rechnung macht

Eine Ausgangsrechnung ist kein Entwurf. Sobald sie ausgestellt und in der Buchführung festgeschrieben ist, ist sie ein Beleg und Belege unterliegen in Deutschland den GoBD, den Grundsätzen zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form. Eine der tragenden Säulen dieser Grundsätze heißt Unveränderbarkeit.

Unveränderbarkeit heißt nicht, dass nie etwas korrigiert werden darf. Sie heißt: Eine einmal festgeschriebene Buchung oder ein Beleg darf nicht mehr so verändert werden, dass der ursprüngliche Inhalt verschwindet, ohne dass die Änderung sichtbar bleibt. Korrekturen laufen nachvollziehbar, über einen Storno, einen Korrekturbeleg, eine protokollierte Änderung mit Datum und Verursacher. Niemals still. Niemals heimlich. Niemals durch ein Update im Hintergrund.

Wie das sauber aussieht, ist kein Hexenwerk. Stellt sich heraus, dass eine verschickte Rechnung falsch war, wird sie nicht überschrieben. Sie wird storniert, der ursprüngliche Beleg bleibt erhalten und sichtbar und es entsteht eine neue, korrigierte Rechnung mit eigener Nummer und eigenem Datum. Am Ende sieht jeder Prüfer beides: den Fehler und die Korrektur. Genau diese Spur ist der Kern. Ein Update, das den alten Inhalt einfach ersetzt, löscht die Spur und damit die Nachvollziehbarkeit.

Eine Rechnung, die nach dem Versand noch ihren Inhalt ändern kann, ist keine Rechnung mehr. Sie ist ein Entwurf mit Briefkopf.

Genau das ist hier passiert: Der Inhalt finalisierter Belege wurde nachträglich überschrieben. Damit ist die ursprüngliche Spur weg und mit ihr die Nachvollziehbarkeit, die ein Betriebsprüfer im Zweifel sehen will. Buchungsbelege wie Rechnungen müssen Sie seit dem Vierten Bürokratieentlastungsgesetz acht Jahre aufbewahren, davor waren es zehn; für Bücher, Inventare und Jahresabschlüsse bleibt es bei zehn Jahren. So oder so begleitet ein solcher Beleg den Unternehmer fast ein Jahrzehnt. Ein theoretisches Risiko ist das also nicht.

Und eine veränderte Rechnung bleibt selten allein. Sie steht in Beziehung zu dem, was der Kunde bereits erhalten hat, zur Zahlung, die darauf eingegangen ist, zur gebuchten Forderung und zur Umsatzsteuer, die ans Finanzamt gemeldet wurde. Verändert sich der Beleg nachträglich, passt er plötzlich nicht mehr zu all dem, was auf ihm aufbaut. Aus einem überschriebenen Dokument wird so schnell eine Kette von Abweichungen, die jemand erklären muss. Und dieser Jemand ist am Ende der Unternehmer, nicht die Software.

„Nur ein Dokument, nicht gedruckt“, warum beides nicht zählt

Zwei Einwände, die in solchen Fällen fast immer fallen, lohnen einen zweiten Blick, weil viele Unternehmer denselben Denkfehler machen. Erstens: Es sei ja nur ein Dokument. In diesem Fall waren es vier. Aber selbst wenn es eines gewesen wäre, für den Grundsatz der Unveränderbarkeit festgeschriebener Belege kennen die GoBD keine Bagatellgrenze. Ein veränderter Beleg ist ein veränderter Beleg.

Zweitens: Die Rechnung sei im System gar nicht als gedruckt markiert gewesen. Das ist die Logik der Software, nicht die Logik des Finanzamts. Ob ein Dokument steuerlich existiert, entscheidet kein technisches Häkchen im ERP. Es entscheidet die Wirklichkeit: Die Rechnung wurde erstellt, verschickt, gebucht, beim Kunden verarbeitet, beim Steuerberater abgelegt. Ein Systemstatus entscheidet nicht darüber, wofür Belege da sind.

Warum das ein Integritätsthema ist, nicht nur ein Steuerthema

In der Informationssicherheit gibt es drei Schutzziele: Vertraulichkeit, Integrität, Verfügbarkeit. In den Audits, die ich gemacht habe, schauen fast alle zuerst auf Vertraulichkeit, wer darf was sehen. Das mittlere Ziel wird dabei am häufigsten unterschätzt: Integrität. Sind die Daten korrekt, vollständig und vor unbemerkter Veränderung geschützt?

Ein Update, das Datensätze verändert, ohne dass es jemand freigegeben, getestet oder protokolliert hat, ist ein klassischer Integritätsvorfall. ISO/IEC 27001:2022 hält dafür konkrete Kontrollen bereit: ein geordnetes Änderungsmanagement (A.8.32 Change management), damit kein Update unkontrolliert in den Produktivbetrieb läuft. Eine lückenlose Protokollierung (A.8.15 Logging), damit jede Veränderung eine nachvollziehbare Spur hinterlässt. Und wer seine Software aus der Cloud bezieht, behält zusätzlich die Informationssicherheit bei der Nutzung von Cloud-Diensten (A.5.23) im Blick.

Im Kern ist das ein Test- und Freigabeproblem. Ein Update, das produktive Datensätze anfasst, gehört vorher in eine Testumgebung, mit echten Beispieldaten, mit einer Prüfung der Ergebnisse, mit einem Plan, wie man es zurückrollt, wenn etwas schiefgeht. Wird es stattdessen direkt in den Echtbetrieb ausgerollt und greift dabei auf bereits abgeschlossene Belege zu, überschreibt es Inhalte, die niemand mehr anfassen dürfte. Der Punkt ist nicht die Kontrollnummer. Der Punkt ist die Haltung dahinter: Wer Daten verarbeitet, muss dafür sorgen, dass sie sich nicht unbemerkt verändern. Ein Mechanismus, der finalisierte Belege still verändern kann, ist unabhängig von der Stückzahl ein strukturelles Risiko, ob er einen Beleg trifft oder hundert.

Genau deshalb ist „Einzelfall“ für mich kein beruhigendes Wort, sondern ein Alarmsignal. Wenn ein Update vier abgeschlossene Belege anfassen konnte, dann nicht, weil diese vier besonders waren, sondern weil die Schranke fehlte, die so etwas hätte verhindern müssen. Ein Auditor fragt an dieser Stelle nie zuerst nach dem Schaden, sondern nach der fehlenden Kontrolle. Der Schaden ist das Symptom. Die fehlende Schranke ist die Ursache.

„Das ist Ihre Wahrnehmung“ und warum dieser Satz falsch ist

Oft fällt dann sinngemäß der Satz, das sei doch nur die eigene Wahrnehmung. Bei mehreren veränderten Belegen, die schwarz auf weiß vorliegen, ist das keine Wahrnehmung. Das sind Fakten. Aber der Satz zeigt ein größeres Missverständnis, nämlich die Frage, wer am Ende verantwortlich ist.

Und die Antwort ist unbequem für jeden, der gehofft hat, die Verantwortung mit der Software-Lizenz mitgekauft und abgegeben zu haben: Die Verantwortung für ordnungsgemäße Bücher liegt beim Unternehmer. Nicht beim Anbieter. Die GoBD sind hier eindeutig, wer Aufzeichnungs- und Aufbewahrungspflichten an einen Dienstleister oder eine Software auslagert, bleibt selbst dafür verantwortlich. Der Anbieter haftet vielleicht zivilrechtlich für seinen Fehler. Gegenüber dem Finanzamt steht der Unternehmer gerade.

Die Verantwortung für ordnungsgemäße Bücher können Sie nicht per Software-Lizenz abgeben. Sie bleibt bei Ihnen.

Die richtige Reaktion ist deshalb nicht, klein beizugeben, sondern eine dokumentierte Fehleranalyse zu verlangen. Nicht aus Rechthaberei. Sondern weil am Ende der Unternehmer erklären muss, warum sich finalisierte Belege nachträglich verändert haben. Diese Erklärung will niemand improvisieren müssen.

Was das mit Lieferantenaudits zu tun hat

Hier schließt sich der Kreis zum Audit. Ihr ERP-Anbieter, Ihr Cloud-Dienstleister, Ihr Buchhaltungssystem, das sind Lieferanten. Und Lieferanten, die Ihre Belege, Ihre Buchungen und Ihre Kundendaten verarbeiten, sind ein Teil Ihrer eigenen Compliance. Wenn deren System Ihre Daten verändert, ist das Ihr Problem, nicht nur deren.

Genau hier setzt ein Lieferanten- oder Second-Party-Audit an. Der Begriff klingt sperrig, meint aber etwas Einfaches: Sie prüfen einen Lieferanten, von dem Sie selbst abhängen, nicht, um ein Zertifikat auszustellen, sondern um Ihr eigenes Risiko zu kennen. Das ist etwas anderes als ein Third-Party-Audit, bei dem eine unabhängige Zertifizierungsstelle ein Unternehmen für ein Zertifikat prüft. Beim Lieferantenaudit geht es nicht um den Stempel, sondern um Ihre Sicherheit und nicht darum, ob die Software hübsch aussieht, sondern ob der Anbieter die Integrität Ihrer Daten ernst nimmt. Am besten vor der Vertragsunterschrift, nicht nach dem Schaden.

Die Fragen sind simpel und werden trotzdem selten gestellt:

• Gibt es eine Verfahrensdokumentation, die zeigt, wie das System Belege erzeugt, speichert und unveränderbar hält?
• Wie läuft das Änderungs- und Update-Management? Werden Updates getestet, bevor sie produktive Daten berühren?
• Sind ausgehende Belege gegen nachträgliche stille Änderung geschützt, das, was die Branche revisionssicher nennt?
• Wird jede Änderung an einem Datensatz protokolliert, mit Zeitpunkt und Verursacher?
• Wer trägt im Fehlerfall welche Verantwortung und steht das im Vertrag, nicht nur im Verkaufsgespräch?

Und wenn der Anbieter auf diese Fragen keine klaren Antworten hat? Dann ist das selbst schon die Antwort. Kein Anbieter muss perfekt sein, aber er muss zeigen können, wie er mit Ihren Belegen umgeht. Wer das vor dem Kauf klärt, führt das Gespräch in Ruhe. Wer es erst nach einem fehlerhaften Update klärt, führt es unter Druck, mit einem Anbieter, der die Tragweite zunächst nicht erkannt hat.

Was Sie aus diesem Fall mitnehmen sollten

Sie müssen kein Auditor sein, um sich zu schützen. Sie müssen nur aufhören, Ihrer Software blind zu vertrauen. Software ist ein Werkzeug. Kein Ersatz für Sorgfalt und kein Ersatz für die Verantwortung, die bei Ihnen bleibt.

Wenn Sie nur eine Sache mitnehmen, dann diese: Nehmen Sie sich Ihre eigene Buchhaltungs- und ERP-Landschaft vor und stellen Sie die unbequeme Frage, könnte ein Update bei Ihnen dasselbe anrichten? Lassen Sie sich die Verfahrensdokumentation geben. Testen Sie an einem Musterbeleg, ob sich eine festgeschriebene Rechnung still ändern lässt. Klären Sie, ob jede Änderung protokolliert wird. Und sichern Sie ausgehende Belege unabhängig vom System, damit Sie eine zweite Spur haben. Wenn Sie die Antworten nicht kennen, kennen Sie ein Risiko nicht. Und die unbekannten Risiken sind im Audit wie im Betrieb am Ende immer die teuersten.