📋

Verfahrensdokumentation nach GoBD

Gemäß BMF-Schreiben vom 28.11.2019 (BStBl I 2019, S. 1269), geändert durch BMF-Schreiben vom 11.03.2024 (BStBl I 2024, S. 374) und 14.07.2025

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 — laufende Produktionsfassung

Erstellt am: 17. März 2026

Verantwortlich: MintFolder AI UG (haftungsbeschränkt), vertreten durch Thaeer Sukay

Status: Interne Dokumentation (Selbstprüfung)

Rechtsgrundlage: §§ 145-147 AO, GoBD 2019 in der jeweils geänderten Fassung (u. a. 2024/2025)

Nächste Prüfung: 17. März 2027

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	PE	6-10 Jahre (einzelfallabhängig)	§147 AO, §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: Lokale/rule-basierte Vorverarbeitung und funktionsabhängige Fallback-Kette (Ollama/lokale Regeln → Gemini → Claude → GPT-4o) extrahiert Metadaten; Groq ist dekommissioniert
Klassifizierung: Automatische Zuordnung zu Kategorie, Kürzel und Aufbewahrungsfrist
Hash-Berechnung: SHA-256-Hash des Dokuments wird vor der Speicherung berechnet
Zielablage: B2C-Dokumente werden in Google Drive gespeichert; B2B-Dokumente können je nach Vertrag im Hetzner Object Storage Vault gespeichert werden
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

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; Hetzner Object Storage für B2B Vault	Dokumentenspeicherung je nach Produktmodus
KI-Engine	Lokale Regeln/Ollama, Gemini, Claude, OpenAI (funktionsabhängig)	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 bzw. B2B-Vault-Referenz
`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/10)
`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)

Gesamt: 63 SQLite-Trigger — Basis-Trigger + DATEV-Exportschutz-Trigger + Transfervermerk-Trigger + eIDAS-Signatur-Trigger + weitere Integritäts-Trigger.

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 der Speicherung in der Zielablage (Google Drive oder B2B Vault), 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.
Externe Attestierung (manipulationserschwerender Nachweis — E-Mail-Attestierung): Die Funktion send_to_worm_storage() wird nach jeder Versiegelung durch den Scheduler (scheduler.py, alle 5 Minuten) automatisch aufgerufen. Der aktuelle Ketten-Kopf-Hash (chain_head) wird per E-Mail-API an [email protected] übermittelt. Die E-Mail dient als zeitgestempelter, extern nachvollziehbarer Nachweis — unabhängig von der MintFolder-Infrastruktur, da der E-Mail-Dienst die Nachricht auf eigenen Servern vorhält. Bei Ausfall der E-Mail-API greift ein lokales Fallback-Log (worm-attestations.log). Diese Kontrolle ist manipulationserschwerend und beweissichernd, ersetzt aber kein externes GoBD-Testat und keine zertifizierte WORM-DMS-Lösung.

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 März 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 (Brevo-messageId, S3-Pfad oder 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.

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	Mehrstufig: Restic/Hetzner primär, zusätzlicher Google-Drive-Backup-Pfad; 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
Dokumente hochladen	✅	✅	✅	❌	✅
Archiv 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)	Verschlüsselte Backups (Restic primär; sekundärer Backup-Pfad)	Regelmäßig/automatisiert	30 Tage rollierend; gesetzliche Archivpfade nach Fristentscheidung
Dokumente	B2C: Google Drive; B2B: Hetzner Object Storage Vault	Echtzeit bzw. nach Verarbeitung	Gemäß Aufbewahrungsfrist und Vertrag
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 je nach Produktmodus über Google Drive oder B2B Vault wiederherstellbar
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 bzw. Hetzner Vault als dokumentierter Ziel-/Archivspeicher je nach Produktmodus

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
Vor Ablauf der Aufbewahrungsfrist kann kein Benutzer, Administrator oder Systemprozess Archiveinträge regulär physisch löschen; nach Fristablauf erfolgt Löschung über dokumentierte Disposal-/Pseudonymisierungsprozesse

Originalformat-Aufbewahrung

PDFs werden im Originalformat in der jeweiligen Zielablage (Google Drive oder B2B Vault) gespeichert
Bilder werden in PDF konvertiert — sowohl Original als auch Konvertierung werden referenziert
Der SHA-256-Hash bezieht sich auf die final archivierte Version

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

Gemäß §147 Abs. 6 AO

Z1 — Unmittelbarer Zugriff

Der Betriebsprüfer erhält über den Admin-Zugang (/api/gobd/audit-trail) Lesezugriff auf:

Alle Archiveinträge mit vollständigen Metadaten
Audit Trail (alle Änderungen an Archiveinträgen)
Zugriffsprotokoll (wer hat wann auf welche Daten zugegriffen)
Filter- und Suchfunktionen nach Datum, Kategorie, Betrag, etc.

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 archivierte Endformat bezieht

Ä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 Fallback-Kette aktualisiert	Thaeer Sukay
21.05.2026	2.3	Rechts- und Transparenzabgleich: Groq entfernt, lokale KI-Kette und B2B-Vault-Speicher ergänzt, Google Drive/B2B-Zielablage präzisiert, WORM-Überbehauptung zu manipulationserschwerender externer Attestierung korrigiert, GoBD 2025-Änderung referenziert.	Codex-assisted review / 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 17. März 2027.

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: April 2026 · Version 2.2