GoBD im SaaS-Billing: Festschreibung, Nachweis und acht Jahre

Ein Kunde firmiert im Herbst um und trägt den neuen Namen im Self-Service-Portal ein. Drei Monate später fragt die Buchhaltung nach einer Rechnung aus dem Frühjahr. Das Billing-System erzeugt das PDF neu, und auf der Rechnung steht jetzt der neue Firmenname. Keiner hat eine Rechnung bearbeitet, und trotzdem stimmt das Dokument im Archiv nicht mehr mit dem überein, das verschickt wurde.

Ein fast identischer Fall steht als Beispiel in den GoBD des Bundesfinanzministeriums, im Abschnitt zur Unveränderbarkeit: Steuersatz und Kundenname werden in den Stammdaten überschrieben, ohne Historie. Dieser Beitrag nimmt die GoBD-Grundsätze, die einen SaaS-Billing-Stack am stärksten treffen, und übersetzt sie in Prüfpunkte für Datenmodell und Betrieb: Unveränderbarkeit, Nachvollziehbarkeit, Aufbewahrung und Verfahrensdokumentation. Wenn Sie gerade ein Tool auswählen, finden Sie die Kriterienliste dafür im Beitrag GoBD-konforme Rechnungssoftware wählen.

Kein Zertifikat macht Ihr Billing-System GoBD-konform

Die Finanzverwaltung erteilt keine Positivtestate zur Ordnungsmäßigkeit eines Buchführungssystems, weder in der Außenprüfung noch per verbindlicher Auskunft. Ein „GoBD-Zertifikat“ eines Softwareanbieters kann bei der Auswahl helfen, bindet das Finanzamt aber nicht. Ob Ihre Abrechnung ordnungsgemäß ist, hängt an Konfiguration, Rechtevergabe, Updates und an der Art, wie Ihr Team mit Korrekturen umgeht.

Für einen SaaS-Stack heißt das: Die Ordnungsmäßigkeit verteilt sich über mehrere Systeme. Metering liefert Mengen, der Produktkatalog Preise, das Billing-System Rechnungen, der Zahlungsanbieter Zahlungsstatus, die Finanzbuchhaltung Buchungen. Jede Übergabe zwischen diesen Systemen ist eine Stelle, an der Information verloren gehen oder überschrieben werden kann.

Unveränderbarkeit: Korrekturen sind neue Datensätze

Die GoBD greifen § 146 Abs. 4 AO auf. Eine Buchung oder Aufzeichnung darf nicht so verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist. Änderungen und Löschungen müssen protokolliert werden. Im Billing betrifft das drei Stellen.

Die erste ist die Rechnung selbst. Solange sie ein Entwurf ist, darf sie sich ändern. Sobald sie eine Rechnungsnummer hat und verschickt ist, ist sie festgeschrieben. Ein falscher Betrag wird durch Storno und neue Rechnung oder durch eine Rechnungskorrektur mit Verweis auf das Original berichtigt, nie durch ein Update der bestehenden Zeile. Prüfen Sie konkret, ob Ihr Admin-Interface oder Ihre API eine festgeschriebene Rechnung noch per PATCH ändern lässt. Manche Tools erlauben das für „Notizen“ oder „Metadaten“, die anschließend auf dem PDF erscheinen.

Die zweite Stelle sind Stammdaten. Kundenname, Anschrift, USt-IdNr., Steuersatz und Preis müssen entweder zum Rechnungszeitpunkt in die Rechnung kopiert oder mit Gültigkeitszeitraum historisiert werden. Ein Datenmodell, das beides leistet, sieht etwa so aus:

Die dritte Stelle sind Nutzungsdaten. Liefert ein Produktteam nachträglich korrigierte Mengen, wird der alte Datensatz nicht überschrieben. Es entsteht ein Korrektur-Event mit Verweis auf das Original. Nur so lässt sich später zeigen, welche Menge abgerechnet wurde und warum die Gutschrift im Folgemonat existiert.

Nachvollziehbarkeit heißt: von der Rechnungszeile zum Event und zurück

Die GoBD verlangen, dass ein sachverständiger Dritter Geschäftsvorfälle in angemessener Zeit in ihrer Entstehung und Abwicklung verfolgen kann, progressiv und retrograd, für die gesamte Aufbewahrungsfrist. Für usage-basierte SaaS-Rechnungen ist das ein konkreter Test.

Retrograd: Auf der Märzrechnung steht „API-Calls: 48.120“. Lässt sich diese Zahl auf die einzelnen Events zurückführen, inklusive der verworfenen Duplikate und der Korrektur vom 2. April? Progressiv: Ein Event vom 14. März mit Idempotency-Key X. Auf welcher Rechnungszeile ist es gelandet, und in welcher Buchung im DATEV-Export? Wenn die Antwort für beide Richtungen ein manuelles Join über drei Exporte erfordert, ist die Kette in der Praxis nicht prüfbar.

Technische Logs allein reichen dafür selten. Ein Eintrag invoice.updated sagt einem Prüfer nichts. Er braucht den fachlichen Vorgang: wer, wann, welche Änderung, aus welchem Anlass, mit welcher Folge für Forderung und Umsatzsteuer.

Acht Jahre ab Jahresende: wann eine Rechnung gelöscht werden darf

Ausgangsrechnungen sind acht Jahre aufzubewahren (§ 14b UStG). Für Buchungsbelege gilt nach § 147 Abs. 3 AO ebenfalls acht Jahre. Bücher, Journale und Jahresabschlüsse bleiben bei zehn Jahren. Ein Lösch-Job im Billing muss deshalb zwischen Rechnungsdaten und den Buchungsdaten der Finanzbuchhaltung unterscheiden.

Die Frist beginnt mit dem Schluss des Kalenderjahres, in dem die Rechnung ausgestellt wurde. Ein Beispiel: Rechnung vom 14. März 2026, Fristbeginn 31. Dezember 2026, Fristende 31. Dezember 2034, frühester Löschtag 1. Januar 2035. Und auch dann nur, soweit die Rechnung nicht mehr für Steuern von Bedeutung ist, deren Festsetzungsfrist noch läuft, etwa während einer offenen Außenprüfung. Ein Lösch-Job, der stur „Rechnungsdatum plus acht Jahre“ rechnet, löscht diese Rechnung gut neun Monate zu früh.

Zwei Punkte betreffen speziell Billing-Systeme:

• Bei E-Rechnungen ist das strukturierte XML das Original. Die GoBD verbieten Umwandlungen, die die maschinelle Auswertbarkeit verringern. Ein Archiv, das nur das Sichtformat oder ein Bild aufbewahrt, reicht dann nicht.
• Ein Fakturierungsprogramm muss nicht jedes PDF ab Erstellung speichern, wenn es jederzeit ein inhaltsgleiches Doppel erzeugen kann. Voraussetzung nach GoBD: Stammdaten, AGB und das Layout des Briefbogens sind historisiert. Genau daran scheitert das Beispiel vom Anfang. Wer PDFs bei Bedarf neu rendert, braucht diese Historie. Wer sie nicht hat, archiviert die versendete Datei.

Verfahrensdokumentation für einen SaaS-Billing-Stack

Die Verfahrensdokumentation beschreibt, wie Daten entstehen, verarbeitet, gespeichert und reproduziert werden. Nach den GoBD besteht sie in der Regel aus vier Teilen. Für einen SaaS-Stack bedeuten sie konkret:

Der unterschätzte Punkt ist die Versionierung. Die Dokumentation muss für die gesamte Aufbewahrungsfrist zeigen, wie das System zu einem bestimmten Zeitpunkt gearbeitet hat. Ein Team, das wöchentlich deployt, braucht deshalb kein Dokument pro Release. Es braucht eine Änderungshistorie, die jede abrechnungsrelevante Änderung datiert: neue Rundungslogik, geänderte Steuerermittlung, ein neues Pflichtfeld in der XRechnung. Ein Changelog im Repository mit Verweis auf die Verfahrensdokumentation ist dafür oft der pragmatischste Weg.

Sechs Prüfungen, die Sie diese Woche machen können

Diese Tests brauchen keinen Prüfer, nur eine Testumgebung und einen Nachmittag:

1. Ändern Sie Name und Anschrift eines Testkunden. Rendern Sie eine alte Rechnung neu und vergleichen Sie sie mit der versendeten Datei.
2. Versuchen Sie, eine festgeschriebene Rechnung über Admin-Oberfläche und API zu ändern, auch Notiz- und Metadatenfelder.
3. Nehmen Sie eine usage-basierte Rechnungszeile und führen Sie sie bis auf die einzelnen Events zurück. Notieren Sie, wie lange das dauert.
4. Prüfen Sie, welche Datei Ihr Archiv bei E-Rechnungen aufbewahrt: das XML, das Sichtformat oder beides.
5. Lesen Sie die Bedingung Ihres Lösch-Jobs. Rechnet er ab Jahresende, und kennt er offene Festsetzungsfristen?
6. Suchen Sie in der Verfahrensdokumentation die letzte Änderung an der Steuerermittlung. Steht dort ein Datum?

Jeder Punkt, der durchfällt, ist eine konkrete Aufgabe mit klarem Ergebnis. Kontier deckt Usage Metering, Subscription Billing, XRechnung und prüfbare Exporte in einem System ab; was davon den deutschen Markt betrifft, steht auf der Seite Billing für Deutschland.