GenioFlow Master-Workflow Vermietung: 22 Sub-Workflows, Lifecycle-Events und der zentrale Audit-Trail jedes Mietverhältnisses

Ein Mietverhältnis in der Hauptstraße 47, dritter Stock links, beginnt am 1. Oktober 2018. Zwei Erwachsene, ein Kind, Dreieinhalb-Zimmer-Wohnung, 84 Quadratmeter, Kaltmiete 920 Euro. Acht Jahre später, am Vormittag des 12. Mai 2026, sitzt die Sachbearbeiterin vor der Akte und versucht zu rekonstruieren, was in diesen acht Jahren passiert ist. Eine Indexanpassung 2019, eine Modernisierung mit Balkon-Anbau 2020, ein Wasserschaden im Bad 2021, eine Mieterhöhung nach Mietspiegel 2022, eine Untervermietungs-Anfrage 2023, ein Mahnvorgang über zwei Monatsmieten 2024, eine zweite Indexanpassung 2025, eine Kaution-Erhöhung wegen der gestiegenen Miete, ein Schimmelfall an der Außenwand, eine Mieterwechsel-Anfrage des Untermieters, eine Auseinandersetzung über die Nebenkosten-Abrechnung, eine Eigenbedarfs-Kündigung des Vermieters, eine Härtefall-Einrede der Mieterin. Vierzehn Vorgänge in acht Jahren — und in der bisherigen Software liegt jeder Vorgang in einer eigenen Akte, in einem eigenen Tab, in einem eigenen Ordner. Manche in Sharepoint, manche im E-Mail-Postfach, eine in einem PDF auf dem Schreibtisch. Welcher Mahnvorgang gehörte zu welchem Streit über die Nebenkosten? Welche Mieterhöhung war die Reaktion auf die Modernisierung? Hat die Mieterin der Untervermietung damals zugestimmt — oder hat der Verwalter es nur abgenickt. Die Antworten stehen verstreut über vier Systeme, drei Mitarbeiter und acht Jahre.

Genau dieses Problem löst der Master-Workflow Vermietung in GenioFlow: Er führt das Mietverhältnis als zusammenhängenden Vorgang vom ersten Tag bis zum Auszug, und er hängt jede Veränderung als Sub-Workflow an dieser Klammer auf. Vierzehn Vorgänge in acht Jahren sind kein Dossier-Chaos, sondern eine Zeitleiste mit vierzehn Sub-Workflows, jeder für sich revisionssicher, jeder im Kontext des Master-Workflows lesbar.

Warum flache Vorgangsverwaltung scheitert

Klassische Verwaltungssoftware modelliert die Realität in Stammdaten-Tabellen: Mieter, Mietvertrag, Einheit, Objekt. Vorgänge — Mahnung, Mieterhöhung, Schaden — werden als separate Datensätze gespeichert, meist mit einer Fremdschlüsselbeziehung zum Mieter oder zur Einheit. Diese Architektur ist sauber, sie ist normalisiert, und sie scheitert in der Praxis an drei Punkten.

Erstens gehören Vorgänge zum Mietverhältnis, nicht zum Mieter. Wenn nach acht Jahren ein Mieterwechsel stattfindet, bleibt die Wohnung dieselbe, der Mietvertrag startet aber neu. Eine Mahnung gegen den ausziehenden Mieter darf nicht plötzlich am neuen Mieter hängen, eine Modernisierung aus 2020 prägt die heutige Miete, ist aber ein Vorgang am Vertrag von damals. Ohne eine Klammer-Entität „Mietverhältnis” werden Vorgänge entweder doppelt referenziert oder gehen mit dem Wechsel verloren.

Zweitens gehen die Verbindungen zwischen Vorgängen verloren. Eine Kündigung nach § 573c BGB löst zwingend eine Wohnungsübergabe nach sich, diese löst die Kaution-Rückzahlung nach § 551 BGB aus. Wenn beim Auszug Schäden festgestellt werden, sind diese Schäden ein eigener Vorgang, der wiederum die Kaution-Rückzahlung beeinflusst. In einer flachen Verwaltung werden diese drei Vorgänge unabhängig voneinander angelegt — die Verknüpfung lebt nur im Kopf des Sachbearbeiters und im Notizfeld der jeweiligen Akte. Wenn der Sachbearbeiter wechselt, ist die Verknüpfung weg.

Drittens lässt sich der Lifecycle nicht abbilden. Ein Mietverhältnis hat klare Phasen: Vertragsanbahnung, Einzug, laufende Vermietung, Kündigung, Auszug, Abschluss. Welche Aktionen in welcher Phase erlaubt sind, welche zwingend nachgelagert werden, welche automatisch starten — all das verlangt eine Phasen-Logik, nicht ein Statusfeld. Eine Mahnung in der Vertragsanbahnung gibt es nicht. Eine Wohnungsübergabe ohne abgeschlossenen Vertragsabschluss ist sinnlos. Eine Kaution-Rückzahlung vor dem Auszug widerspricht § 551 BGB.

Viertens — und das ist die Folge der ersten drei Punkte — fehlt der automatische Trigger für Folgevorgänge. Eine Kündigung wird ausgesprochen, das Mietende steht fest, und die Verwaltung müsste theoretisch zum Stichtag selbst daran denken, die Wohnungsübergabe einzuplanen, die Kaution-Rückzahlung vorzubereiten und die Wohnungsgeberbescheinigung auszustellen. In der Praxis bleibt eines davon liegen, fast immer.

Das Master-Sub-Workflow-Konzept

Der Master-Workflow Vermietung modelliert das Mietverhältnis als endlichen Automaten in XState v5. Die Top-Level-Zustände sind bewusst grob: vertragsabschluss, laufende_vermietung, gekuendigt, mietvertrag_abgeschlossen. Diese vier Zustände decken den Lebenszyklus jedes Wohnraum-Mietverhältnisses ab — vom unterzeichneten Mietvertrag, der noch nicht begonnen hat, über den laufenden Betrieb, die Kündigungsphase mit eingeplantem Auszug, bis zum endgültigen Abschluss nach Kaution-Rückzahlung. Übergänge zwischen diesen Zuständen sind durch Guards abgesichert, die nicht der Sachbearbeiter, sondern die Engine prüft. Ein Wechsel von laufende_vermietung nach mietvertrag_abgeschlossen ohne den Zwischenzustand gekuendigt ist im Automaten gar nicht definiert — die Engine weist den Übergang ab, unabhängig davon, was die Oberfläche anzeigt.

An diesem Master hängen Sub-Workflows. Jeder Sub-Workflow ist selbst eine eigene Zustandsmaschine mit eigenem Lifecycle, eigenen Guards und eigenem Audit-Trail. Eine Mieterhöhung nach § 558 BGB ist ein Sub-Workflow mit den Phasen Begründung erstellt, Mietspiegel-Beleg erfasst, Erhöhungsverlangen versendet, Zustimmungsfrist läuft, Zustimmung erfolgt oder Klage eingereicht, Umsetzung. Eine Kündigung nach § 573c BGB ist ein Sub-Workflow mit Sub-States für Härtefall nach § 574 BGB, Widerspruch nach § 574b BGB und Räumungsklage, falls der Auszug nicht erfolgt. Eine Wohnungsübergabe ist ein Sub-Workflow, der sowohl beim Einzug als auch beim Auszug verwendet wird.

Die Verknüpfung zwischen Master und Sub läuft über Lifecycle-Events. Sobald ein Sub-Workflow gestartet wird, sendet die Engine ein child_started:<typ>-Event an den Master. Sobald der Sub erfolgreich abgeschlossen ist, folgt child_completed:<typ>. Bei Abbruch — Mieterhöhung zurückgezogen, Kündigung widerrufen — feuert child_cancelled:<typ>. Der Master reagiert auf diese Events deklarativ: Eine Wohnungsübergabe zum Mietbeginn schließt den Vertragsabschluss ab und überführt den Master in laufende_vermietung. Eine erfolgreich abgeschlossene Kaution-Rückzahlung im Zustand gekuendigt überführt den Master in mietvertrag_abgeschlossen. Diese Übergänge sind keine externen Trigger, sondern Teil der State-Maschine.

XState v5 ist hier der bewusste Standard. Statt einer Eigenentwicklung nutzt ImmoGenio eine Engine, die in TypeScript spezifiziert ist, in Diagrammen visualisiert werden kann und gegen alle möglichen Eingaben automatisch getestet werden kann. Side-Effects — E-Mails, Statusspiegel in operative Tabellen, PDF-Erzeugung — laufen ausschließlich in der Transition-Transaktion. Entweder geht der Übergang vollständig durch, oder gar nicht. Halb gelaufene Workflow-Übergänge gibt es nicht.

Der Sub-Workflow-Katalog: 22 Maschinen für den Verwalter-Alltag

Welle 1 deckt die rechtsstarken Standardprozesse ab, an denen die meisten Klagen hängen.

Welle 2 deckt den breiteren Mieter-Lifecycle ab — die Vorgänge, die im Verwaltungsalltag häufig auftreten und in der bisherigen Software meist nur als Notiz geführt wurden.

Standalone-Workflows sind nicht direkt an den Master Vermietung gebunden, sondern an andere Master oder an Objekte.

Die eigentuemerversammlung ist selbst ein Master-Workflow auf WEG-Seite, an dem Wirtschaftsplan-Genehmigung und Beschluss-Sub-Workflows hängen. Damit hat ImmoGenio neben dem Master Vermietung einen zweiten Master für die WEG-Welt — dieselbe Mechanik, andere Domäne.

Praxis-Beispiel: Mieterwechsel mit Kaution-Einbehalten

Zurück zur Wohnung in der Hauptstraße. Die Mieterin reicht ihre Kündigung am 28. Februar 2026 ein, eingehalten in qualifizierter elektronischer Signatur, Mietdauer 8,87 Jahre, Frist neun Monate nach § 573c Abs. 1 BGB. Der Sub-Workflow kuendigung startet im Master, GenioFlow sendet child_started:kuendigung und überführt den Master beim erfolgreichen Status-Wechsel in den Top-Level-Zustand gekuendigt. Das Mietende ist der 30. November 2026.

Mit dem Übergang in gekuendigt reagiert der Master deklarativ: Er startet automatisch den Sub-Workflow wohnungsuebergabe mit Variante auszug und plant den Übergabetermin auf den Tag des Mietendes. Der Sachbearbeiter sieht in der Mietakte sofort die neue Karte „Wohnungsübergabe Auszug — geplant für 30.11.2026”. Er muss diesen Folgevorgang nicht anlegen, er ist da. Er kann den Termin mit dem Mieter abstimmen, das Protokoll vorbereiten und am Stichtag die Übergabe digital signieren.

Bei der Übergabe stellt das Übergabeprotokoll drei Mängel fest: Lackschäden an der Wohnungstür, ein nicht funktionierender Fenstergriff im Wohnzimmer, eine fehlende Backofen-Glasscheibe. Der Sub-Workflow wohnungsuebergabe schließt mit child_completed:wohnungsuebergabe ab und übergibt die Mängelliste strukturiert an den Master. Der Master startet daraufhin den Sub-Workflow kaution_rueckzahlung. Dieser läuft in eigenen States: Mängelbewertung, Einbehalts-Berechnung, Abrechnung der einbehaltenen Beträge mit dem ehemaligen Mieter, Auszahlung des Restes. Zinsen werden tagesgenau nach § 551 BGB berechnet, die Abrechnungsfrist ist auf sechs Monate nach Mietende terminiert.

Nach drei Monaten sind zwei der drei Mängel beseitigt, die Backofen-Scheibe ist mit 180 Euro vom Einbehaltsbetrag verrechnet. Die Restzahlung der Kaution geht raus, der Sub-Workflow schließt mit child_completed:kaution_rueckzahlung. Der Master reagiert: Übergang von gekuendigt in mietvertrag_abgeschlossen. Aus diesem Zustand führen keine Aktionen mehr heraus — das Mietverhältnis ist endgültig geschlossen. Vier Sub-Workflows, ein Master-Lifecycle, eine durchgehende Zeitleiste in der Akte.

Sub-Workflow-Lifecycle-Events im Detail

Lifecycle-Events sind das Bindeglied zwischen Master und Sub. Sie folgen einem strikten Schema: child_started:<typ>, child_completed:<typ>, child_cancelled:<typ>. Der Typ ist der Maschinenname des Sub-Workflows. Side-Effects, die durch das Event ausgelöst werden — automatisches Anlegen eines Folgevorgangs, Update des Master-Status, Versand einer Benachrichtigung — laufen ausschließlich in der Transition-Transaktion mit dem auslösenden Übergang. Wenn das Anlegen des Folge-Sub-Workflows fehlschlägt, wird die Transition zurückgerollt. Halb gestartete Folgevorgänge entstehen nicht.

Bei child_started notifiziert der Sub den Master über den Start. Der Master kann darauf reagieren, etwa indem er konkurrierende Aktionen sperrt. Während eine Mieterhöhung läuft, sperrt der Master eine weitere Mieterhöhung, weil § 558 Abs. 1 BGB die Jahresfrist einhält. Während eine Kündigung läuft, sperrt der Master eine zweite Kündigung — eine Kündigung über eine Kündigung kennt das Mietrecht nicht.

Bei child_completed triggert der Master den nächsten Phasen-Step. Eine erfolgreich abgeschlossene Wohnungsübergabe in der Einzugs-Variante schließt den vertragsabschluss-Sub-Workflow ab und führt den Master in laufende_vermietung. Eine erfolgreich abgeschlossene Kaution-Rückzahlung schließt den Master in mietvertrag_abgeschlossen.

Bei child_cancelled fällt der Master in den Parent-State zurück. Eine widerrufene Kündigung führt den Master von gekuendigt zurück in laufende_vermietung. Das Backup-Feld der Kündigung, das den Vorzustand des Mietvertrags speichert, sorgt dafür, dass der Rollback datengetreu ist. Halb-zurückgenommene Kündigungen mit Status aktiv, aber stehengebliebenem Auszugstermin gibt es nicht.

Compliance-Anker pro Sub-Workflow

Jeder Sub-Workflow trägt seine rechtliche Klammer im Code. Die Kündigung referenziert § 573c BGB für die Frist und § 568 BGB für die Schriftform. Die Mieterhöhung referenziert § 558 BGB für die Kappungsgrenze, § 558a BGB für die Begründungspflicht und § 558b BGB für die Zustimmungsfrist. Staffelmieten laufen nach § 557a BGB mit Mindestlaufzeit von einem Jahr, Indexmieten nach § 557b BGB mit Zwölf-Monats-Sperrfrist und Bezug auf den Verbraucherpreisindex.

Die Kaution-Rückzahlung folgt § 551 BGB: Höchstgrenze von drei Nettokaltmieten, getrennte Anlage mit Verzinsung, Abrechnungsfrist von sechs Monaten nach Mietende mit Einbehalts-Möglichkeit für offene Forderungen. Untervermietung läuft nach § 540 BGB und § 553 BGB, mit dem berechtigten Interesse des Mieters als Voraussetzung für die Zustimmungspflicht. Modernisierung läuft nach § 555c BGB für die Ankündigung, § 555d BGB für die Duldung und § 559 BGB für die Mieterhöhung um maximal acht Prozent der aufgewendeten Kosten.

Auf WEG-Seite verankert der Wirtschaftsplan-Genehmigungs-Workflow § 28 WEG, der Beschluss-Workflow § 23 WEG mit der Anfechtungsfrist von einem Monat nach § 46 WEG. Über allem steht die Aufbewahrungspflicht — § 257 HGB für die handelsrechtlichen Belege und § 147 AO für die steuerrechtlichen Pflichten. Workflow-Logs werden nicht gelöscht, sondern revisionssicher aufbewahrt, append-only, ohne UPDATE-Berechtigung für Anwendungskonten.

Grenzen der ersten Version

22 produktive Workflows decken den Großteil des Verwalter-Alltags ab, aber nicht alles. Hausordnungs-Verstöße ohne unmittelbaren Mahnungs- oder Kündigungsbezug werden derzeit über anfrage_general und aufgabe_status abgewickelt. Ein eigener Hausordnungs-Workflow mit Eskalationsstufen ist geplant. Schimmel-Fälle laufen heute über die Kombination schaden plus mietminderung, ohne eigenen Schimmel-Workflow mit Gutachten-Steuerung und KfW-Schnittstelle für die Sanierung — dieser Workflow ist für die nächste Welle vorgesehen.

Es gibt keinen grafischen Workflow-Editor für Endkunden. Die State-Maschinen werden codegestützt entwickelt und durch das Produkt-Team gepflegt. Verwalter können Workflow-Varianten nicht selbst klicken — die rechtliche Sorgfalt verlangt, dass Frist-Logik, Guards und Audit-Trail durch das Produkt-Team verantwortet werden, nicht durch Konfigurations-Klicks im Backoffice. Ebenso gibt es kein Multi-Tenant-Customizing der Maschinen: Alle Mandanten nutzen dieselben State-Maschinen, weil das BGB für alle dasselbe gilt.

FAQ

Wieso XState v5 und nicht eine eigene Engine?

Zustandsmaschinen sind ein gut erforschtes Konzept der Informatik mit formaler Semantik. Eine bewährte Bibliothek liefert Tooling — Visualisierung, Testbarkeit, Type-Safety — ohne Wartungslast. Eine Eigenentwicklung müsste denselben Funktionsumfang nachbauen und würde an genau den Stellen brüchig, an denen die Bibliothek schon Edge-Cases gelöst hat. XState v5 ist in TypeScript-Projekten zudem De-facto-Standard.

Was passiert bei einem fehlerhaften Sub-Workflow?

Side-Effects laufen ausschließlich in der Transition-Transaktion. Wenn ein Übergang scheitert — Validierungsfehler, Guard nicht erfüllt, Datenbank-Konflikt — wird die gesamte Transaktion zurückgerollt. Der Sub-Workflow bleibt im Vorzustand, der Master erhält kein Event, und der Audit-Trail enthält den Versuch als fehlgeschlagene Transition, nicht als halb-erfolgreichen Schritt.

Kann der Verwalter einen Sub-Workflow manuell starten?

Ja, sofern der Master im erlaubten Zustand ist. Eine Modernisierung kann der Verwalter im Zustand laufende_vermietung manuell anlegen, eine Kaution-Rückzahlung nicht — sie wird automatisch durch den Übergang in gekuendigt und den Abschluss der Auszugs-Übergabe getriggert. Welche Sub-Workflows aus welchem Master-Zustand erlaubt sind, ist Teil der State-Maschine, nicht der UI.

Werden alle 22 Workflows für jeden Tenant aktiviert?

Ja. Die Multi-Tenant-Architektur trennt Daten, nicht Workflow-Definitionen. Mandant A nutzt dieselben State-Maschinen wie Mandant B, weil § 573c BGB für beide gilt. Welche Workflows in einem Mandanten aktiv genutzt werden, hängt vom Bestand ab: Eine reine Mietverwaltung ohne WEG sieht die WEG-Master-Workflows nicht in der Navigation, weil keine WEG-Objekte gepflegt sind.

Wie wird die Konsistenz zwischen Master und Sub-Workflows gewahrt?

Über drei Mechanismen. Erstens laufen Side-Effects in der Transition-Transaktion, Halbzustände entstehen nicht. Zweitens verhindert ein transaktionaler Advisory Lock pro Workflow-ID parallele Übergänge: Zwei gleichzeitige Aktionen am selben Master werden serialisiert. Drittens ist der Sync-Trigger der Engine an die operativen Tabellen gekoppelt — Status-Felder in mahnungen, mieterhoehungen, kuendigungen werden ausschließlich durch die Engine geschrieben, nicht durch Anwendungs-Code.

Was passiert mit alten Mietverhältnissen ohne Workflow-Anbindung?

Eine Backfill-Migration hat alle bestehenden Mietverhältnisse beim Rollout in die Workflow-Tabellen übernommen. Der Master-Zustand wurde aus dem operativen Status abgeleitet: Aktive Mietverträge starten in laufende_vermietung, gekündigte mit anstehendem Auszug in gekuendigt, beendete mit erfolgter Kaution-Rückzahlung in mietvertrag_abgeschlossen. Historische Vorgänge — Mahnungen, Mieterhöhungen, Kündigungen — wurden als abgeschlossene Sub-Workflows nachgetragen. Damit ist auch das Mietverhältnis aus der Hauptstraße seit 2018 lückenlos in der Engine abgebildet.

Verwandte Beiträge

Wer den Überblick über GenioFlow als Engine sucht, findet die Einführung im Beitrag GenioFlow — Die Evolution der Immobilienverwaltung. Der Sub-Workflow kuendigung mit der Live-Frist-Berechnung nach § 573c BGB und dem atomaren Status-Wechsel ist detailliert in Kündigungs-Workflow nach § 573c BGB beschrieben. Die Mechanik der Mieterhöhung mit Kappungsgrenze und Mietspiegel-Bezug steht in Mieterhöhung nach § 558 BGB. Den Sub-Workflow mahnwesen mit den drei Stufen und Verzugszinsen nach § 288 BGB beschreibt Dreistufiges Mahnwesen mit Verzugszinsen.

Wo wir stehen

Der Master-Workflow Vermietung ist mit 22 Sub-Workflows produktiv. Lifecycle-Events child_started, child_completed und child_cancelled verknüpfen Master und Sub atomar, Side-Effects laufen in der Transition-Transaktion, parallele Übergänge sind durch Advisory Locks serialisiert. Die Backfill-Migration hat bestehende Mietverhältnisse rückwirkend an die Engine angeschlossen, neue Mietverhältnisse starten ab Vertragsabschluss als Master-Workflow. Verwaltungen, die mit ImmoGenio arbeiten, sehen in der Mietakte eine durchgehende Zeitleiste pro Mietverhältnis — keine Sammlung von Einzelvorgängen, sondern einen Lifecycle mit revisionssicherem Audit-Trail.

Kontakt

Sie führen Mietverhältnisse heute mit verstreuten Vorgangs-Ordnern und möchten den Lifecycle auf eine zusammenhängende Engine umstellen. Schreiben Sie an kontakt@immogenio.de — wir zeigen Ihnen den Master-Workflow Vermietung mit den 22 Sub-Workflows an einem Mietverhältnis aus Ihrem eigenen Bestand.