Zum Inhalt springen
Restow Docs

GoBD und andere Aufbewahrungsvorschriften

Das Archiv von Restow (siehe Archivierung und Journaling, verfügbar seit 0.1.0) ist für den GoBD-konformen Einsatz ausgelegt. Diese Seite legt dar, was das konkret bedeutet, Anforderung für Anforderung, und wirft einen Blick auf einige andere Aufbewahrungsvorschriften, nach denen gelegentlich gefragt wird (SEC Rule 17a-4, FINRA, Schweiz, Österreich), ohne für eine davon Konformität zu beanspruchen.

Anforderung → Restow-Mechanismus

Abschnitt betitelt „Anforderung → Restow-Mechanismus“
GoBD-Anforderung Restow-Mechanismus Stand
Vollständig und richtig Journaling erfasst eine Kopie, bevor ein Nutzer etwas ändern oder löschen kann; aus Dateien importierte Mail wird beim Import archiviert und ab dann gezählt. Seit 0.4.4 werden auch Kopien, die ein Mailanbieter weiterleitet, echt erfasst, und Graph-Erfassung und IMAP-Archivierung erfassen zeitnah aus dem Postfach, als solche gekennzeichnet Verfügbar (Journaling, Weiterleitung, Graph-Erfassung und IMAP-Archivierung ab Business; Import mit Archivierung in jeder Edition)
Zeitgerecht Erfassung geschieht, bevor das Empfänger-Postfach verändert werden kann (Journaling), nicht nach einem späteren Zeitplan. Weitergeleitete Kopien entstehen im Transport des Anbieters. Eine zeitnahe Erfassung aus dem Postfach (Graph, IMAP-Archivierung) lässt eine Lücke, in der eine Mail verschoben oder gelöscht werden kann, und Restow sagt dafür keine Vollständigkeit zu Verfügbar (Business)
Geordnet, nachvollziehbar Suche über Betreff, Adressen und (bei importierter Mail) Nachrichtentext, Metadaten je Element, EML-/ZIP- oder MBOX-Export mit Manifest und Prüfsummen, Nachweisbericht als JSON über die Integrations-API Verfügbar (jede Edition); Datei mit Kettenwerten (CHAIN.txt) und signierter PDF-Nachweisbericht geplant
Unveränderbar Prüfkette über jedes archivierte Element mit Kettenprüfung (manipulationserkennbar; seit 0.3.1 auch gegen Tagesanker, die jede Nacht versiegelt werden, mit einer optionalen Stichprobe, die aus dem Speicher zurückgelesen wird) und eine Anwendung ohne Weg, ein Element vor Fristablauf zu ändern oder zu löschen. Auf S3 mit Object Lock sind die Datensätze der Archivelemente bis zum Ende der Aufbewahrung gesperrt, und der Nachrichteninhalt ist zusammen mit den Backup-Daten gesperrt, wo unveränderbare Backups eingeschaltet sind (für den Zeitraum dieser Einstellung, nicht bis zum Aufbewahrungsdatum des Archivs) Hash-Kette, Prüfung und Unveränderbarkeit auf Anwendungsebene verfügbar; Object Lock für den Inhalt nur über die Einstellung unveränderbarer Backups des Repositorys; tägliche externe Anker und Object Lock, das der eigenen Aufbewahrung des Archivs folgt, geplant
Maschinell auswertbar Ursprungsformat erhalten (eine E-Mail bleibt eine E-Mail), Suche über Betreff, Adressen und Nachrichtentext importierter Mail; der Inhalt von Anhängen wird nicht durchsucht Verfügbar
Ursprungsformat Byte-genaue Speicherung des Originals als message/rfc822, keine konvertierte oder ausgedruckte Kopie (eine importierte MSG-Datei enthält keine E-Mail in dieser Form und wird als EML neu aufgebaut) Verfügbar
Verfahrensdokumentation Eine Vorlage je Mandant, aus der tatsächlichen Konfiguration vorausgefüllt (Erfassungsweg, Speicher, Verschlüsselung, Zugriffsrechte, Aufbewahrung, Löschverfahren, Kontrollen), die die Organisation vervollständigt. Das vollständige Dokument samt organisatorischer Prozesse bleibt nach GoBD die eigene Verantwortung der Steuerpflichtigen Geplant
Änderungs-/Löschprotokollierung Jede Löschung durch den Aufbewahrungslauf wird samt den Hashes des Elements in das hash-verkettete Audit-Log geschrieben Verfügbar (Business)
Festgelegte Aufbewahrungsfrist Eine feste Vorgabe von 8 Jahren, die am 31. Dezember des Jahres des Eingangs plus 8 Jahre endet. Das deckt die 6 Jahre für Handelsbriefe und die 8 Jahre für Buchungsbelege (seit 2025) ab, nicht die 10 Jahre für Bücher und Jahresabschlüsse; eine andere Frist lässt sich in 0.4.7 über keine Oberfläche und keine API setzen; der durchgesetzte Löschlauf braucht Business Feste Vorgabe verfügbar (jede Edition); andere Fristen noch nicht einstellbar; durchgesetzter Löschlauf verfügbar (Business)
Legal Hold (selbst keine GoBD-Anforderung, aber oft nötig neben der Aufbewahrung) Je Mandant oder je Postfach, mit Begründung, auditiert; blockiert Löschung (ein Hold auf ein Suchergebnis ist nicht verfügbar) Verfügbar (Business)
Zugriffskontrolle, auditierter Zugriff Das Archiv ist für Mandanten-Administrationen da; Suchen und gelesene Elemente werden ins Audit-Log geschrieben. Rollenbezogene Suche (Endnutzer, Provider-Admin mit Vier-Augen-Freigabe) ist geplant Auditierter Administrationszugriff verfügbar; rollenbezogene Suche geplant

Die archivspezifischen Mechanismen in dieser Tabelle (die, um die es bei „unveränderbar“ und „zeitgerecht“ nach GoBD eigentlich geht) sind ab 0.1.0 enthalten, soweit als verfügbar markiert, der Rest ist geplant; das vollständige Design steht unter Archivierung und Journaling, der Stand unter Archivierung. Getrennt vom Archiv verschlüsselt und isoliert Restow schon heute die Daten jedes Mandanten; jeder Lese-, Restore- oder Export-Zugriff wird in jeder Edition im manipulationserkennbaren (Hash-Kette) Audit-Log aufgezeichnet (wer, wann, was, in wessen Auftrag, von welcher IP). Die Audit-Log-Ansicht (Liste, Filter, Eintragsdetails und Kettenprüfung) ist mit Business und Service Provider enthalten, und seit 0.3.1 ebenso der Audit-Log-Export (CSV, JSON mit Hashes). Siehe Audit-Log.

Eine feste Aufbewahrungsfrist ist auch nicht automatisch das letzte Wort: Nach § 147 Abs. 3 AO muss ein Beleg länger aufbewahrt werden, solange er für eine noch nicht bestandskräftige Steuerfestsetzung von Bedeutung ist. Ein Löschlauf, der immer starr nach einer festen Frist löscht, ohne das zu prüfen, könnte zu früh löschen. Diese Prüfung vorzunehmen, etwa mit einem Legal Hold (Business), ist die eigene Entscheidung Ihrer Organisation, nichts, was Restow automatisiert.

Ist WORM-Speicher erforderlich?

Abschnitt betitelt „Ist WORM-Speicher erforderlich?“

Nicht ausdrücklich. Randziffer 110 der GoBD nennt Zugriffsberechtigungskonzepte als Beispiel einer organisatorischen Maßnahme, die Unveränderbarkeit unterstützen kann, neben Hardware-Maßnahmen (manipulationssichere Medien) und Software-Maßnahmen (Schreibsperren, Löschmarkierungen, automatische Protokollierung, Versionierung). Dieselbe Randziffer stellt aber auch fest, dass die Aufbewahrung in einem gewöhnlichen Dateisystem die Unveränderbarkeit „regelmäßig nicht“ erfüllt, sofern nicht zusätzliche Maßnahmen das sicherstellen. Das Standard-Archivziel in Restow ist das lokale Volume, auf dem die Anwendung die Unveränderbarkeit erzwingt (kein Weg, ein Element vor Fristablauf zu ändern oder zu löschen, die Prüfkette, Zugriffsbeschränkung, Löschprotokollierung): die Art „zusätzlicher Maßnahmen“, die Rz. 110 meint. Hardware-WORM für archivierte Nachrichteninhalte, das der eigenen Aufbewahrung des Archivs folgt (S3-kompatibles Object Lock, COMPLIANCE-Modus, für den ganzen Aufbewahrungszeitraum), ist genau deshalb geplant. Was es heute gibt: Auf S3 mit Object Lock sind die Datensätze der Archivelemente bis zum Ende der Aufbewahrung gesperrt, und seit 0.4.0 kann eine Administration für ein Repository unveränderbare Backups einschalten, was die Packs mit dem Nachrichteninhalt zusammen mit den Backup-Daten sperrt, für den dort eingestellten Zeitraum (1 bis 3650 Tage, verlängert, solange die Packs verwendet werden). Das ist eine rollierende Sperre, keine Sperre bis zum Aufbewahrungsdatum, und sie wurde gegen einen nachgebauten S3-Dienst getestet, noch nicht gegen einen echten. Auf lokalen und NFS-Zielen erzwingt die Anwendung die Unveränderbarkeit, und die Oberfläche kennzeichnet solche Ziele mit „Kein Hardware-WORM“; die vollständige Aussage steht unter Archivierung und Journaling. Ob diese Maßnahmen für Ihre Situation ausreichen, muss Ihre eigene Steuerberatung oder Prüfungsstelle beurteilen, nicht Restow.

Außerhalb Deutschlands sieht es in einem konkreten Fall anders aus. Die US-SEC Rule 17a-4(f) regelt elektronische Aufzeichnungen für Broker-Dealer: Sie verlangt entweder ein WORM-Medium („non-rewriteable, non-erasable“) oder, seit den am 12.10.2022 verabschiedeten Änderungen (wirksam 03.01.2023, Compliance-Datum 03.05.2023), eine „Audit-Trail-Alternative“: ein System, das ein geändertes oder gelöschtes Original wiederherstellen kann. Beide Wege verlangen zusätzlich eine Verpflichtungserklärung gegenüber der Aufsicht, die seit den Änderungen 2022 auch eine benannte Führungskraft abgeben kann, nicht nur eine benannte dritte Partei. Die FINRA Rule 4511 übernimmt für ihre Mitglieder denselben elektronischen Speicherstandard aus 17a-4 per Verweis, plus eine 6-Jahres-Standardfrist für jede Aufzeichnung ohne eigene festgelegte Frist.

Diese Vorschrift gilt für US-Broker-Dealer, FINRA-Mitglieder und, nach demselben Regelwerk von 2022, Security-Based-Swap-Dealer und größere Marktteilnehmer (Rule 18a-6). Sie hat keine Bedeutung für ein deutsches (oder anderes EU-)Unternehmen, das gewöhnliche Mail nach GoBD archiviert. Sollte sie für Sie dennoch relevant sein: Die Erfüllung von Rule 17a-4(f) ist eine eigene Prüfung, die Ihre Organisation mit eigener Rechtsberatung und Prüfungsstelle klären müsste, kein Zertifikat, das dieses Produkt ausstellt.

Ein paar weitere Vorschriften, kurz

Abschnitt betitelt „Ein paar weitere Vorschriften, kurz“
  • Schweiz (Art. 958f OR, konkretisiert durch die GeBüV, die Verordnung über die Führung und Aufbewahrung der Geschäftsbücher): Geschäftsbücher, Buchungsbelege und Geschäftskorrespondenz werden 10 Jahre ab Ende des Geschäftsjahres aufbewahrt. Bücher und Belege dürfen elektronisch oder auf vergleichbaren Datenträgern geführt werden (Art. 958f Abs. 3 OR); der Geschäftsbericht und der Revisionsbericht müssen schriftlich und unterzeichnet aufbewahrt werden (Art. 958f Abs. 2 OR). Die elektronische Option deckt diese beiden nicht ab. Art. 9 GeBüV legt die Medienvorgaben für die elektronische Option fest: entweder ein unveränderliches Medium, oder ein veränderliches Medium in Verbindung mit Integritätsverfahren (zum Beispiel digitale Signaturen), einer nachweisbaren Aufbewahrungszeit (zum Beispiel Zeitstempel) und dokumentierten Verfahren. Es gibt also eine WORM-ähnliche Option, aber auch eine Alternative aus veränderlichem Medium plus Kontrollen, kein striktes WORM-Gebot.
  • Österreich (BAO § 132): 7 Jahre für die meisten Unterlagen (für manche gelten längere Fristen, etwa bei Grundstücksbezug bis zu 22 Jahre), verlängert, solange ein Dokument für ein anhängiges Steuerverfahren relevant bleibt; die Frist beginnt mit Ende des Kalenderjahres, für das die Eintragungen vorgenommen wurden oder auf das sich die Unterlagen beziehen.

Keine der beiden ist ein Ziel, auf das Restows Design speziell ausgerichtet wurde. Die oben genannten Mechanismen (Journaling, Prüfkette, Aufbewahrungsrichtlinie, Legal Hold) sind grob dieselbe Art von Maßnahme, die auch diese Gesetze verlangen, aber Restow beansprucht keine Erfüllung der spezifischen Anforderungen einer dieser Vorschriften.

Was Restow nicht behauptet

Abschnitt betitelt „Was Restow nicht behauptet“

Restow behauptet keine Zertifizierung, Konformität oder Compliance mit GoBD, SEC Rule 17a-4, FINRA, SOC 2, ISO oder einem anderen Standard: kein Software-Produkt kann das für Sie zertifizieren. Die GoBD-Randziffern 179-181 stellen ausdrücklich fest, dass die Finanzverwaltung keine Positivtestate erteilt (weder im Rahmen einer Außenprüfung noch als verbindliche Auskunft), und dass das Zertifikat eines Dritten die Finanzverwaltung nicht bindet. Restow sagt stattdessen: Das Archiv ist für den GoBD-konformen Einsatz ausgelegt, mit den auf dieser Seite und unter Archivierung und Journaling genannten konkreten Maßnahmen. Ob ein konkreter Einsatz die Pflichten Ihrer Organisation tatsächlich erfüllt (nach GoBD oder einer anderen Vorschrift), kann nur Ihre eigene Steuerberatung, Prüfungsstelle oder Rechtsberatung für Ihre konkrete Situation bestätigen.

Quellen

Abschnitt betitelt „Quellen“

Weiterlesen

Abschnitt betitelt „Weiterlesen“

Restow 0.4.7 beta: Produktseite · Preise · Quellcode (Apache 2.0) · Discord · Feedback (englisch)

Impressum & Datenschutz