ADR 0004: Future Batch Reporting and Data Quality¶
Status: Accepted
Datum: 2026-07-01
Kontext¶
Der aktuelle Reports-Tab im Frontend-MVP erzeugt Report-Vorschauen für genau eine Einzelanalyse.
Diese Reports sind bewusst nicht als Batch-Reports oder Ranking-Berichte gedacht. Batch-Reports werden später gemeinsam mit dem Batchlauf, der Import-/Normalisierungslogik und der Datenqualitätsbewertung konzipiert.
Während der Diskussion zum Investment One Pager wurde festgelegt:
Der aktuelle One Pager soll Eingaben, Annahmen und deren Herkunft zeigen.
Eine gewichtete Sicherheits- oder Datenqualitätsbewertung wird im Einzelanalyse-Report noch nicht berechnet.
Entscheidung¶
Die Reportlogik wird getrennt betrachtet:
| Ebene | Zweck | Status |
|---|---|---|
| Einzelanalyse-Reports | Darstellung einer manuell geprüften Objektanalyse | Frontend-MVP |
| Batch-Reports | Vergleich, Filterung und Ranking vieler Objekte | spätere Ausbaustufe |
| Data Quality Score | Bewertung der Belastbarkeit importierter oder geschätzter Daten | spätere Ausbaustufe |
Für den aktuellen MVP gilt:
- Reports sind Einzelanalyse-Reports.
- Reports berechnen keine Werte neu.
- Reports zeigen vorhandene Eingaben, KPIs, Szenarien, Annahmen und Plausibilitätsmeldungen.
- Reports zeigen Herkunftsinformationen, aber keinen gewichteten Data Quality Score.
Batch-Reporting Grundsatz¶
Batch-Reporting wird erst sinnvoll, wenn es eine klare Pipeline gibt:
RawListing -> Normalisierung -> PropertyInput -> Single-Property-Engine -> PropertyRecord -> CompareObjects / BatchReport
Rohdaten aus Inseraten, Importen oder späteren Scraping-Quellen dürfen nicht direkt berechnet werden.
Jedes Objekt braucht zuerst normalisierte Eingaben mit Herkunft, Plausibilität und Datenqualität.
Kritische Pflichtdaten im Batchlauf¶
Einige Felder sind so grundlegend, dass fehlende oder nicht zuverlässig zugeordnete Werte nicht nur den Score reduzieren, sondern den Analysezustand beeinflussen sollten.
Kritische Pflichtdaten:
| Feld | Bedeutung | Folge bei fehlendem Wert |
|---|---|---|
| Kaufpreis | Basis für Investition, Darlehen, Renditen und ETF-Vergleich | Objekt nicht voll bewertbar |
| Wohnfläche | Basis für €/m²-Kennzahlen und Mietplausibilität | Objekt nicht voll bewertbar |
| Objektart | Grundlage für Annahmen und Benchmarks | Analyse nur eingeschränkt nutzbar |
| Miete oder Mietschätzung | zentraler Treiber für Cashflow und Rendite | Ergebnis stark eingeschränkt |
Daraus folgt:
Fehlende Pflichtdaten sollten später nicht nur als niedrige Qualität bewertet werden.
Sie können den Status incomplete auslösen.
Eigenkapital und Vergleichbarkeit¶
Eigenkapital ist wichtig für die persönliche Analyse, aber nicht primär eine objektbezogene Datenqualität.
Für spätere Batch-Analysen ist deshalb zu unterscheiden:
| Modus | Zweck |
|---|---|
| Persönlicher Modus | nutzt das tatsächlich verfügbare oder gewünschte Eigenkapital des Nutzers |
| Vergleichsmodus | nutzt ein standardisiertes Finanzierungsprofil für alle Objekte |
Eine spätere offene Entscheidung ist, ob Batch-Vergleiche mehrere Finanzierungsvarianten rechnen sollen, zum Beispiel:
Variante A: sehr niedriger Eigenkapitaleinsatz / hohe Finanzierung
Variante B: 80 % LTV / 20 % Eigenkapital
Das erzeugt jedoch mehrere Berechnungen je Objekt und wird nicht im aktuellen Frontend-MVP entschieden.
Zinssatz im Batchlauf¶
Für Batch-Analysen sollten Zinssatz, Tilgung, Zinsreset und Anschlusszins zunächst standardisiert werden.
Grund:
Objekte sind schlecht vergleichbar, wenn jedes Objekt mit anderen Finanzierungskonditionen gerechnet wird.
Spätere Struktur:
| Profil | Zweck |
|---|---|
| Standardfinanzierung | objektübergreifender Vergleich |
| Persönliche Finanzierung | nutzerbezogene Analyse eines konkreten Objekts |
| Stressfinanzierung | Sensitivität gegen höhere Zinsen und Anschlussfinanzierung |
Mieteinnahmen und Datenqualität¶
Mieteinnahmen sind einer der wichtigsten Treiber der Analyse.
Im Batchlauf werden Mieten häufig nicht direkt manuell eingegeben, sondern geschätzt oder aus Datenquellen abgeleitet.
Mögliche Mietquellen:
| Quelle | Beispielhafte Bedeutung |
|---|---|
| Ist-Miete / Mietvertrag | belastbarer objektbezogener Wert |
| Inseratsmiete | aus Angebot übernommen |
| manuelle Nutzereingabe | bewusst gesetzte Annahme |
| Mietdatenbank guter Match | Lage, Fläche und Objektart gut zugeordnet |
| Mietdatenbank grober Match | nur Stadt, PLZ oder Stadtteil grob zugeordnet |
| WG-Schätzung | aus Zimmeranzahl, Grundriss und Zielgruppe abgeleitet |
| Default-Schätzung | allgemeine Modellannahme ohne starken Objektbezug |
Für WG-Objekte sollten später zusätzliche Kriterien berücksichtigt werden:
- Anzahl separat nutzbarer Zimmer.
- Zimmergrößen.
- Durchgangszimmer ja/nein.
- Anzahl Bäder.
- Gemeinschaftsfläche.
- Lage und Zielgruppe.
- Plausibilität der Miete pro m² und pro Zimmer.
CAPEX und Zustand¶
CAPEX ist besonders schwierig, weil im Batchlauf häufig keine vollständigen technischen Unterlagen vorliegen.
Mögliche spätere Qualitätsstufen:
| CAPEX-Grundlage | Interpretation |
|---|---|
| Default nach Objektart | grobe Annahme |
| Baujahr / Objektalter berücksichtigt | bessere Annahme |
| Zustand aus Inseratstext oder Bildern abgeleitet | geschätzte Annahme |
| WEG-Unterlagen, Rücklage, Sanierungsplan oder Gutachten berücksichtigt | belastbarere Objektannahme |
CAPEX bleibt ein entscheidender Risikotreiber und sollte im Batchranking sichtbar bleiben.
Spätere Data-Quality-Logik¶
Ein späterer Data Quality Score soll nicht blind alle Felder gleich behandeln.
Zu unterscheiden sind:
| Kategorie | Beispiele |
|---|---|
| Pflichtdaten | Kaufpreis, Wohnfläche, Objektart |
| Investmenttreiber | Miete, CAPEX, Leerstand, Kosten, Zinsprofil |
| Vergleichsannahmen | ETF-Rendite, Wertentwicklung, Standardfinanzierung |
| Nutzerspezifische Annahmen | Eigenkapital, persönliche Finanzierung, Zielstrategie |
Ein möglicher späterer Report kann getrennt ausweisen:
Overall Data Quality
Critical Assumption Quality
Missing Critical Fields
Rent Estimate Quality
CAPEX Estimate Quality
Diese Werte sind nicht Teil des aktuellen One Pagers.
Batch-Report Zielbild¶
Ein späterer Batch-Report soll andere Fragen beantworten als ein Einzelreport:
- Welche Objekte sind rechnerisch attraktiv?
- Welche Objekte sind trotz gutem Rating unsicher wegen schwacher Datenbasis?
- Welche Objekte scheiden wegen fehlender Pflichtdaten aus?
- Welche Objekte brauchen zuerst Mietprüfung, CAPEX-Prüfung oder Finanzierungsprüfung?
- Welche Objekte sind unter standardisierten Annahmen vergleichbar robust?
Mögliche Batch-Report-Ausgaben:
- Ranking-Tabelle.
- Filter nach Rating und Data Quality.
- Kennzeichnung unvollständiger Objekte.
- Top-Kandidaten mit Warnhinweisen.
- Ausschlussliste mit fehlenden Pflichtdaten.
- Sensitivitätsübersicht für Miete, CAPEX und Zins.
Konsequenzen¶
Vorteile:
- Der aktuelle One Pager bleibt einfach und verständlich.
- Keine unfertige Datenqualitätslogik wird in Einzelreports eingebaut.
- Batch-Reporting kann später sauber mit Import, Normalisierung und Datenmodell entwickelt werden.
- Objektqualität, Annahmenqualität und persönliche Finanzierung werden nicht vermischt.
Nachteile:
- Der aktuelle Einzelreport zeigt noch keinen Gesamtwert zur Datenqualität.
- Batch-Ranking und Data Quality müssen später als eigener fachlicher Block definiert werden.
Nicht entschieden¶
Offen bleiben:
- genaue Gewichtung eines späteren Data Quality Score.
- Umgang mit Objekten ohne Kaufpreis oder Wohnfläche.
- Standard-Finanzierungsprofile für Batchvergleiche.
- ob mehrere Eigenkapital-/LTV-Varianten je Objekt gerechnet werden.
- Logik zur Mietschätzung aus Datenbank, Grundriss oder WG-Eignung.
- CAPEX-Ableitung aus Baujahr, Zustand, Text, Bildern oder Unterlagen.
- konkrete Darstellung des späteren Batch-Reports.