Skip to content

GoBD System-Audit & Hash-Chain Ledger

Das Compliance- und Revisionsmodul von CaterOS gewährleistet die lückenlose Einhaltung der Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD).


1. Gesetzliche Grundprinzipien der GoBD

Die Finanzverwaltung verlangt für alle steuerrelevanten digitalen Aufzeichnungen vier Kernanforderungen:

  1. Nachvollziehbarkeit & Nachprüfbarkeit: Jeder Geschäftsvorfall muss von der Entstehung bis zur Verbuchung lückenlos dokumentiert sein.
  2. Wahrheit, Klarheit & fortlaufende Aufzeichnung: Kassenvorgänge, Rechnungen und Statuswechsel sind zeitgerecht zu erfassen.
  3. Unveränderbarkeit: Buchungen und Belege dürfen weder gelöscht noch unprotokolliert überschrieben werden.
  4. Aufbewahrungspflicht: Alle digitalen Originale (inklusive strukturierter XML-Rechnungsdatensätze) sind im Originalformat revisionssicher aufzubewahren.

2. Der kryptografische PostgreSQL Hash-Chain Ledger

text
[Genesis-Prüfsumme] ➔ [Ereignis 1: Rechnung erstellt] ➔ [Ereignis 2: Festgeschrieben] ➔ [Ereignis 3: Zahlung verbucht]
     (Hash 0)                    (SHA-256 Hash 1)                (SHA-256 Hash 2)                (SHA-256 Hash 3)

Funktionsweise der revisionssicheren Verkettung

  • Kryptografische Verkettung (SHA-256): Bei jedem steuer- und abrechnungsrelevanten Vorgang berechnet das System automatisch einen eindeutigen SHA-256 Hashwert über die Beleginhalte und verkettet diesen untrennbar mit dem Hash des unmittelbar vorangegangenen Eintrags.
  • Transaktionssicherheit & Parallelitätsschutz: Zur Verhinderung von Race Conditions oder konkurrierenden Schreibzugriffen wird jede Transaktion mandantenspezifisch auf Systemebene serialisiert.
  • Append-Only Schutz (Unveränderbarkeit): Eine strikte Systemsperre unterbindet nachträgliche Änderungen oder Löschungen von Audit-Einträgen vollständig. Eine nachträgliche Manipulation der Kette ist mathematisch ausgeschlossen.

3. Beleg-Snapshots & Löschschutz (Immutability)

Das System unterscheidet kaufmännisch zwischen veränderbaren Arbeitsentwürfen und festgeschriebenen Buchungsbelegen:

Entwürfe (Status: DRAFT)

  • Befinden sich in der Bearbeitung und stellen noch keine kaufmännische Verbindlichkeit dar.
  • Dürfen bei Fehlern oder Testkalkulationen physisch gelöscht werden, ohne die Rechnungsnummernfolge zu beschädigen.

Festgeschriebene Rechnungen (Status: SENT, PAID, CANCELLED)

  • Beim Übergang in den Status SENT rastet die GoBD-Festschreibung ein.
  • Sämtliche Absenderstammdaten, Kundenanschriften, Positionen, Steuersätze und das generierte E-Rechnungs-XML werden in einem unveränderlichen Beleg-Snapshot fixiert.
  • Physisches Löschen über die API oder das Benutzerinterface ist dauerhaft blockiert.
  • Korrekturen erfolgen ausschließlich über offizielle Storno- oder Korrekturbelege (Typ 381).

4. Revisionssicherer Export & Betriebsprüfung

Im Rahmen einer steuerlichen Betriebsprüfung (Außenprüfung oder Kassennachschau) stellt das System alle relevanten Datenprüfpfade bereit:

  • Strukturierte XML-Originale: Dauerhafte Verfügbarkeit der unveränderten XRechnung- und Factur-X-Dateien im Belegarchiv.
  • DATEV EXTF-Protokolle: Lückenloser Nachweis übermittelter Buchungsstapel.
  • Prüfpfad-Verifikation: Mathematische Verifizierbarkeit der Hash-Kette zur Bestätigung der Unveränderbarkeit gegenüber den Prüfern der Finanzverwaltung.