diff --git a/docs/saas-umstrukturierungsplan.md b/docs/saas-umstrukturierungsplan.md
index 58bb7be..181f857 100644
--- a/docs/saas-umstrukturierungsplan.md
+++ b/docs/saas-umstrukturierungsplan.md
@@ -305,7 +305,7 @@ Nicht tun:
 | M2 | Technisches Fundament | Abgeschlossen: Migrationen, Bootstrap, Session, CSRF-Helper und Legacy-Schreibseitenschutz stehen |
 | M3 | SaaS-Basis | Abgeschlossen: Tenants, User, Registrierung, Login, Rollen, Mail-Links und zentrale Mandantenauswahl funktionieren |
 | M4 | Datenmigration | Gestartet: Ledger-Tabelle, Legacy-Backfill, Paritätscheck, Ledger-Service und Preview sind umgesetzt |
-| M5 | App-Kern | Gestartet: Gesamtübersicht liest read-only aus dem Ledger |
+| M5 | App-Kern | Weit fortgeschritten: Kernseiten lesen und schreiben tenant-sicher gegen das Ledger; offen sind Hinweise und ein eigener Zahlungs-Screen |
 | M6 | Betriebsflows | Import, Export, Mail und Jahresprozesse sind auditierbar |
 | M7 | Landingpage | Public-Seite und Auth-Seiten sind im gemeinsamen Stil nutzbar; spätere Ausbaustufen folgen |
 | M8 | Härtung | Betrieb, Datenschutz, Monitoring und Isolation sind geprüft |
@@ -508,21 +508,36 @@ Schritte:
 - Dashboard `Meine Kaffeeliste` umsetzen: read-only Ledger-Stand in
   `index.php` erledigt; eigene Web-Striche werden als Kompatibilitätsbrücke
   ins Ledger gespiegelt.
-- Eigene Stricherfassung umsetzen.
-- Zahlungs-/PayPal-Bereich umsetzen.
-- Mitgliederverwaltung tenant- und rollenbasiert umsetzen.
+- Eigene Stricherfassung umsetzen: erledigt über die Selbsteintragung im
+  Dashboard (`index.php`).
+- Zahlungs-/PayPal-Bereich umsetzen: PayPal-Anzeige und -Links sind über
+  `tenant_settings` im Dashboard umgesetzt, erledigt als Teil von
+  `index.php`. Ein eigener `/app/einzahlungen`-Screen wie ursprünglich in der
+  Zielarchitektur skizziert existiert nicht separat; die Funktion ist bewusst
+  im Dashboard gebündelt statt als eigene Route.
+- Mitgliederverwaltung tenant- und rollenbasiert umsetzen: erledigt in
+  `mitarbeiterverwalten.php`, inklusive Spiegelung nach `participants` und
+  Behebung einer gespeicherten XSS-Lücke bei Name/E-Mail.
 - Gesamtübersicht umsetzen: erster read-only Stand in `kaffeeliste.php`
   erledigt.
 - Teilnehmerauswertung umsetzen: read-only Stand in `teilnehmerauswertung.php`
   erledigt.
-- Letzte Einträge und Korrekturen als Storno statt Delete umsetzen.
-- Hinweise als tenant-spezifische Notices umsetzen.
+- Letzte Einträge und Korrekturen als Storno statt Delete umsetzen: erledigt
+  in `letzteneintraege.php` über `ledger_void_entry_by_legacy_id()`; Legacy-
+  Zeilen werden weiterhin gelöscht, der gespiegelte Ledger-Eintrag bleibt für
+  die Revision erhalten.
+- Sammelerfassung (`stricheintragen.php`, `einzahlung.php`) tenant-sicher
+  absichern und ans Ledger anbinden: erledigt. Beide Seiten hatten zuvor
+  keine Zugriffskontrolle außer CSRF; das ist behoben.
+- Hinweise als tenant-spezifische Notices umsetzen: offen, `hinweise.php`
+  ist noch vollständig Legacy ohne Tenant-Bezug.
 
 Ergebnis:
 
-- Ein Kunde kann seine Kaffeeliste operativ nutzen.
+- Ein Kunde kann seine Kaffeeliste operativ nutzen, inklusive
+  Mitgliederpflege und Korrekturen.
 - App sieht weiterhin nach bestehender Kaffeeliste aus.
-- Erster M5-Stand ist in `docs/m5-app-kern.md` dokumentiert.
+- M5-Stand ist in `docs/m5-app-kern.md` dokumentiert.
 
 Abhängigkeiten: