GoBD-Verfahrensdokumentation

1.1 Adressatenkreis

Diese Verfahrensdokumentation richtet sich an den Steuerberater des Mandanten, an etwaige Betriebsprüfer der Finanzverwaltung sowie an den Mandanten selbst. Sie ist Grundlage für die Beurteilung der GoBD-Konformität der mit der Software geführten Aufzeichnungen.

1.2 Abgrenzung

Die Verantwortung für eine GoBD-konforme Buchführung im Sinne der jährlichen Steuererklärung obliegt weiterhin dem Mandanten und seinem Steuerberater. Immobilien Butler stellt die technischen Voraussetzungen sowie die in dieser Dokumentation beschriebenen Verfahren bereit.

2.1 Architektur

Immobilien Butler ist eine mandantenfähige Web-Anwendung auf Basis von Next.js 15 (TypeScript, React 19). Frontend und API werden über Vercel in der EU-Region (fra1, Frankfurt am Main) ausgeliefert. Die Datenhaltung erfolgt in einer PostgreSQL-Datenbank, verwaltet durch Supabase auf AWS in Frankfurt (eu-central-1). Hintergrundjobs (OCR-Erkennung, Sollstellungs-Generierung, Mahnwesen, NK-Verteilung) laufen serverseitig als API-Routen bzw. Cron-Jobs.

2.2 Mandantentrennung

Jeder Datensatz trägt eine `tenant_id`. Die Anwendungsschicht filtert alle Lese- und Schreiboperationen über einen Prisma-Wrapper, der eine fehlende Mandantenfilterung zur Laufzeit erkennt. Auf Datenbankebene wird zusätzlich Row-Level-Security (PostgreSQL RLS) eingeführt; der Rollout erfolgt schrittweise und ist in den Release-Notes dokumentiert.

2.3 Kontenrahmen und Kostenstellen

Verwendeter Kontenrahmen ist SKR-03 V+V in der DATEV-Spezialvariante für Vermietung und Verpachtung. Pro Liegenschaft wird eine vierstellige Kostenstelle vergeben, pro Einheit eine vierstellige Sub-Kostenstelle. Diese Struktur bildet eine Anlage V pro Liegenschaft 1:1 ab.

2.4 Mehrsprachigkeit und Lokalisierung

Benutzeroberfläche, Korrespondenz und sämtliche Auswertungen erfolgen in deutscher Sprache nach deutscher Konvention (Datum TT.MM.JJJJ, Beträge mit Komma als Dezimaltrennzeichen, Währung EUR).

3.1 Eingangskanäle

• Web-Upload: Drag-and-drop oder Dateiauswahl unter /belege/neu. Der hochladende Benutzer wird mit Zeitstempel und IP-Adresse protokolliert.
• Mobile-Scanner: Foto-Scan über das integrierte mobile UI (Kamera mit Mehrseiten-PDF-Aufbau).
• Inbound-E-Mail: Weiterleitung an belege@<mandant>.immobilien-butler.com über den Postmark-Inbound-Webhook. Anhänge werden je als Belegkandidat angelegt; die Roh-EML bleibt revisionssicher abgelegt.

3.2 Datenerkennung (OCR)

Hochgeladene Belege werden über die Anthropic-Claude-Vision-API analysiert. Die KI extrahiert Belegdatum, Brutto-/Netto-/USt-Betrag, Lieferant, mögliche Zuordnung zu Liegenschaft/Einheit sowie einen Vorschlag für das SKR-03-V+V-Konto. Die Confidence wird je Feld gespeichert; Werte unterhalb des Schwellwerts werden im Review-UI explizit gekennzeichnet. Die Verarbeitung erfolgt im Auftrag des Verantwortlichen; eine Modell-Trainingsnutzung ist vertraglich ausgeschlossen.

3.3 Prüfung und Freigabe

Kein Beleg wird ohne menschliche Sichtprüfung gebucht. Bei der Freigabe wird der Status auf POSTED gesetzt und das System vergibt in derselben Transaktion eine lückenlose Belegnummer (siehe §6.4); Pflichtfelder sind Belegdatum, Brutto-Betrag, Liegenschaft (Kostenstelle), SKR-03-Konto, Umlagefähigkeit (für die Nebenkostenabrechnung) sowie ggf. BetrKV-Paragraf. Die Originaldatei bleibt unverändert mit dem Beleg verknüpft und ist über den ursprünglichen Hash referenzierbar.

3.4 Stornos und Korrekturen

Korrekturen an gebuchten Belegen erfolgen ausschließlich durch eine Storno-Buchung mit Verweis auf den Originalbeleg — niemals durch stille Änderung. Bearbeitungen vor der Buchung (Status PENDING / REVIEW) werden im Audit-Log mit Vorher-/Nachher-Stand protokolliert.

4.1 Import

Bankumsätze werden über CSV-Import (CAMT.053 / MT940 / bankspezifische CSV) eingespielt. Doppel-Eingänge werden über eine Hash-Prüfung (IBAN + Buchungsdatum + Betrag + Verwendungszweck) erkannt und unterdrückt. Eine PSD2-Anbindung über finAPI (BaFin-lizenziert) ist als Folgeschritt vorgesehen.

4.2 Zuordnung (Reconciliation)

Jede Banktransaktion wird einem oder mehreren Ziel-Vorgängen zugeordnet: MietzahlungSoll (Mieteingang), Beleg (Ausgabe), Kaution (Kautionseingang) oder einer manuellen Sonstige-Buchung. Mehrfachzuordnungen erfolgen über Splits; die Summe der Splits entspricht exakt dem Transaktionsbetrag — die Anwendung lässt eine Inkongruenz nicht zu.

4.3 KI-gestützte Zuordnungsvorschläge

Für unzugeordnete Transaktionen können Vorschläge durch ein LLM erzeugt werden. Die Vorschläge sind ausdrücklich Vorschläge — sie werden gespeichert und im UI angezeigt, jedoch nie ohne explizite Benutzerbestätigung übernommen.

4.4 Status

Transaktionen durchlaufen die Stati UNALLOCATED → PARTIALLY_ALLOCATED → ALLOCATED bzw. IGNORED. Jeder Statusübergang und jede Zuordnungsänderung wird im Audit-Log protokolliert.

5.1 Mietzahlungs-Sollstellung

Bei Aktivierung eines Mietvertrags werden für die folgenden zwölf Monate Sollstellungsdatensätze erzeugt. Ein Hintergrundjob ergänzt zum Monatswechsel jeweils den nächsten Monat. Archivierte oder beendete Mietverträge erzeugen keine neuen Sollstellungen mehr und fließen nicht in aktive KPIs ein.

5.2 Nebenkostenabrechnung

Umlagefähige Belege je Liegenschaft werden zum Abrechnungsstichtag aggregiert und nach Verteilerschlüssel (Wohnfläche, Personen, Verbrauch) auf die im Zeitraum aktiven Mietverträge verteilt. Jede Position bleibt bis auf den einzelnen Beleg rückverfolgbar. Der Versand an Mieter erfolgt ausschließlich über den MailDraft-Workflow mit expliziter Freigabe — eine automatische Ausgangssendung ist systemseitig nicht vorgesehen.

5.3 Mahnwesen

Überfällige Sollstellungen werden im Mahnwesen-Modul aggregiert. Mahnstufen, Mahngebühren und Verzugszinsen werden je Mandant konfiguriert. Der Versand folgt demselben MailDraft-Pattern mit Vorschau, Freigabe und einzeln-/stapelweisem Versand.

6.1 Vorgehensweise

Gebuchte Belege, zugeordnete Banktransaktionen sowie Soll-Bezahlt-Verknüpfungen sind nach Abschluss eines Buchungszeitraums (Monat oder Jahr) festgeschrieben. Änderungen sind im Anwendungsfall blockiert; Korrekturen erfolgen ausschließlich über eine offene Folgeperiode mit Storno- und Neubuchung.

6.2 Auslösung

Die Festschreibung wird durch einen Mandant-Administrator manuell unter /finanzen/festschreibung ausgelöst — wahlweise pro Kalenderjahr (`kind = YEAR`) oder pro Kalendermonat (`kind = MONTH`). Zeitpunkt, Periodenende und Auslöser werden im Audit-Log (`booking_period.closed`) mit Vorher-/Nachher-Stand protokolliert. Eine Wiedereröffnung ist ausschließlich dem Anbieter (MASTER_ADMIN) vorbehalten, erfordert eine schriftliche Begründung und wird ebenfalls vollständig auditiert (`booking_period.reopened`).

6.3 Defense-in-Depth

Die Festschreibung wird zusätzlich datenbankseitig durch Trigger auf den Tabellen `bank_transactions`, `bank_transaction_splits`, `belege` und `mietzahlung_soll` gegen direkte Datenmanipulation abgesichert — Änderungen an Datensätzen, deren effektives Buchungsdatum in einer festgeschriebenen Periode liegt, werden mit einem ERROR zurückgewiesen. Weitere Trigger sichern die Belegnummer (unveränderlich nach Vergabe), das Audit-Log (append-only, siehe §8.2), die Inhalts-Identität archivierter Dateien (§10.4) sowie die Aufbewahrungsfristen (§10.1) ab.

6.4 Lückenlose Belegnummerierung

Jeder gebuchte Beleg erhält im Buchungszeitpunkt eine systemseitig vergebene, je Mandant und Kalenderjahr fortlaufende Belegnummer (Format „JJJJ-00001"). Die Vergabe erfolgt in derselben Datenbank-Transaktion wie die Buchung selbst — abgebrochene Buchungen hinterlassen keine Lücke, parallele Buchungen serialisieren auf dem Nummernkreis. Die Nummer ist nach Vergabe unveränderlich (Datenbank-Trigger); stornierte oder gelöschte (soft-delete) Belege behalten ihre Nummer, sodass die Lückenlosigkeit der Folge jederzeit prüfbar bleibt (GoBD Vollständigkeit). Die Belegnummer ist von der Rechnungsnummer des Lieferanten unabhängig und wird im DATEV-Export als Belegfeld 1 übergeben.

7.1 DATEV-Buchungsstapel

Unter /finanzen/export erzeugt das System einen EXTF-CSV-Export im DATEV-Standardformat (Format-Version 9, Zeichensatz Windows-1252, Trennzeichen Semikolon, Dezimaltrennzeichen Komma). Exportiert werden alle zugeordneten Banktransaktionen sowie manuelle Soll-Buchungen des gewählten Zeitraums. Der Export ist beliebig oft reproduzierbar; die erzeugte Datei entspricht der DATEV-Importspezifikation für Buchungsstapel.

7.2 Anlage V (Vorabausfüllung)

Pro Liegenschaft und Steuerjahr wird unter /finanzen/anlage-v eine vorausgefüllte Anlage V auf Basis der gebuchten Einnahmen (SKR-03 V+V Erlöskonten) und Werbungskosten (Aufwandskonten inkl. AfA) bereitgestellt. Die Zuordnung der Konten zu den Zeilen der Anlage V folgt der DATEV-V+V-Konvention.

7.3 GDPdU / Z3-Datenträgerexport

Für den Datenzugriff Z3 (Datenträgerüberlassung) gemäß GoBD/GDPdU stellt das System unter /finanzen/export einen IDEA-konformen Export bereit. Geliefert werden zwei Dateien (index.xml gemäß AWV-Beschreibungsstandard 1.0 + Buchungen.csv im UTF-8-Format mit RFC-4180-Quoting), die der Steuerberater bzw. Betriebsprüfer in dasselbe Verzeichnis legt und in IDEA über die index.xml einliest. Der Buchungsumfang entspricht dem DATEV-Stapel (allokierte Banktransaktionen + manuelle Soll-Buchungen).

7.4 EÜR

Eine Einnahmen-Überschuss-Rechnung gemäß § 4 Abs. 3 EStG steht für Mandanten zur Verfügung, die nicht nach Anlage V abrechnen. Konten-Aggregation und Mapping sind unter /finanzen/euer einsehbar.

8.1 Rollen

• MASTER_ADMIN: Systemanbieter; mandantenübergreifender Support, kein Zugriff auf Mandantendaten ohne dokumentierten Auftrag.
• ADMIN: Mandant (Vermieter); alle Rechte innerhalb des eigenen Mandanten.
• USER: Vom ADMIN eingeladene Mitarbeiter mit feingranularen Permissions.
• STEUERBERATER: Per-Mandant-Rolle für den vom Mandanten beauftragten Steuerberater. Strikt lesender Zugriff auf Stammdaten (Liegenschaften, Mietverträge), Bankumsätze, Audit-Log sowie die Auswertungen DATEV-Buchungsstapel, Anlage V und EÜR. Keine Schreibrechte; `grantedPermissions` werden für diese Rolle bewusst ignoriert.

8.2 Audit-Log

Jede schreibende Operation (Create/Update/Delete) auf rechnungs- und steuerrelevanten Entitäten — Eigentümer, Liegenschaft, Einheit, Mietvertrag, Mieter, Kaution, Mietzahlungssoll, Bankkonto, Banktransaktion, Beleg, Lieferant, MailDraft, Nebenkostenabrechnung — wird in der `audit_log`-Tabelle mit Benutzer-ID, Aktion, Entität, Vorher- und Nachher-Stand sowie Zeitstempel protokolliert. Das Audit-Log ist unter /audit-log einsehbar und append-only: ein Datenbank-Trigger weist jedes UPDATE und jedes DELETE innerhalb der zehnjährigen Aufbewahrungsfrist (§ 147 AO) zurück. Buchungsrelevante Protokolleinträge werden damit so lange aufbewahrt wie die Buchungen, die sie beschreiben.

8.3 Zwei-Faktor-Authentifizierung

Authenticator-App-basiertes TOTP (RFC 6238, ±1-Step-Toleranz) ist für MASTER_ADMIN- und ADMIN-Rollen verpflichtend, für USER optional und mandantenweit erzwingbar. Recovery-Codes werden ausschließlich als sha256-Hashes gespeichert. TOTP-Secrets werden mit AES-256-GCM verschlüsselt abgelegt (Schlüssel: `TWOFACTOR_ENC_KEY`, außerhalb der Datenbank).

8.4 Zugang und Passwörter

Selbstregistrierung ist deaktiviert. Der Systemanbieter legt den ersten ADMIN je Mandant an; weitere Benutzer werden vom ADMIN eingeladen. Initial-Passwörter müssen beim ersten Login geändert werden (`mustChangePassword`-Flag). Passwort-Hashing erfolgt mit bcrypt (Cost-Factor ≥ 10).

8.5 Vier-Augen-Prinzip im Zahlungsverkehr

Ausgangskorrespondenz an Mieter, Vendoren und externe Parteien (Mahnwesen, NK-Versand, Mieterhöhung, Vertragsdokumente) erfolgt durchgängig im Entwurf-/Freigabe-Modus über `MailDraft`: jede Sendung wird gestaltet, optional bearbeitet und einzeln oder als Stapel freigegeben — eine automatische Ausgangssendung ist systemseitig ausgeschlossen.

9.1 Transport- und Speicherverschlüsselung

Alle Verbindungen zur Anwendung erfolgen ausschließlich über TLS 1.2+. Die Datenbank (Supabase / PostgreSQL) speichert at-rest verschlüsselt. Dateispeicherung erfolgt auf S3-kompatiblem Objektspeicher (Cloudflare R2, EU-Jurisdiktion). Sensible Felder (TOTP-Secrets) werden zusätzlich applikationsseitig AES-256-GCM-verschlüsselt.

9.2 DSGVO und AVV

Mit jedem Mandanten wird ein Auftragsverarbeitungsvertrag (AVV) geschlossen. Mit allen Subprozessoren bestehen entsprechende AVVs. Datenresidenz: EU. Die jeweils aktuelle Liste der Subprozessoren ist unter /subprozessoren öffentlich einsehbar.

9.3 Notfallmanagement

Datenpannen werden gemäß Art. 33/34 DSGVO über die in /datenpanne beschriebene Prozedur dokumentiert, gemeldet und nachgehalten. Wiederanlaufpläne und Backup-Strategie sind im TOM-Dokument hinterlegt.

10.1 Aufbewahrungsfrist und Inhalt

Aufbewahrungspflichtige Daten — alle gebuchten Belege, Bankumsätze, Soll-Buchungen, Mietverträge, Nebenkostenabrechnungen und das Audit-Log — werden mindestens 10 Jahre aufbewahrt (§ 147 AO; die Frist läuft ab Ende des Kalenderjahres der Entstehung). Die Frist wird datenbankseitig erzwungen: Trigger auf `documents`, `belege` (gebuchte Datensätze) und `audit_logs` weisen jede physische Löschung vor Fristablauf zurück; anwendungsseitige Löschungen sind grundsätzlich Soft-Deletes (`deleted_at`), die den Datensatz aus operativen Sichten entfernen, aber vollständig erhalten. Eine rechtmäßige endgültige Löschung (Vertragsende nach AGB §9, abgelaufene Frist) erfolgt ausschließlich über eine dokumentierte Operator-Prozedur mit vorherigem Vollexport. Belegoriginale werden unverändert mit ihrem ursprünglichen Hash referenziert; Änderungen an Originaldateien sind nicht vorgesehen.

10.2 Backup und WORM-Replikat

Die PostgreSQL-Datenbank wird täglich durch Supabase gesichert; Point-in-Time-Recovery innerhalb der Provider-Retention ist möglich. Die R2-Objektablage ist redundant ausgelegt und wird von der Anwendung ausschließlich write-once genutzt (die Storage-Schicht besitzt keine Lösch- oder Überschreib-Funktion; Objektschlüssel sind eindeutig). Zusätzlich wird der vollständige Belegdatei-Bestand täglich als einseitige Kopie (rclone copy, --immutable) in ein unabhängiges WORM-Replikat übertragen: ein AWS-S3-Bucket in Frankfurt (eu-central-1) mit S3 Object Lock im Compliance-Modus und zehnjähriger Default-Retention — dort abgelegte Objekte können vor Fristablauf von niemandem gelöscht oder überschrieben werden, auch nicht vom Konto-Inhaber. Die Replikations-Zugangsdaten (lesend auf R2, schreibend auf das Replikat, ohne Löschrechte) liegen auf einem von der Anwendung getrennten System und sind der Anwendung nicht bekannt. Erstes vollständiges Replikat: 07.07.2026, verifiziert per rclone check (0 Abweichungen).

10.3 Verantwortung

Die zehnjährige Aufbewahrungspflicht der originären Buchhaltungsunterlagen liegt nach deutschem Steuerrecht weiterhin beim Mandanten. Immobilien Butler stellt zu jedem Zeitpunkt einen vollständigen Datenexport zur Verfügung (DATEV-Buchungsstapel, GDPdU-Z3-Datenträger, Belegoriginale als Einzeldownload; ein ZIP-Sammelexport der Belegoriginale ist in Einführung) und unterstützt so die mandantenseitige Aufbewahrungspflicht.

Status: Status ZIP-Sammelexport: in Einführung

10.4 Integritätsprüfung des Archivs

Der SHA-256-Hash jeder archivierten Datei wird bei der Aufnahme erfasst und ist datenbankseitig unveränderlich (Trigger auf `documents`: Hash und Erfassungszeitpunkt können nicht verändert werden). Eine periodische Integritätsprüfung lädt die Objekte aus der R2-Ablage, berechnet die Hashes neu und vergleicht sie mit den erfassten Werten — einschließlich soft-gelöschter Dokumente, die sich noch in der Aufbewahrungsfrist befinden. Jeder Lauf und jede Abweichung wird im Audit-Log protokolliert (`document.integrity_check` / `document.integrity_violation`). Turnus: quartalsweise, zusammen mit der Restore-Übung (ops/RUNBOOK.md).

11.1 Anbieter (Immobilien Butler)

• Bereitstellung und Betrieb der Software gemäß dieser Dokumentation.
• Audit-Log, Festschreibungsmechanismus, Mandantentrennung, Backups, EU-Datenresidenz.
• Bereitstellung von DATEV-, Anlage-V- und GDPdU-Exporten.
• AVVs mit Subprozessoren; laufende TOM-Pflege gem. Art. 32 DSGVO.

11.2 Mandant (Vermieter)

• Vollständige und zeitgerechte Erfassung sämtlicher Geschäftsvorfälle.
• Sachliche und rechnerische Richtigkeit der erfassten Daten.
• Sichtprüfung und Freigabe der OCR-Vorschläge vor jeder Buchung.
• Regelmäßige Kontenabstimmung (mindestens monatlich, vor Festschreibung).
• Festschreibung abgeschlossener Perioden.
• 10-jährige Aufbewahrung der Originalunterlagen (§ 147 AO).
• Pflege des mandantenspezifischen Annex zu dieser Verfahrensdokumentation.

11.3 Steuerberater

Die GoBD-Konformität der Buchführung im Sinne der jährlichen Steuererklärung wird vom Steuerberater des Mandanten festgestellt. Immobilien Butler stellt die technischen Voraussetzungen bereit; die buchhalterische Würdigung obliegt dem Steuerberater.