📋

Verfahrensdokumentation nach GoBD

Gemäß GoBD i.d.F. des BMF-Schreibens vom 14.07.2025 (2. Änderung; Ursprung 28.11.2019, BStBl I 2019, S. 1269, geändert 11.03.2024, BStBl I 2024, S. 374)

Hinweis: Diese Seite dokumentiert eine interne technische Selbstprüfung der im Quellcode von MintFolder AI implementierten Maßnahmen. Es handelt sich nicht um ein Testat, Gutachten oder eine Bescheinigung einer Wirtschaftsprüfungsgesellschaft, einer Datenschutzbehörde oder einer anderen fachkundigen Stelle.

System: MintFolder AI v1.4.0

Erstellt am: 23. April 2026

Verantwortlich: Thaeer Sukay (MintFolder AI)

Status: Interne Dokumentation (Selbstprüfung)

Rechtsgrundlage: §§ 145-147 AO, GoBD i.d.F. BMF 14.07.2025

Nächste Prüfung: 09. Dezember 2026 (halbjährlich)

Allgemeine Beschreibung

Unternehmensprofil

MintFolder AI ist ein cloudbasiertes Dokumentenarchivierungswerkzeug zur Archivierung, Klassifizierung und Aufbewahrung von Geschäftsdokumenten nach GoBD-Anforderungen. Das System bedient drei Eingangskanäle: Web-Oberfläche, Telegram-Bot und B2B-API-Schnittstelle.

Zweck des Systems

Automatische KI-gestützte Klassifizierung eingehender Dokumente (Rechnungen, Verträge, Korrespondenz)
Nach GoBD konzipierte Archivierung mit unveränderlicher Speicherung
Strukturierte Metadatenextraktion (Absender, Empfänger, Betrag, Datum, USt-ID, IBAN)
Automatische Zuordnung der gesetzlichen Aufbewahrungsfristen
Bereitstellung von Daten für die Betriebsprüfung (Z1/Z2/Z3)

Dokumentenarten

Dokumenttyp	Kürzel	Aufbewahrungsfrist	Rechtsgrundlage
Eingangsrechnungen	RE	8 Jahre	§147 Abs. 3 AO i.d.F. BEG IV, ab 01.01.2025
Ausgangsrechnungen	AR	8 Jahre	§147 Abs. 3 AO i.d.F. BEG IV, ab 01.01.2025
Buchungsbelege	BU	8 Jahre	§147 Abs. 3 AO i.d.F. BEG IV, ab 01.01.2025
Verträge	VT	6 Jahre (im Regelfall; Einzelfallprüfung)	§147 AO / §257 HGB (einzelfallabhängig)
Geschäftsbriefe	GB	6 Jahre	§147 Abs. 1 Nr. 2, 3 AO
Steuerbescheide	ST	10 Jahre	§147 Abs. 1 Nr. 4a AO
Personalunterlagen / Persönliche Dokumente	PA	10 Jahre (konservativer Default; bei Differenzierung Lohnbeleg/Sonstiges einzelfallabhängig)	§147 Abs. 1 Nr. 4a AO, §41 EStG, §257 HGB
Bankbelege	BA	10 Jahre	§147 Abs. 1 Nr. 4 AO
Sonstige	SO	6 Jahre	§147 Abs. 1 Nr. 5 AO

Anwenderdokumentation

Eingangskanäle

Kanal	Beschreibung	Kennung (archive_source)
Web-Oberfläche	Upload über Browser-Dashboard (app.mintfolder.ai)	`web`
Telegram-Bot	Direkte Dokumentenübermittlung per Chat	`bot`
B2B-Dashboard	API-Schnittstelle für Geschäftskunden	`b2b`
Scanner-Modul	Kamera-basierter Dokumentenscan	`scan`

Verarbeitungsablauf

Dokumenteneingang: Benutzer lädt PDF/Bild über einen der vier Kanäle hoch
KI-Analyse: Vierstufige Fallback-Kette (Lokal/Ollama → Gemini → Claude → GPT-4o) extrahiert Metadaten
Klassifizierung: Automatische Zuordnung zu Kategorie, Kürzel und Aufbewahrungsfrist
Hash-Berechnung: SHA-256-Hash des Dokuments wird vor der Speicherung berechnet
Google Drive Upload: Dokument wird in strukturiertem Ordnerpfad gespeichert
Archivierung: Alle Metadaten werden in der SQLite-Datenbank gespeichert
Auto-Lock: Trigger trg_archive_auto_lock sperrt den Eintrag sofort nach INSERT
Bestätigung: Benutzer erhält Bestätigung mit Archivpfad und Drive-Link

Benutzerrollen

Rolle	Berechtigung	Beschreibung
`owner`	Vollzugriff	Unternehmensinhaber, alle Verwaltungsfunktionen
`admin`	Verwaltung	Team-Management, Einstellungen, Export
`editor`	Bearbeitung	Dokumente hochladen und archivieren
`viewer`	Nur Lesen	Archiv einsehen, keine Änderungen
`api-only`	API-Zugriff	Nur programmatischer Zugriff über API-Key
`auditor`	Nur Lesen (zeitlich begrenzt)	Betriebsprüfer — lesender Zugriff auf Archiv, Audit-Trail und Integritätsprüfung

Technische Systemdokumentation

Systemarchitektur

Komponente	Technologie	Zweck
Backend	Python 3.12 + Uvicorn (ASGI)	API-Server & Geschäftslogik
Datenbank	SQLite 3 (WAL-Modus)	Metadatenspeicherung & Audit Trail
Dateispeicher	Google Drive API v3	Dokumentenspeicherung
KI-Engine	Lokal/Ollama → Gemini → Claude → OpenAI (vierstufige Fallback-Kette)	Dokumentenanalyse & Klassifizierung
Webserver	Nginx (Reverse Proxy)	HTTPS-Terminierung, Routing
Bot-Interface	python-telegram-bot v20	Telegram-Kanal
PDF-Verarbeitung	pypdf, pypdfium2, Pillow	PDF-Operationen (18 Tools)

Datenbankschema — Archivtabelle

Tabelle: archive_log — Zentrale Archivtabelle mit 37 Feldern

Feld	Typ	GoBD-Relevanz
`id`	INTEGER PK	Eindeutige Dokumentennummer
`user_id`	INTEGER FK	Zuordnung zum Benutzer
`original_name`	TEXT	Ursprünglicher Dateiname
`final_name`	TEXT	Archivierter Dateiname
`category` / `kuerzel`	TEXT	Dokumentenkategorie (RE, AR, VT, etc.)
`sender` / `recipient`	TEXT	Absender/Empfänger
`doc_date`	TEXT	Belegdatum
`processed_at`	TEXT	Erfassungszeitpunkt (automatisch)
`drive_path`	TEXT	Speicherpfad in Google Drive
`document_hash`	TEXT	SHA-256 Hash für Integritätsprüfung
`archive_source`	TEXT	Herkunftskanal (web/bot/b2b/scan)
`locked_at`	TEXT	Sperrzeitpunkt (Unveränderbarkeit)
`betrag_netto`	REAL	Nettobetrag (für Aufbewahrungsfrist)
`waehrung`	TEXT	Währung
`rechnungsnummer`	TEXT	Rechnungsnummer
`ust_id_sender`	TEXT	USt-IdNr. des Absenders
`iban`	TEXT	IBAN des Absenders
`aufbewahrungsfrist`	INTEGER	Aufbewahrungsfrist in Jahren (6/8/10 gem. §147 Abs. 3 AO i.d.F. BEG IV)
`gobd_log`	TEXT	GoBD-Verarbeitungsprotokoll (JSON)

Integritätssicherung — SQLite Triggers

Trigger	Zweck	GoBD-Anforderung
`trg_archive_auto_lock`	Automatische Sperrung bei INSERT (status='success')	Zeitgerechte Erfassung
`trg_archive_no_tamper_core`	Blockiert UPDATE auf Kernfelder nach Sperrung	Unveränderbarkeit
`trg_archive_no_tamper_financial`	Blockiert UPDATE auf Finanzfelder nach Sperrung	Unveränderbarkeit
`trg_archive_no_delete`	Blockiert DELETE auf alle Archiveinträge	Vollständigkeit
`trg_archive_retention_guard`	Verhindert Soft-Delete vor Ablauf der Aufbewahrungsfrist	Aufbewahrungspflicht
`trg_archive_audit_summary`	Protokolliert Änderungen an ai_summary	Nachvollziehbarkeit
`trg_archive_audit_status`	Protokolliert Statusänderungen	Nachvollziehbarkeit
`trg_archive_audit_drive_deleted`	Protokolliert Drive-Löschmarkierungen	Nachvollziehbarkeit
`trg_archive_audit_category`	Protokolliert Kategorieänderungen	Nachvollziehbarkeit
`trg_audit_trail_no_tamper`	Audit Trail nach Versiegelung unveränderbar	Prüfbarkeit
`trg_audit_trail_no_tamper_data`	Datenfelder des Audit Trails immer unveränderbar	Prüfbarkeit
`trg_audit_trail_no_delete`	Audit Trail löschgeschützt	Prüfbarkeit
`trg_credits_non_negative`	Verhindert negative Guthaben-Salden	Finanzielle Integrität
`trg_ledger_no_tamper`	Kredit-Ledger unveränderbar	Finanzielle Integrität
`trg_ledger_no_delete`	Kredit-Ledger löschgeschützt	Finanzielle Integrität
`trg_action_ledger_no_tamper`	Aktions-Ledger unveränderbar	Finanzielle Integrität
`trg_action_ledger_no_delete`	Aktions-Ledger löschgeschützt	Finanzielle Integrität
`trg_credits_never_negative`	Zusätzliche Negativsaldo-Sperre	Finanzielle Integrität
`trg_audit_trail_chrono_guard`	Verhindert rückdatierte Audit-Trail-Einträge	Chronologische Erfassung (§146 AO)
`trg_billing_events_no_tamper`	Abrechnungsereignisse unveränderbar	Finanzielle Integrität
`trg_billing_events_no_delete`	Abrechnungsereignisse löschgeschützt	Finanzielle Integrität
`trg_datev_locked_no_unlock`	DATEV-Sperre kann nicht aufgehoben werden	DATEV-Exportschutz (§146 AO)
`trg_datev_no_summary_change`	KI-Zusammenfassung nach DATEV-Export unveränderbar	DATEV-Exportschutz
`trg_datev_no_kontierung_change`	Vorkontierung nach Export unveränderbar	DATEV-Exportschutz (§146 AO)
`trg_datev_no_softdelete`	Soft-Delete auf exportierten Datensätzen blockiert	DATEV-Exportschutz
`trg_datev_no_metadata_overwrite`	Metadaten nach Export unveränderbar	DATEV-Exportschutz
`trg_datev_no_ocr_change`	OCR-Daten nach Export unveränderbar	DATEV-Exportschutz (§146 AO)
`trg_datev_no_user_reassign`	Benutzerzuordnung nach Export unveränderbar	DATEV-Exportschutz (§146 AO)
`trg_datev_no_retention_change`	Aufbewahrungsfrist nach Export unveränderbar	DATEV-Exportschutz
`trg_datev_no_storno_reversal`	Storno kann nicht rückgängig gemacht werden	DATEV-Exportschutz
`trg_datev_no_audit_field_change`	Audit-Felder nach Export unveränderbar	DATEV-Exportschutz
`trg_datev_no_locked_at_change`	Sperrzeitstempel nach Export unveränderbar	DATEV-Exportschutz (§146 AO)
`trg_b2b_datev_no_booking_change` u. a. (5 Trigger)	B2B-Belege (`b2b_usage_logs`) nach DATEV-Export festgeschrieben: Buchungsfelder, DELETE innerhalb der Aufbewahrungsfrist, Entsperrung, Sperrzeitstempel und Mandantenzuordnung unveränderbar (Sprint 5, Spalte `datev_locked`)	DATEV-Festschreibung (§146 Abs. 4 AO)
2 weitere Festschreibungs-Trigger (Sprint 6)	Zwei zusätzliche Festschreibungs-Trigger im Rahmen von Sprint 6 ergänzt; Gesamtbestand der Trigger steigt damit von 91 auf 93 (`schema_version` v729 → v732)	DATEV-Festschreibung (§146 Abs. 4 AO)

Gesamtbestand: 97 SQLite-Trigger (aktive Namen im initialisierten Schema, Stand: 2026-06-14, schema_version v747; davon 95 GoBD-Integritäts-/Append-only- und 2 FTS-Index-Trigger) — kategorisiert in: Integritäts-Trigger (Hash-Chaining, Foreign-Key-Enforcement), Audit-Trigger (UPDATE/DELETE-Protokollierung), DATEV-Exportschutz-Trigger (Unveränderbarkeit nach Festschreibung gem. §146 Abs. 4 AO), Transfervermerk-Trigger (eIDAS-Signaturkette) und Aufbewahrungs-Trigger (§147-AO-Frist-Berechnung).

Die obige Tabelle zeigt gemäß GoBD Rn. 155 (Verhältnismäßigkeitsgrundsatz) eine kuratierte Auswahl der zentralen Trigger zur Veranschaulichung der Kontroll- und Sicherungsmaßnahmen. Die vollständige technische Trigger-Definition mit SQL-DDL, Auslöser, betroffenen Tabellen und Schutzzweck ist Bestandteil der technischen Systemdokumentation (GoBD Rn. 153 lit. c) und wird im Quellcode-Modul db/schema.py versioniert geführt (der Migrations-Runner verbleibt in db/_core.py). Ein Auszug (SQL-Definition aller 97 aktiven Trigger) wird auf Verlangen einer Außenprüfung gem. §147 Abs. 6 AO i.V.m. §146a Abs. 4 AO innerhalb der gesetzlichen Frist bereitgestellt.

Hinweis: Diese Tabelle zeigt eine Auswahl der implementierten Integritäts-Trigger. Die vollständige Liste ist in der technischen Umsetzungsdokumentation aufgeführt.

Hash-Algorithmus

Algorithmus: SHA-256 (256-Bit Secure Hash Algorithm)
Berechnung: hashlib.sha256(file_bytes).hexdigest()
Zeitpunkt: Vor dem Upload in Google Drive, nach der Verarbeitung
Speicherung: Feld document_hash in archive_log
Verifizierung: Funktion verify_document_hash(archive_id, file_bytes)

Kryptographische Verkettung des Audit Trails (Hash-Chaining)

Problemstellung: Als Solo-Gründer (Ein-Personen-Betrieb) verfügt der Systembetreiber über vollständigen Root-/SSH-Zugang zum Produktionsserver. Eine physische Funktionentrennung (Vier-Augen-Prinzip) gemäß GoBD Rn. 152 ist daher organisatorisch nicht darstellbar. Insbesondere könnte der Administrator die SQLite-Datenbankdatei mittels Hex-Editor direkt manipulieren und so die Anwendungs-seitigen Trigger umgehen.

Kompensierende Kontrolle (§ 146 Abs. 4 AO): Als Ersatz für die fehlende Funktionentrennung implementiert das System ein kryptographisches Hash-Chaining-Verfahren in der Tabelle archive_audit_trail:

Sequentielle Verkettung: Jeder Audit-Trail-Eintrag enthält neben seinen Daten zwei zusätzliche Felder: previous_hash (SHA-256-Hash des Vorgänger-Eintrags) und current_hash (SHA-256-Hash des aktuellen Eintrags einschließlich previous_hash). Der erste Eintrag der Kette verweist auf einen deterministischen Genesis-Hash.
Versiegelung (Sealing): Die Hash-Berechnung erfolgt über eine kanonische, pipe-separierte Zeichenkette aller Datenfelder: SHA-256(previous_hash|id|archive_id|user_id|action|field_name|old_value|new_value|performed_by|ip_address|user_agent|created_at). Nach der Versiegelung sind sämtliche Modifikationen durch SQLite-Trigger blockiert.
Manipulationserkennung: Der API-Endpunkt /api/gobd/verify-integrity liest die gesamte Tabelle, berechnet jeden Hash neu und vergleicht ihn mit dem gespeicherten Wert. Jede Abweichung — auch eine einzelne geänderte Zelle — invalidiert die Kette ab diesem Punkt und wird mit der exakten Zeilen-ID (tampered_ids) gemeldet. Status: FAILED.
E-Mail-Attestierung (Zeitstempel-Nachweis via Zoho SMTP — kein zertifizierter WORM-Speicher): Die Funktion send_to_worm_storage() wird nach jeder Versiegelung durch den Scheduler (scheduler.py, alle 60 Sekunden) automatisch aufgerufen. Der aktuelle Ketten-Kopf-Hash (chain_head) wird per Zoho SMTP-Relay (smtppro.zoho.eu, EU) an [email protected] übermittelt. Die E-Mail dient als zeitgestempelter, extern verifizierbarer Nachweis — unabhängig von der MintFolder-Infrastruktur, da Zoho die E-Mail auf eigenen EU-Servern vorhält. Bei Ausfall des SMTP-Relays greift ein lokales Fallback-Log (worm-attestations.log). S3 Object Lock steht als zusätzliche Methode bereit.

Prüfverfahren für den Betriebsprüfer: Der Prüfer ruft den Endpunkt GET /api/gobd/verify-integrity auf (authentifiziert via Bearer-Token). Die Antwort enthält: (a) den Gesamtstatus (PASSED/FAILED), (b) die Anzahl verifizierter Einträge, (c) bei Manipulation die betroffenen Zeilen-IDs, (d) den aktuellen Ketten-Kopf-Hash zur unabhängigen Verifizierung.

Kryptographische Anker-Persistierung (Proof Chain)

Seit April 2026 werden sämtliche Attestierungen zusätzlich in der Tabelle anchor_attestations persistiert. Jeder Eintrag enthält den attested chain_hash, eine Rückverlinkung zum vorherigen Anker (previous_anchor) sowie die externe Referenz (Zoho-SMTP-Versandmarker, S3-Pfad oder lokaler Log-Pfad). Dies ermöglicht:

Proof-Chain-Export: GET /api/gobd/proof-chain — liefert die vollständige Attestierungskette als JSON.
Einzelanker-Verifizierung: GET /api/gobd/verify-anchor/{hash} — öffentlicher Endpunkt, der für jeden SHA-256-Hash prüft, ob eine korrespondierende Attestierung existiert und die Kette intakt ist.
Per-Dokument-Anchoring: anchor_document(archive_id) — erzeugt einen individuellen kryptographischen Anker pro archiviertem Dokument, unabhängig von der periodischen Chain-Head-Attestierung.

E-Rechnung-Validierung (Sprint 6)

Strukturierte elektronische Rechnungen (XRechnung CII/UBL und ZUGFeRD/Factur-X) werden gegen die EN16931-Geschäftsregeln per Schematron geprüft. Es wird keine XSD-Schemavalidierung durchgeführt (XSD ist für die von der Bibliothek tolerierte CII-Elementreihenfolge bewusst nicht maßgeblich; die Schematron-Prüfung der EN16931-Geschäftsregeln — Beträge, Steuersummen, BR-CO-Regeln — ist die substanzielle Korrektheitsprüfung). Die Validierung wirkt in zwei Richtungen unterschiedlich:

Eingehende Belege (services/e_rechnung.py): Die XML eingehender XRechnung/ZUGFeRD-Belege wird per facturx.xml_check_schematron (EN16931, CII) geprüft. Der Validierungsstatus wird am Beleg vermerkt (e_rechnung_validation_status / e_rechnung_validation_errors). Ein ungültiger eingehender Beleg wird niemals verworfen, sondern markiert und dennoch unverändert archiviert — die Vollständigkeit nach §147 AO geht der formalen Gültigkeit vor; der eingegangene Beleg ist Teil der lückenlosen Aufzeichnung. UBL-Syntax liegt außerhalb des CII-Bereichs von factur-x und wird als skipped_ubl vermerkt (kein Fehler); eine echte XRechnung-CIUS-Nutzlast, die factur-x nicht prüfen kann, wird als skipped_cius vermerkt (nie als „ungültig").
Ausgehende Rechnungen (services/invoice_generator.py): Beim Finalisieren wird die erzeugte XRechnung (CII) per Schematron (saxonche-XSLT-Prozessor) gegen die EN16931-Regeln geprüft. Bei einem Schematron-Verstoß wird der Finalize-Vorgang mit HTTP 422 abgelehnt — eine nicht regelkonforme E-Rechnung darf nicht ausgestellt/versendet werden (§14 UStG; Verzugsschaden-Risiko). Nur der ausgehende Pfad enthält dieses harte Gate.

Die XRechnung-CIUS-/BR-DE-Validierung nach dem KoSIT-Standard (deutsche nationale Spezifikationen über EN16931 hinaus, KoSIT XRechnung 3.0 Schematron via saxonche) wird beim Finalisieren ausgehender XRechnungen zusätzlich ausgeführt; das Ergebnis wird am Beleg vermerkt (brde_validation_status / brde_validation_errors, nach dem Finalisieren unveränderbar). Sie läuft derzeit warnend/protokollierend (warn-first) und ist noch keine harte Sperre — die blockierende Finalize-Sperre (HTTP 422) bleibt die EN16931-Schematron-Prüfung. Die Heraufstufung der BR-DE-Prüfung zur harten Sperre ist als Folgeschritt vorgesehen.

GDPdU-/Z3-Export (Sprint 6)

Für die Datenträgerüberlassung (Z3) gem. §147 Abs. 6 AO erzeugt services/export/gdpdu.py ein GDPdU-/Audicon-konformes Paket (Beschreibungsstandard für IDEA/AIS-TaxAudit-Import) aus denselben Finanz-Archivzeilen, die auch der DATEV-EXTF-Export verwendet. Das Paket besteht aus genau drei aufeinander abgestimmten Dateien:

Datei	Inhalt
`index.xml`	GDPdU-Beschreibungsdatei (INDEX.XML), konform zur amtlichen DTD `gdpdu-01-08-2002.dtd` (Version 1.1)
`gdpdu-01-08-2002.dtd`	Die amtliche DTD, unverändert dem Paket beigelegt, damit der Datenträger selbstbeschreibend ist
`journal.csv`	Die Buchungsdaten, ein Datensatz je Zeile, in exakt der im Index deklarierten Spaltenreihenfolge

index.xml und journal.csv werden aus einer einzigen Spaltendefinition (_COLUMNS) abgeleitet, sodass die VariableColumn-Reihenfolge/-Namen im XML immer mit dem CSV-Header übereinstimmen. CSV-Konventionen folgen den deutschen Audicon-Vorgaben: Spaltentrennzeichen ;, Datensatztrennzeichen CRLF, Textbegrenzer ", Dezimalzeichen ,, Tausendertrennzeichen ., Datumsformat DD.MM.YYYY, UTF-8. Damit steht den Prüferinnen und Prüfern für die Z3-Datenüberlassung neben dem DATEV-EXTF-Format (Abschnitt 8) ein weiteres maschinell auswertbares, standardkonformes Format zur Verfügung.

Betriebsdokumentation

Systembetrieb

Parameter	Wert
Server	Linux (Ubuntu 24.04 LTS)
Hosting	Dedizierter Server mit SSH-Zugang
HTTPS	Let's Encrypt TLS 1.3 (automatische Erneuerung)
Prozess-Manager	Uvicorn mit nohup / systemd
Datenbank-Modus	SQLite WAL (Write-Ahead Logging)
Backup-Intervall	Täglich (siehe Datensicherungskonzept)
Monitoring	Health-Check Endpoint + Log-Analyse

Wartungsverfahren

Updates werden über Git-basiertes Deployment ausgerollt
Datenbankmigrationen erfolgen automatisch beim Anwendungsstart
Alle Konfigurationsänderungen werden in der Änderungshistorie dokumentiert
Uvicorn-Neustart nach Code-Änderungen mit Prozessüberwachung

Internes Kontrollsystem (IKS)

Gemäß GoBD Rz. 100-103 (BMF-Schreiben 28.11.2019)

Zugangskontrollen

Web-Zugang: Google OAuth 2.0 Authentifizierung (kein Passwort-Management nötig)
Bot-Zugang: Telegram-Benutzer-ID als eindeutiger Identifikator
B2B-Zugang: API-Key-basierte Authentifizierung mit Unternehmens-ID
Admin-Zugang: Separater sudo-Login mit IP-Logging
Stealth Mode: Cookie-basierte Zugangssteuerung auf Domain-Ebene

Zugriffsberechtigungen

Aktion	owner	admin	editor	viewer	api-only	auditor
Dokumente hochladen	✅	✅	✅	❌	✅	❌
Archiv einsehen	✅	✅	✅	✅	❌	✅
Audit-Trail einsehen	✅	✅	❌	❌	❌	✅
Team verwalten	✅	✅	❌	❌	❌	❌
Einstellungen ändern	✅	✅	❌	❌	❌	❌
Daten exportieren	✅	✅	❌	❌	❌	❌
GoBD-Export (Z3)	✅	❌	❌	❌	❌	❌

Erfassungskontrollen

PDF-Validierung: Dimensionsprüfung, Seitenanzahlprüfung, Dekompressionsbomben-Schutz
KI-Plausibilitätsprüfung: Mehrstufige Fallback-Kette (funktionsabhängig) mit Confidence-Score
Automatische Metadaten-Extraktion mit strukturierter JSON-Validierung
Aufbewahrungsfrist-Automatik: kategorien- und datumsabhängig (6/8/10 Jahre nach §147 AO und BEG IV)

Verarbeitungskontrollen

SHA-256 Hash-Berechnung vor dem Upload (Integritätssicherung)
Automatische Sperrung (Auto-Lock) unmittelbar nach erfolgreicher Archivierung
Audit Trail für alle Metadatenänderungen (Trigger-basiert)
Fehlerprotokollierung mit Status „failed" bei Verarbeitungsfehlern

Zugriffsprotokollierung

Tabelle access_log: User-ID, Ressourcentyp, Aktion, IP-Adresse, Zeitstempel
Tabelle audit_log: Admin-Aktionen mit IP und Detail
Tabelle archive_audit_trail: Alle Feldänderungen an Archiveinträgen

Datensicherungskonzept

Backup-Strategie

Ebene	Methode	Intervall	Aufbewahrung
Datenbank (SQLite)	Dateibasiertes Backup (`archiver.db`)	Täglich	30 Tage rollierend
Dokumente	Google Drive (Cloud-Speicher)	Echtzeit	Gemäß Aufbewahrungsfrist
Quellcode	Git-Repository	Bei jeder Änderung	Unbegrenzt
Konfiguration	Nginx/System-Konfig-Backup	Bei Änderung	Vorherige Version

Wiederherstellung (Disaster Recovery)

SQLite-Datenbank aus dem letzten täglichen Backup wiederherstellen
Dokumente sind über Google Drive jederzeit zugreifbar
Anwendung aus Git-Repository neu deployen
Nginx-Konfiguration aus Backup wiederherstellen
Integritätsprüfung aller Dokument-Hashes durchführen

Verfügbarkeit

Server-Uptime-Ziel: 99,5%
Health-Check-Endpoint zur automatisierten Überwachung
Google Drive als redundanter Dokumentenspeicher (99,9% SLA von Google)

Aufbewahrung und Archivierung

Aufbewahrungsfristen

Automatische Fristberechnung: Das System setzt die Aufbewahrungsfrist kategorien- und datumsabhängig gemäß §147 AO i. V. m. BEG IV:
• 10 Jahre — z. B. Jahresabschlüsse/Bilanzen und bestimmte Unterlagen nach §147 AO
• 8 Jahre — bestimmte Buchungsbelege ab 2025 (BEG IV, dokumenttypabhängig)
• 6 Jahre — insbesondere Geschäftsbriefe/sonstige Unterlagen nach §147 AO

Löschschutz

Trigger trg_archive_no_delete: Verbietet jegliches DELETE auf der Archivtabelle
Trigger trg_archive_retention_guard: Blockiert Soft-Delete (drive_deleted = 1) vor Ablauf der Aufbewahrungsfrist
Kein Benutzer, Administrator oder Systemprozess kann Archiveinträge physisch löschen

Originalformat-Aufbewahrung

PDFs werden im Originalformat in Google Drive gespeichert
Bilder werden in PDF konvertiert — sowohl Original als auch Konvertierung werden referenziert
Der SHA-256-Hash bezieht sich auf die final archivierte Version

Hinweis zum Altbestand der Web-Uploads (Stand 2026-06-10): Web-Upload-Dokumente (B2C-Pfad), die vor dem Merge des zugehörigen Fixes (2026-06-10) archiviert wurden, wurden ohne SHA-256-Integritäts-Hash archiviert. Ab diesem Datum wird der Hash bei der Archivierung über die tatsächlich gespeicherten Bytes erzeugt; zusätzlich wird der tatsächlich genutzte KI-Provider je Archiveintrag persistiert (Art. 15 DSGVO / Art. 50 KI-VO). Für Altbestände kann ein nachträglich berechneter Hash die Integrität nur ab dem Zeitpunkt der Nachberechnung belegen, nicht ab der Originalarchivierung. Die Altbestände werden nicht nachträglich verändert.

Datenzugriff für die Betriebsprüfung (Z1/Z2/Z3)

Gemäß §147 Abs. 6 AO

Z1 — Unmittelbarer Zugriff (§147 Abs. 6 AO)

MintFolder stellt eine dedizierte Auditor-Rolle (Betriebsprüfer) bereit, die ausschließlich lesenden Zugriff auf das Archivsystem gewährt:

Zugangseinrichtung

Der Unternehmensinhaber (Owner) lädt den Betriebsprüfer per E-Mail ein (POST /api/b2b/auditor/invite).
Der Prüfer erhält eine zeitlich begrenzte Einladung (Standard: 30 Tage).
Nach Annahme erhält der Prüfer die Rolle auditor im Team-System.
Nach Ablauf der Frist wird der Zugang automatisch deaktiviert.
Der Inhaber kann den Zugang jederzeit vorzeitig widerrufen.

Technische Absicherung (Defense-in-Depth)

Schicht 1 — Middleware: Alle nicht-GET-Anfragen (POST, PUT, DELETE) werden für die Auditor-Rolle mit HTTP 403 blockiert. Jeder blockierte Schreibversuch wird im Audit-Trail protokolliert.
Schicht 2 — Datenbank-Trigger: Unabhängig von der Rolle blockieren die bestehenden GoBD-Trigger (trg_archive_no_tamper_core, trg_archive_no_delete u.a.) jede Änderung an gesperrten Archiveinträgen auf Datenbankebene.
Schicht 3 — Audit-Trail: Jeder lesende Zugriff des Prüfers wird in der unveränderlichen archive_audit_trail-Tabelle mit Zeitstempel, IP-Adresse und User-Agent protokolliert (Aktion: auditor_read).

Zugriffsbereiche des Prüfers

Alle Archiveinträge mit vollständigen Metadaten
Audit Trail (alle Änderungen an Archiveinträgen)
Zugriffsprotokoll (wer hat wann auf welche Daten zugegriffen)
Integritätsprüfung (/api/gobd/verify-integrity)
Hash-Chain-Verifizierung (/api/gobd/proof-chain)
Filter- und Suchfunktionen nach Datum, Kategorie, Betrag etc.

Einschränkungen

Kein Zugriff auf Z3-Datenexport (nur Owner/Admin)
Kein Zugriff auf Team-Verwaltung, Billing oder Einstellungen
Keine Schreiboperationen möglich (technisch erzwungen)

Z2 — Mittelbarer Zugriff

Z2 — Mittelbarer Zugriff: Über /api/gobd/verify-integrity können Hash-Integritätsprüfung, Audit-Trail-Verifizierung und Aufbewahrungsfristen-Status abgerufen werden.

Z3 — Datenüberlassung

Über /api/gobd/export-z3 als ZIP-Archiv: DATEV-Export (EXTF v7.0), Archivdaten mit Metadaten, SHA-256 Validierungshashes.

Konvertierung & Scan & Digitalisierung

Scanverfahren

Bildaufnahme: Kamera/Upload über Web, Bot oder Scanner-Modul
Bildoptimierung: Automatische Scanner-Effekt-Anwendung (Kontrast, Entzerrung)
PDF-Konvertierung: Bild wird in archivtaugliches PDF konvertiert
OCR: Optische Zeichenerkennung für Volltextsuche (sofern aktiviert)
Qualitätsprüfung: Dimensionsprüfung, Mindestauflösung, Dekompressionsbomben-Schutz
Archivierung: Standardverfahren mit Hash-Berechnung und Auto-Lock

Konvertierungsrichtlinie

Grundsatz: Bei der Konvertierung von Bildern in PDF wird sichergestellt, dass:
• Kein inhaltlicher Informationsverlust stattfindet
• Die bildliche Übereinstimmung mit dem Original gewährleistet ist
• Der Konvertierungsprozess im Audit-Trail protokolliert wird
• Der SHA-256-Hash sich auf das Originaldokument bezieht (vor Konvertierung)

Originalformat-Erhaltung (Dual-Version Storage)

Prinzip: Bei jeder Konvertierung (z.B. JPG→PDF, OCR) werden beide Versionen in Google Drive gespeichert:
• original_drive_file_id — Referenz auf die bit-exakte Originaldatei
• drive_file_id — Referenz auf die konvertierte/verarbeitete Version
• Bei Dateien ohne Konvertierung (z.B. PDF-Upload) sind beide Referenzen identisch.
• document_hash (SHA-256) wird vor der Konvertierung berechnet und bezieht sich auf die Originaldatei.
• Die Originalreferenz ist durch den Datenbank-Trigger trg_archive_original_immutable unveränderlich geschützt — einmal gesetzt, kann sie nicht mehr überschrieben werden (Ausnahme: DSGVO-Löschung).

Änderungshistorie

Datum	Version	Änderung	Verantwortlich
17.03.2026	1.0	Erstdokumentation gemäß GoBD 2019	Thaeer Sukay
17.03.2026	1.0	Implementierung aller technischen GoBD-Maßnahmen	Thaeer Sukay
24.03.2026	1.3.0	Aktualisierung: Trigger-Anzahl, API-Endpoints, DSGVO-Pseudonymisierung, Vault-Integration	Thaeer Sukay
07.04.2026	1.4.0	Transfervermerk (Rz. 130-146): Automatische Erstellung bei Archivierung, WORM-geschützt, Papiervernichtungs-Genehmigung. Betriebsprüfer-Zugang (Rz. 155-163): Token-basierter Z1/Z2-Zugang mit Protokollierung, Such-UI, Z3-Export. eIDAS AdES Signatur: RSA-PSS-SHA256 Dokumentensignierung gemäß §14 UStG + eIDAS Art. 26.	Thaeer Sukay
08.04.2026	2.2	BEG IV: Aufbewahrungsfristen aktualisiert (8/10 Jahre); GoBD 2024/2025 Rechtsgrundlagen ergänzt; Z3-Terminologie aktualisiert; KI-Pipeline auf 5-stufige Fallback-Kette aktualisiert	Thaeer Sukay
16.04.2026	2.3	Z1 Unmittelbarer Zugriff: Dedizierte Auditor-Rolle (Betriebsprüfer) mit zeitlich begrenztem read-only Zugang, Middleware-Schreibschutz (HTTP 403), vollständige Zugriffsprotokollierung im Audit-Trail (auditor_read/auditor_write_blocked), Defense-in-Depth-Dokumentation.	Thaeer Sukay
16.04.2026	2.4	Originalformat-Erhaltung (Dual-Version Storage): Neues Feld original_drive_file_id für bit-exakte Originalreferenz, Unveränderlichkeits-Trigger trg_archive_original_immutable, Backfill bestehender Einträge, document_hash bezieht sich auf Originaldatei vor Konvertierung, DSGVO-Löschung berücksichtigt.	Thaeer Sukay
08.06.2026	2.5	Live-Abgleich GoBD-Sprints 4–5: Trigger-Gesamtbestand 81 → 91; Definitionsstelle der Schema-/Trigger-Definitionen `db/_core.py` → `db/schema.py` (Migrations-Runner verbleibt in `db/_core.py`); `schema_version` v729; DATEV-Festschreibung der B2B-Belege gem. §146 Abs. 4 AO (Spalte `datev_locked` + 5 Festschreibungs-Trigger auf `b2b_usage_logs`); Aufbewahrungsfristen 8/10/6 Jahre (BEG IV); Rechtsgrundlage GoBD i.d.F. des BMF-Schreibens vom 14.07.2025 (2. Änderung).	Thaeer Sukay
09.06.2026	2.6	GoBD-Sprint 6: E-Rechnung-Schematron-Validierung (EN16931) — eingehende Belege werden markiert und stets archiviert (§147 AO), ausgehende Rechnungen bei Schematron-Verstoß mit HTTP 422 abgelehnt; GDPdU-/Z3-Export (Audicon-konform: `index.xml` + `gdpdu-01-08-2002.dtd` + `journal.csv`) gem. §147 Abs. 6 AO; 2 neue Festschreibungs-Trigger ergänzt; Trigger-Gesamtbestand 91 → 93; `schema_version` v729 → v732.	Thaeer Sukay
10.06.2026	2.6	Audit-Remediation Block 4 (COMP-002/COMP-008): B2C-Web-Upload-Pfad archiviert seit 10.06.2026 mit SHA-256-Integritäts-Hash über die tatsächlich gespeicherten Bytes (gleicher Mechanismus wie Telegram-Bot- und B2B-Pfad) sowie mit KI-Provider-Provenance je Archiveintrag (Art. 15 DSGVO / Art. 50 KI-VO). Datierter Hinweis zum hash-losen Altbestand der Web-Uploads ergänzt; Altbestände werden nicht nachträglich verändert.	Thaeer Sukay

Hinweis: Diese Verfahrensdokumentation ist ein lebendes Dokument und muss bei jeder wesentlichen Änderung am System aktualisiert werden. Die nächste reguläre Überprüfung erfolgt spätestens am 09. Dezember 2026 (halbjährlich).

Für ein rechtsverbindliches Testat wenden Sie sich an eine zugelassene Wirtschaftsprüfungsgesellschaft (z.B. nach IDW PS 880 für GoBD oder ISO 27001 für Informationssicherheit).

Interne Dokumentation · Kein Testat · Stand: 2026-06-13 · Version 2.6