Der vollständige Zustandsraum
Der Mieterhöhungs-Sub-Workflow modelliert acht Zustände — fünf Vor-Versand-States für die Guard-Prüfung, drei Post-Versand-States für die Reaktion. Migration M238 verankert die Schema-Struktur sowie den F+B-Anbindungspunkt. Die zentralen Guards sind: F+B-Mietspiegel grün für kappungsgrenze_pruefen, Kappungsgrenze eingehalten für sperrfrist_pruefen, Sperrfrist abgelaufen für versandbereit_setzen:
Die drei Validierungs-States (mietspiegel_validierung, kappungsgrenze_geprueft, sperrfrist_geprueft) sind als Kette modelliert — jeder darf nur weitergehen, wenn der vorhergehende Guard grün ist. Bei rotem Guard fällt der Workflow zurück auf entwurf und der Verwalter passt die geplante Miete an. Das Anpassen ist nicht versteckt — die Engine zeigt aktiv, welcher Wert (z. B. „max. 9,775 €/m² nach Kappungsgrenze”) akzeptabel wäre.
Beispiel: Frankfurter Wohnung, Erhöhung 8,50 € → 9,40 €/m²
Die 75-m²-Wohnung in der Frankfurter Innenstadt wird seit Mai 2021 vermietet, aktuelle Nettokaltmiete 8,50 €/m² (637,50 € im Monat). Heute ist Mai 2026 — die Sperrfrist von 12 Monaten ist seit der letzten Anpassung erfüllt. Frankfurt ist Mietkappungs-Gemeinde, also gilt 15 % als Kappungsgrenze.
Drei Wochen vom Entwurf bis zur Aktivierung — und die juristischen Schwellen sind alle technisch geprüft, nicht händisch.
Technisch erzwungene Compliance
Der häufigste Fehler in der Praxis: Eine Mieterhöhung wird ohne ausreichende Mietspiegel-Basis versendet, der Mieter widerspricht, der Verwalter stellt erst spät fest, dass die Begründung nicht trägt — die Zustimmungsklage scheitert vor Gericht.
ImmoGenio macht das technisch unmöglich. Drei Guards stehen vor dem Versand, und jeder muss explizit grün sein. Der Verwalter sieht in Echtzeit, ob die geplante Miete im F+B-Korridor liegt — und falls nicht, welche Miete maximal zulässig wäre. Versucht er trotzdem zu versenden, blockiert die Engine den Übergang. Es gibt keinen Override-Pfad für die F+B-Validierung — das ist Absicht, weil eine Mieterhöhung ohne Mietspiegel-Bezug juristisch unhaltbar ist.
Die Kappungsgrenze ist gesetzlich verankert (§ 558 Abs. 3 BGB). Eine Erhöhung über die Kappungsgrenze hinaus ist nicht teilwirksam — sie ist insgesamt unwirksam, der Mieter muss gar nicht zustimmen. Der Workflow verhindert diesen Fehler vor dem Versand.
Zustimmungsfrist und Klage-Option
Die 2-Monats-Frist nach § 558b Abs. 2 BGB beginnt mit dem auf den Zugang folgenden Monat. Beispiel: Mieterhöhung geht am 12. März zu — Frist läuft bis 31. Mai. Der Workflow setzt den Timer automatisch und wechselt um Mitternacht des Fristablaufs in „zustimmungsfrist_abgelaufen”.
Danach hat der Verwalter 3 Monate Zeit für die Zustimmungsklage (also bis 31. August). Der Workflow zeigt diese Frist als gelb-warnenden Hinweis im Portal und blockiert den Übergang „klage_einreichen” nach Fristablauf nicht — aber er dokumentiert die Spätüberschreitung im Audit-Trail. Praktisch sinnvoll ist die Klage nur innerhalb der Frist.
Edge-Case: Teilzustimmung des Mieters
In rund 10 % der Fälle stimmt der Mieter nicht der vollen Erhöhung zu, sondern nur einer Teil-Erhöhung. Beispiel: Sie fordern 9,40 €/m², der Mieter bietet 8,90 €/m². Der Workflow erlaubt im Zustand versendet den Übergang nach zustimmung_eingegangen mit einem Teil-Wert. Sie als Verwalter entscheiden dann: Akzeptieren Sie die Teil-Zustimmung (Workflow → abgeschlossen mit 8,90 €), oder erheben Sie Klage auf die Differenz (Workflow → klage_zustimmung mit 0,50 € Streitwert). Beide Pfade sind im Audit-Trail dokumentiert.