paperless-ngx GoBD-konform nutzen
- Christian Süßenguth
- Kurz notiert
Direkt nach der Installation ist das großartige Open Source-Dokumentenmanagementsystem paperless-ngx leider noch nicht GoBD-konform, da es normalen Benutzer:innen möglich ist, Dokumente unwiderruflich aus dem Archiv herauszulöschen.
Die GoBD fordert jedoch, dass archivierte Belege "nicht nachträglich veränderbar sind". Um das schnell und einfach zu bewerkstelligen, empfehle ich die folgenden technischen und organisatorischen Maßnahmen (sog. TOMs), welche auch in deiner Verfahrensdokumentation festgehalten werden müssen.
Haftungsausschluss
Dieser Artikel beschreibt meinen praxisorientierten Ansatz, die Ziele aus der GoBD mit freier Software wie paperless-ngx umzusetzen. Dennoch handelt es sich hier nicht um eine anwaltlich abgesicherte Beratung, die ein gewisses Restrisiko mit sich bringt.
Auch wenn meine Argumentationen schlüssig und in sich stimmig sind, übernehme ich für den hier angebotenen Weg keine Gewährleistung und auch keine rechtliche Verantwortung. Am Ende bist du als Unternehmer:in selbst dafür verantwortlich, die GoBD rechtssicher umzusetzen. Entsprechende Informationen zu den Anforderungen der GoBD findest du gut zusammengefasst im GoBD-Praxisleitfaden der Kanzlei PSP.
Inhaltsverzeichnis
Voraussetzungen
Eigene Instanz
Berechtigungsmanagement
Taggen statt Löschen
Papierkorb konfigurieren
Logdateien konfigurieren
Prozessüberlegungen und Nachteile
Automatische Papierkorb-Leerung deaktivieren
Automatische Papierkorb-Leerung auf 8/10 Jahre setzen
Automatische Papierkorb-Leerung nutzen
Geschicktere Lösung
Voraussetzungen
Eigene Instanz
Lege dir eine eigene Instanz von paperless-ngx an, die ausschließlich für aufbewahrungspflichtige Belege (z.B. Rechnungen, Angebote usw.) gedacht ist. Archiviere darin keine sonstigen Dokumente, sondern lege dir dafür wiederum eine eigene Instanz an.
Das hat den Vorteil, dass du im Falle einer Steuerprüfung das gesamte System freigeben kannst, ohne dass die Prüfer:in andere Dokumente zu Gesicht bekommt. Auch aus DSGVO-Gesichtspunkten ist das ein wichtiger Punkt, da durch Fehler in der Software oder bei der Berechtigungsvergabe Mitarbeitende deines Unternehmens, die z.B. nur für die Buchhaltung zuständig sind, versehentlich Zugriff auf andere Dokumente wie Verträge oder gar private Dokumente erhalten könnten.
Durch eine Trennung der Systeme (Organisatorische und technische Maßnahme zugleich) kannst du das wirkungsvoll verhindern.
Berechtigungsmanagement
Grundsätzlich solltest du nur als eingeschränkter Benutzer am System arbeiten, nicht als Administrator (eig. selbstverständlich 😉). Desweiteren solltest du den normalen Benutzern über die Berechtigungsverwaltung die Löschberechtigung entziehen. Somit können weder Mitarbeitende, noch das Steuerberatungsunternehmen oder eine Steuerprüfer:in versehentlich Belege löschen.
Taggen statt Löschen
Führe stattdessen einen Tag namens LÖSCHEN!
ein, welches diese Personen einem Dokument zuweisen können, wenn es beispielsweise ein (nicht automatisch erkanntes) Duplikat ist.
In regelmäßigen Abständen kannst du dich dann als Administrator einloggen und die Belege löschen bzw. in den Papierkorb verschieben. Somit ist auch das 4-Augen-Prinzip gewahrt, es kann also nie etwas "versehentlich" gelöscht werden.
Das Intervall für die automatische Löschung von Dokumenten aus dem Papierkorb liegt standardmäßig bei 30 Tagen und kann mit der Variable PAPERLESS_EMPTY_TRASH_DELAY
entsprechend angepasst werden.
Papierkorb konfigurieren
Die Konfigurationsvariable PAPERLESS_EMPTY_TRASH_DIR
für den Papierkorb solltest du so konfigurieren, dass aus dem Papierkorb vollständig gelöschte Dokumente auf Ebene des Dateisystems in einem gesonderten Archivordner landen. In Kombination mit dem Log (siehe nächster Punkt) sind damit mehr als ausreichend technische und organisatorische Maßnahmen eingeführt, eine Löschung aktiv zu verhindern bzw. zu dokumentieren.
Hinweis
¹ Die Dokumente können aus dem gesonderten Archivordner von einem Administrator auf Dateisystemebene zwar immer noch händisch gelöscht oder verändert werden und die Logs könnten theoretisch ebenfalls frisiert werden, doch das erfordert ein hohes Maß an krimineller Energie und ist bei proprietären Systemen mit entsprechendem Aufwand ebenfalls möglich. Da in der IT nichts 100%ig ist – also auch keine Kaufsoftware – kauft man sich mit einem als GoBD-konform vertriebenen System in erster Linie eine Haftungsverschiebung auf den Softwarehersteller, keine 100%ige Gewährleistung, dass die Software alle möglichen Manipulationen wirkungsvoll verhindert.
Da ich als Unternehmer – wie hoffentlich andere Unternehmer:innen auch – nach dem Prinzip des Ehrbaren Kaufmanns¹ agiere, stehen derartige Manipulationen überhaupt nicht zur Debatte.
Ehrbarer Kaufmann
¹ [Das Prinzip des] Ehrbaren Kaufmanns steht für ein ausgeprägtes Verantwortungsbewusstsein für das eigene Unternehmen, für die Gesellschaft und für die Umwelt. Ein Ehrbarer Kaufmann stützt sein Verhalten auf Tugenden, die den langfristigen wirtschaftlichen Erfolg zum Ziel haben, ohne den Interessen der Gesellschaft entgegenzustehen. Er wirtschaftet nachhaltig.
Logdateien konfigurieren
Standardmäßig ist der sog. Audit-Trail aktiviert, wodurch sämtliche Vorgänge an einem Dokument im System dokumentiert werden (konfigurierbar über PAPERLESS_AUDIT_LOG_ENABLED
). Das ist schonmal wichtig und nötig, um Veränderungen an den Dokumenten selbst festzuhalten.
Allerdings kann man diesen Audit-Trail für gelöschte Dokumente aus dem Papierkorb nur einsehen, wenn man die Dokumente manuell wiederherstellt (und anschließend wieder löscht). Kein besonders geschicktes Konzept wenn man bedenkt, dass das für einen Archivierungszeitraum von 10 Jahren (ab 01.01.2025 8 Jahre) aufrechterhalten werden soll und im Papierkorb sehr unübersichtlich wird, da alle Dokumente im Papierkorb in einer flachen Struktur und nur mit dem Titel abgelegt werden.
Nehmen wir dennoch an, wir möchten am integrierten Löschkonzept von paperless-ngx festhalten und die Dokumente werden nach einer festgelegter Zeitspanne (konfigurierbar über PAPERLESS_EMPTY_TRASH_DELAY
) bzw. manuell aus dem System gelöscht. Daraufhin landen sie auf Ebene des Dateisystems in einem gesonderten Archivordner.
Um nun diese Löschvorgänge aus dem Papierkorb über die Logdateien dauerhaft festhalten, muss die Konfiguration der Logdateien angepasst werden. Standardmäßig werden die Logdateien von paperless-ngx nach dem Erreichen einer Größe von 1 MB (konfigurierbar über PAPERLESS_LOGROTATE_MAX_SIZE
) rotiert (d.h. es wird eine neue leere Datei erzeugt) und es werden insgesamt 20 (konfigurierbar über PAPERLESS_LOGROTATE_MAX_BACKUPS
dieser Dateien vorgehalten.
Das heißt im Umkehrschluss, dass nach 20 MB Logdateien eben diese unwiderbringlich gelöscht werden. Das ist natürlich für ein Langzeitarchiv nicht sinnvoll, also müssen die beiden Variablen angepasst werden.
Setze also die Variable PAPERLESS_LOGROTATE_MAX_BACKUPS
auf 0
, so dass keine Logdateien gelöscht werden (Quelle). Ggf. ist es auch sinnvoll, die maximale Größe der einzelnen Logdateien noch zu erhöhen, um am Ende nicht 20.000 Dateien im Log-Ordner zu haben. Ich denke eine Größe von 15 MB pro Logdatei sind akzeptabel (Das wären dann 15728640
bytes).
Werden nun Dokumente in paperless-ngx gelöscht, tauchen in den Logdateien folgende Einträge auf:
Verschieben eines Dokuments in den Papierkorb
[DEBUG] [paperless.handlers] Moving /usr/src/paperless/media/documents/originals/0004737.pdf to trash at ../media/trash-archive/0004737.pdf
Endgültiges Löschen aus dem Papierkorb
[DEBUG] [paperless.handlers] Deleted file /usr/src/paperless/media/documents/archive/0004737.pdf
Um im Zweifel nachweisen zu können, dass im System keine Dokumente gelöscht wurden, die nicht auch auf Ebene des Dateisystems im gesonderten Archivordner liegen, reicht es, die Logdateien mit folgendem Befehl zu analysieren:
grep -rE "(to trash|Deleted)"
Die Ausgabe sieht dann wie folgt aus:
paperless.log:[2024-12-02 22:45:02,255] [DEBUG] [paperless.handlers] Moving /usr/src/paperless/media/documents/originals/0004737.pdf to trash at ../media/trash-archive/0004737.pdf
paperless.log:[2024-12-02 22:45:02,257] [DEBUG] [paperless.handlers] Deleted file /usr/src/paperless/media/documents/archive/0004737.pdf.
paperless.log:[2024-12-02 22:45:02,257] [DEBUG] [paperless.handlers] Deleted file /usr/src/paperless/media/documents/thumbnails/0004737.webp.
Dieses Log ist vollständig maschinenlesbar und kann von einer Prüfer:in auf Inkonsistenzen oder andere Unstimmigkeiten untersucht werden. Die Dokumenten-ID, die den Dateinamen bildet, ist dabei die interne ID in paperless-ngx, die für jedes in das System eingefügte Dokument um eins erhöht wird.
Prozessüberlegungen und Nachteile
Auch wenn dieser Prozess in sich stimmig und zu Ende gedacht ist, hat er einen gravierenden Nachteil. Als Unternehmer:in bin ich verpflichtet, meine Unterlagen maximal 10 Jahre (ab 01.01.2025 8 Jahre) aufzuheben. Ich habe also ein berechtigtes Interesse daran, dass Dokumente nach dieser Zeitspanne tatsächlich unwiderruflich gelöscht werden (können), ohne dabei Inkonsistenzen zu erzeugen.
Das ist selbstverständlich erst ab einer Nutzungsdauer des Systems von mehr als 8 bzw. 10 Jahren relevant, sollte aber dennoch schon mit dessen Einführung bedacht werden.
Automatische Papierkorb-Leerung deaktivieren
Lösche ich Dokumente über den oben genannten Prozess und belasse diese im Papierkorb (deaktiviere also die automatische Leerung mit PAPERLESS_EMPTY_TRASH_DELAY=9999
), weiß ich bei den einzelnen Dokumenten nicht, ab wann sie endgültig gelöscht werden dürfen, da ich die Metadaten nur sehen kann, wenn ich das Dokument manuell wiederherstelle und wieder lösche.
Automatische Papierkorb-Leerung auf 8/10 Jahre setzen
Setze ich eine automatische Leerung für den Papierkorb und setze die Zeit auf 8 bzw. 10 Jahre (PAPERLESS_EMPTY_TRASH_DELAY=3650
), würden Dokumente nach 8 bzw. 10 Jahren automatisch aus dem Papierkorb gelöscht. Diese Zeit gilt allerdings erst zu laufen, sobald das Dokument im Papierkorb gelandet ist. Während des Archivierungszeitraums liegen die Dokumente aber ja in paperless-ngx und nicht im Papierkorb. Lösche ich sie nach der Aufbewahrungsfrist, würden sie daraufhin nochmal 8 bzw. 10 Jahre im Papierkorb liegen, insgesamt wären sie also 16 bzw. 20 Jahre archiviert.
Automatische Papierkorb-Leerung nutzen
Belasse ich die automatische Leerung für den Papierkorb beim Standardwert von 30 Tagen, landen diese anschließend auf Ebene des Dateisystems im gesonderten Archivordner. Die Dateien in diesem Ordner haben den Zeitstempel des Originals. Da dieser nicht zwangsläufig mit dem Datum des Dokuments identisch ist, muss hier eine gewisse Unschärfe berücksichtigt werden.
Auf Dateiebene kann nun genauer gefiltert werden, welche Dokumente in den 8 bzw. 10-Jahres-Zeitraum fallen und diese anschließend gelöscht werden. Allerdings müsste man daraufhin auch die Logdateien bis zu diesem Zeitraum löschen, um keine Inkonsistenzen zu erzeugen.
Daher gibt es noch eine alternative Lösung, die ich für geschickter halte, weil man dazu nicht derart in den Gesamtprozess des Systems eingreifen muss.
Geschicktere Lösung
Den gesamten internen Löschprozess mittels eines eigenen Arbeitsablaufes abzubilden ist also der geschicktere Weg. Sozusagen die interne Löschfunktion ausschließlich dafür zu nutzen um Belege, deren Aufbewahrungsfrist verstrichen ist, endgültig zu löschen.
Statt des oben beschriebenen Löschprozesses werden Dokumente, die das Tag "LÖSCHEN!" erhalten, mittels eines eigenen Arbeitsablaufes automatisiert an einen anderen Speicherpfad verschoben. Diesen Speicherpfad kann man in seinen bisherigen Ansichten bequem rausfiltern, so dass gelöschte Dokumente im Alltag nicht mehr auftauchen, aber dennoch jederzeit inkl. deren Audit-Trail auffindbar sind. So muss eine Prüfer:in die Oberfläche von paperless-ngx nicht verlassen und es sind keine "technischen Kenntnisse" auf Ebene der Kommandozeile nötig.
Sobald die Aufbewahrungsfrist eines Dokuments verstrichen ist, kann dieses dann mit Administratorrechten erst in den Papierkorb und nach Ablauf der Papierkorb-Aufbewahrungsfrist vollständig aus dem System gelöscht werden. Der Zwischenschritt mit dem gesonderten Archivordner auf Ebene des Dateisystems ist damit nicht mehr nötig.
Du hast Fragen oder Anregungen zu diesem Artikel oder benötigst Unterstützung bei der rechtssicheren Konfiguration von paperless-ngx? Dann freue ich mich über eine Nachricht von dir über Kontakt, per Telegram oder unten in die Kommentare.
Weiterführende Links
Änderungshistorie
03.12.2024, 01:00 – Artikel erstellt
Hi, ich bin Christian und Inhaber der Firma SWEETGOOD. Mit dem andersGOOD Blog möchte ich auch dich für datensichere IT-Lösungen begeistern. So bringst du dein Unternehmen voran, ohne großen Konzernen deine wertvollen Daten zu liefern. Probiers mal anders!
Kommentarbereich
Die Kommentare sind für dich noch deaktiviert, da du dem Setzen von Cookies bisher nicht zugestimmt hast.
Klicke oben rechts auf "Ja, klar!" und lade die Seite neu, um die Kommentare anzuzeigen.
Seite neu laden