Verfahrensdokumentation

1. Allgemeine Angaben

1.1 Zweck dieser Dokumentation

Diese Verfahrensdokumentation beschreibt die technischen und organisatorischen Maßnahmen, die Paperarchive zur ordnungsgemäßen Erfassung, Verarbeitung, Aufbewahrung und Bereitstellung von digitalisierten Geschäftsdokumenten einsetzt. Sie dient dem Nachweis der GoBD-Konformität gegenüber der Finanzverwaltung und Wirtschaftsprüfern.

1.2 Geltungsbereich

Diese Dokumentation gilt für alle Dokumente, die innerhalb eines GoBD-aktivierten Space in Paperarchive verarbeitet und archiviert werden. Die GoBD-Konformität kann pro Space aktiviert werden und betrifft ausschließlich Spaces, in denen diese Funktion eingeschaltet ist.

2. Organisatorische Rahmenbedingungen

2.1 Verantwortliche Personen

2.2 Zugangsberechtigungen

Der Zugriff auf Paperarchive ist durch ein mehrstufiges Berechtigungskonzept geschützt:

• Authentifizierung: JWT-basierte Authentifizierung über Supabase Auth. Jeder Benutzer erhält nach erfolgreicher Anmeldung ein signiertes JSON Web Token, das bei jeder API-Anfrage validiert wird.
• Autorisierung: Supabase Row Level Security (RLS) Policies stellen sicher, dass Benutzer ausschließlich auf Daten zugreifen können, die ihrem eigenen Account zugeordnet sind.
• Space-basierte Trennung: Innerhalb eines Accounts können mehrere Spaces (z.B. "Geschäftlich", "Privat") angelegt werden. Jeder Space verfügt über eigene Einstellungen, einschließlich der GoBD-Aktivierung.
• Kein direkter Datenbankzugriff: Endbenutzer haben keinen direkten Zugang zur Datenbank. Sämtliche Operationen laufen über die API-Schicht mit entsprechender Validierung.

2.3 Mandantentrennung

Jeder Benutzer arbeitet in isolierten Spaces. Die Mandantentrennung wird auf Datenbankebene durch Supabase RLS durchgesetzt:

• Jeder Datensatz ist einem Benutzer und einem Space zugeordnet.
• RLS Policies verhindern den Zugriff auf Daten anderer Benutzer, selbst bei direkten Datenbankabfragen.
• Die Space-Zuordnung wird während der Dokumentenverarbeitung automatisch aufgelöst - entweder aus den Upload-Metadaten, dem bestehenden Dokument oder dem Standard-Space des Benutzers.

3. Dokumentenverarbeitung

3.1 Übersicht der Verarbeitungspipeline

Die Dokumentenverarbeitung durchläuft eine definierte, fünfstufige Pipeline. Jede Stufe wird protokolliert und kann bei Fehlern einzeln wiederholt werden.

Upload → [1] Validierung → [2] Malware-Scan → [3] OCR → [4] KI-Analyse → [5] Embedding & Matching

3.2 Stufe 1: Validierung

Vor der Verarbeitung werden folgende Prüfungen durchgeführt:

• Dateityp-Validierung: Nur zugelassene Dateitypen werden akzeptiert (PDF, JPEG, PNG, TIFF, GIF, WebP, BMP, SVG).
• Dateigrößen-Validierung: Die maximale Dateigröße beträgt 50 MB.
• Space-Zuordnung: Das Dokument wird dem korrekten Space zugeordnet (aus Upload-Metadaten, bestehendem Dokumenteintrag oder Standard-Space).

3.3 Stufe 2: Malware-Scan

• Hochgeladene Dateien werden mittels ClamAV auf Schadsoftware geprüft.
• Bei positivem Malware-Befund wird die Datei sofort aus dem Storage gelöscht und die Verarbeitung abgebrochen.
• Es werden nur zugelassene Scan-Befehle akzeptiert, um Command-Injection zu verhindern.

3.4 Stufe 3: Texterkennung - OCR

• Die Texterkennung erfolgt über die Google Cloud Vision API.
• Die API wird über den EU-Endpunkt (eu-vision.googleapis.com) angesprochen, um die Datenresidenz innerhalb der EU sicherzustellen.
• Der extrahierte Text wird layoutgetreu in Chunks aufgeteilt und mit Bounding-Box-Informationen gespeichert.
• Maximale Seitenanzahl für OCR: 5 Seiten pro Dokument.

3.5 Stufe 4: KI-Analyse

Die KI-Analyse extrahiert strukturierte Informationen aus dem OCR-Text:

• Anbieter: Azure OpenAI (EU-Region) als primärer Anbieter, OpenAI als Fallback.
• Extrahierte Informationen: Dokumententitel, Dokumentendatum, Kategorie-Vorschlag, Absender-Erkennung, Schlüsseldaten (Beträge, Fälligkeitsdaten, Referenznummern).
• Konfidenzbasierte Verarbeitung: Jedes extrahierte Feld erhält einen Konfidenzwert (0,0 - 1,0). Felder mit niedrigem Konfidenzwert erzeugen Events, die vom Benutzer bestätigt oder korrigiert werden müssen.
• Pattern Learning: Neue Dokumente werden mit bestehenden Mustern des Benutzers abgeglichen, um die Erkennungsgenauigkeit kontinuierlich zu verbessern.

3.6 Stufe 5: Embedding und Matching

• Vektor-Embeddings werden durch einen lokalen Embedding-Service generiert (keine Datenübertragung an externe Dienste).
• Ähnliche Dokumente werden anhand der Vektordistanz identifiziert, um die Verarbeitung zu optimieren.

3.7 Integritätssicherung beim Upload

• SHA-256 Hash: Beim Upload wird ein SHA-256-Hash der Originaldatei berechnet und in der Datenbank gespeichert.
• Verifizierung: Die Dateiintegrität kann jederzeit überprüft werden, indem der gespeicherte Hash mit einem neu berechneten Hash der Datei im Storage verglichen wird.
• Manipulationserkennung: Bei einer Hash-Abweichung wird eine Warnung protokolliert. Dies ermöglicht die Erkennung nachträglicher Veränderungen an der Originaldatei.

3.8 Protokollierung der Verarbeitungsschritte

Jeder Verarbeitungsdurchlauf wird mit Korrelations-ID, Dauer pro Stufe, Gesamtdauer und ggf. Fehlerinformationen dokumentiert.

4. Aufbewahrung und Unveränderbarkeit

4.1 GoBD-Modus

Der GoBD-Modus ist pro Space aktivierbar. Bei aktiviertem GoBD-Modus gelten folgende erweiterte Regeln:

• Aufbewahrungsfristen werden automatisch angewendet.
• Archivierte Dokumente unterliegen einem Änderungsschutz.
• Löschungen während einer aktiven Aufbewahrungsfrist werden blockiert.

4.2 Aufbewahrungsfristen

Die Aufbewahrungsfristen richten sich nach dem Dokumenttyp und der gesetzlichen Grundlage:

Die Aufbewahrungsfrist beginnt mit dem Schluss des Kalenderjahres, in dem das Dokument erstellt oder empfangen wurde. Die Berechnung erfolgt automatisch: Dokumentdatum + Aufbewahrungsjahre, wobei das Ablaufdatum auf den 31.12. des errechneten Jahres gesetzt wird.

4.3 Archive-Lock (Änderungsschutz)

Dokumente in GoBD-aktivierten Spaces unterliegen nach der Archivierung einem Änderungsschutz:

• Geschützte Felder: Nach der Archivierung können bestimmte Felder (z.B. Originaldatei, Dokumentdatum, Beträge) nicht mehr geändert werden.
• Archivierungszeitpunkt: Der Zeitpunkt der Archivierung wird festgehalten und kann nicht verändert werden.
• Unveränderbarkeit der Originaldatei: Die Originaldatei im Storage wird durch den SHA-256-Hash gesichert. Jede Veränderung würde bei einer Integritätsprüfung erkannt werden.

4.4 Löschschutz

Dokumente mit aktiver Aufbewahrungsfrist können nicht gelöscht werden:

• Vor jeder Löschung wird geprüft, ob das Dokument einem GoBD-aktivierten Space angehört.
• Archivierte Dokumente können nicht gelöscht werden.
• Dokumente mit laufender Aufbewahrungsfrist können nicht gelöscht werden.
• Erst nach Ablauf der Aufbewahrungsfrist ist die Löschung möglich.

5. Protokollierung (Audit-Trail)

5.1 Grundsatz

Alle sicherheits- und compliance-relevanten Änderungen an Dokumenten werden in einer unveränderlichen Audit-Log-Tabelle protokolliert. Der Audit-Trail ist unabhängig vom GoBD-Toggle aktiv - auch in Spaces ohne GoBD-Modus werden sämtliche Änderungen protokolliert.

5.2 Append-Only-Prinzip

Die Audit-Log-Tabelle folgt dem Append-Only-Prinzip:

• Einträge können ausschließlich hinzugefügt werden (INSERT).
• UPDATE und DELETE sind durch Datenbank-Trigger unterbunden.
• Bestehende Einträge können nachträglich weder verändert noch gelöscht werden.

5.3 Protokollierte Aktionen

Folgende Aktionen werden im Audit-Log erfasst:

• Änderung von Dokumentmetadaten (mit alten und neuen Werten)
• Löschung eines Dokuments
• Archivierung eines Dokuments
• Löschung eines Speicherobjekts

5.4 Fehlertoleranz

Die Audit-Protokollierung ist fehlertolerant implementiert: Fehler beim Schreiben eines Audit-Eintrags führen nicht zum Abbruch der eigentlichen Operation. Stattdessen wird der Fehler im Anwendungslog vermerkt, sodass betriebliche Störungen die Geschäftsprozesse nicht blockieren.

6. Datensicherung und Wiederherstellung

6.1 Datenbank-Backups

• Anbieter: Supabase (Managed PostgreSQL)
• Häufigkeit: Tägliche automatische Backups
• Point-in-Time Recovery (PITR): Wiederherstellung auf einen beliebigen Zeitpunkt innerhalb des Backup-Fensters möglich
• Backup-Speicherort: EU-Region (Frankfurt, Deutschland)

6.2 Dateispeicherung

• Storage: Supabase Storage (S3-kompatibel)
• Redundanz: Dateien werden redundant gespeichert
• Datenresidenz: EU-Region (Frankfurt, Deutschland)

6.3 Wiederherstellungsverfahren

Im Falle eines Datenverlusts oder einer Beschädigung:

1. Point-in-Time Recovery der Datenbank auf den gewünschten Zeitpunkt
2. Integritätsprüfung der wiederhergestellten Dokumente anhand der gespeicherten SHA-256-Hashes
3. Überprüfung der Audit-Log-Vollständigkeit

7. Datenschutz und Sicherheit

7.1 Transportverschlüsselung

• Alle Verbindungen zwischen Client und Server sind TLS-verschlüsselt (HTTPS).
• Die interne Kommunikation zwischen Backend-Services und Datenbank erfolgt ebenfalls verschlüsselt.

7.2 Zugriffskontrolle

• Row Level Security (RLS): Supabase RLS Policies erzwingen die Datenisolation auf Datenbankebene. Jede Abfrage wird automatisch auf die Daten des authentifizierten Benutzers eingeschränkt.
• JWT-Authentifizierung: Jede API-Anfrage erfordert ein gültiges, signiertes JWT-Token.
• Rate Limiting: API-Endpunkte sind durch Rate Limiting geschützt, um Missbrauch zu verhindern.

7.3 Eingabevalidierung

• Alle API-Eingaben werden validiert und bereinigt.
• Datei-Uploads werden auf zugelassene Dateitypen und -größen geprüft.
• Dokument-IDs werden als UUID validiert, um Path-Traversal-Angriffe zu verhindern.

7.4 Datensparsamkeit bei externen Diensten

• Google Cloud Vision: Ausschließlich EU-Endpunkt. Es werden nur die Bilddaten zur Texterkennung übertragen - keine Metadaten oder Benutzerinformationen.
• Azure OpenAI: EU-Region. Es wird nur der extrahierte OCR-Text zur Analyse übertragen, nicht die Originaldatei.
• Lokaler Embedding-Service: Vektor-Embeddings werden lokal auf dem eigenen Server generiert. Es findet keine Datenübertragung an externe Dienste statt.

8. Technische Infrastruktur

8.1 Server-Infrastruktur

8.2 Datenbank und Storage

8.3 Externe Dienste

8.4 Deployment und CI/CD

• Versionskontrolle: Git (GitHub)
• Deployment-Trigger: Push auf den main-Branch
• CI/CD-Pipeline: GitHub Actions
• Kein manuelles Deployment im Regelbetrieb: Alle Änderungen durchlaufen die CI/CD-Pipeline.

9. Änderungshistorie

10. Anlagen

• Datenschutzerklärung
• Nutzungsbedingungen