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; Pflichtfelder sind Belegnummer, 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.

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 ist append-only.

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). Belegoriginale werden unverändert mit ihrem ursprünglichen Hash referenziert; Änderungen an Originaldateien sind nicht vorgesehen.

10.2 Backup

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; Lifecycle-Regeln werden so konfiguriert, dass Belegdateien für den vollen Aufbewahrungszeitraum vorgehalten werden.

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 ZIP-Archiv) und unterstützt so die mandantenseitige Aufbewahrungspflicht.

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.