Festschreibung, Storno, Objektsperre — Unveränderbarkeit ist Technik, kein Versprechen

Unveränderbarkeit ist der GoBD-Grundsatz mit dem größten Abstand zwischen Prospekt und Wirklichkeit. Fast jede Software „gewährleistet" sie. Die nützliche Frage lautet: Durch welchen Mechanismus — und was passiert, wenn man es trotzdem versucht?

Drei Mechanismen, drei Prüffragen

1. Festschreibung von Buchungen. Nach der Festschreibung darf kein normales Update mehr durchgehen — nicht „sollte nicht", sondern: die Schreiboperation wird abgewiesen. Korrekturen entstehen als Storno mit Spiegel: Die Gegenbuchung referenziert das Original, beides bleibt sichtbar. Prüffrage an den Anbieter: „Zeigen Sie mir, was passiert, wenn ich eine festgeschriebene Buchung ändere." Die richtige Antwort ist eine Fehlermeldung.

2. Unveränderbare Belegablage. Das Werkzeug heißt Objektsperre (Object Lock) mit Aufbewahrungsfrist auf dem Speicher, und es gibt sie in zwei Modi. Im Modus COMPLIANCE kann während der Frist niemand ein Original überschreiben oder löschen, auch kein Administrator. Im Modus GOVERNANCE kann es kein normaler Zugang — wer das Sonderrecht dafür hat, kann die Sperre aber aufheben. Konsequent gebaut, verweigert das System außerdem das SPEICHERN auf einem Speicher ohne Sperre. Prüffrage: „Welchen Modus nutzen Sie, und wer hat das Sonderrecht?"

FinMake nutzt die Objektsperre im Modus GOVERNANCE, und das Schreibtor verweigert jeden Speicher ohne Sperre samt Frist. Kein Weg in der Anwendung ändert oder löscht ein gesperrtes Original. Der Betreiber kann die Sperre mit dem Sonderrecht aufheben, etwa für eine Löschweisung nach Vertragsende; gegen einen Missbrauch dieses Rechts schützt die Sperre deshalb nicht.

3. Manipulationssichere Protokolle. Ein Audit-Log, das der Anwendungscode pflegt, ist so verlässlich wie der Anwendungscode. Stärker: verkettete Prüfsummen in der Datenbank selbst — jede Zeile trägt den Fingerabdruck ihrer Vorgängerin, nachträgliche Änderungen zerreißen die Kette sichtbar. Prüffrage: „Woran erkennt ein Prüfer, dass im Protokoll nichts nachträglich geändert wurde?"

Und die Nummernfolge

Kassenbuch und Rechnungsausgang brauchen lückenlose, fortlaufende Nummern — nicht als Konvention, sondern erzwungen: Die nächste Nummer wird vergeben, nie gewählt; eine Lücke ist ein sichtbarer Befund und kein stilles Loch.

Der Punkt

Jeder dieser Mechanismen lässt sich VORFÜHREN — am lebenden System, in fünf Minuten. Verlangen Sie die Vorführung statt der Zusicherung. Ein Anbieter, der die Ablehnung zeigt (das abgewiesene Update, den verweigerten Speicher), hat Unveränderbarkeit gebaut. Einer, der Folien zeigt, hat sie formuliert. Und fragen Sie nach dem Modus der Sperre: Die ehrliche Antwort nennt ihn.

Aktualisiert am 06.10.2026: Hier stand als Maßstab ein Ausschluss des Löschens, der nur im Modus COMPLIANCE gilt. FinMake nutzt GOVERNANCE, und das sagt der Absatz jetzt.