Immohai Reporting-Spezifikation

Status: verbindlich
Spezifikationsversion: 1.1.0
Modellbezug: 0.6.2
Implementierungsbezug: frontend-mvp-0.2.5
Stand: 2026-07-05

1. Zweck

Reporting erklärt vorhandene Analyseergebnisse. Es erzeugt keine eigene Berechnungslogik.

Ein Report beantwortet:

Welche Eingaben und Annahmen wurden verwendet?
Welche Werte sind manuell, geschätzt, importiert oder Default?
Welche Felder sind fixed, scenario_adjustable oder sensitivity_only?
Welche Presets oder Sliderwerte wurden für Best und Stress verwendet?
Wie sehen Best, Base und Stress aus?
Wie hoch sind Finanzierung, Cashflow und Liquiditätsbedarf?
Wie schneidet die Immobilie nach modelliertem Exit gegen ETF ab?
Welche Daten- und Modellrisiken bestehen?
Welche Prüfungen sind noch offen?

2. Fachliche Quellen

Formeln und KPIs:      docs/calculations/model-specification.md
Feldverträge:          docs/specification/data-quality-and-validation/data-model.md
Schnittstellen:        docs/specification/model-and-calculations/calculation-interfaces.md
Rating:                docs/specification/model-and-calculations/kpi-assessments.md
Datenqualität:         docs/specification/data-quality-and-validation/data-quality-assessment.md
Mietschätzung:         docs/specification/product-domains-and-workflows/rent-analysis.md

Reports dürfen keine abweichenden Definitionen einführen.

3. Zulässige Reportquellen

Reportvorschau:
  unveränderbarer aktueller AnalysisResult-Snapshot

Gespeicherter Objektbericht:
  PropertyRecord-Snapshot

Objektvergleich:
  ausschließlich PropertyRecord-Snapshots

Das aktuelle Formular ist keine Reportquelle, solange es nicht bewusst neu berechnet wurde.

4. Grundsatz

Berechnungsengine bewertet.
ReportDataBuilder strukturiert vorhandene Werte.
Report rendert und erklärt.

Reports dürfen nicht:

Formeln neu implementieren
KPI-Schwellen verändern
Plausibilitätschecks erzeugen
ScenarioRatings neu ableiten
InvestmentRating neu ableiten
alte PropertyRecords still neu berechnen
unberechnete Formularwerte mit einem älteren Ergebnis mischen
Kaufempfehlungen aussprechen

5. ReportData

report_meta
property_summary
input_summary
scenario_summary
financing_summary
cashflow_summary
wealth_summary
rent_estimate_summary
rating_summary
data_quality_summary
assumption_origins
scenario_policies
scenario_controls
warnings
open_checks
decision_summary_text
model_limits

Der Begriff recommendation_text wird nicht verwendet.

6. Report-Metadaten

report_id
report_type
created_at
analysis_result_id
object_id optional
model_version
calculation_engine_version
property_input_schema_version
analysis_result_schema_version
property_record_schema_version optional
default_assumptions_version
scenario_presets_version
object_types_version
market_rent_schema_version optional
rent_estimate_schema_version optional
analysis_data_quality_method_version
rent_reference_dataset_id optional
rent_reference_dataset_version optional
rent_reference_dataset_scope_id optional

Legacy-Lesealiase:

property_record_id -> object_id
scenario_preset_version -> scenario_presets_version
object_type_config_version -> object_types_version
schema_version -> property_input_schema_version
source_dataset_id -> rent_reference_dataset_id
source_dataset_version -> rent_reference_dataset_version

Neue Reports schreiben ausschließlich kanonische Feldnamen.

7. Zentrale Kennzahlen

Mindestens anzeigen:

Kaufpreis
Erwerbsnebenkosten
Investitionsbedarf nach Kauf
Gesamtinvestition
Eingesetztes Eigenkapital
Darlehen
über den Kaufpreis hinaus finanzierter Betrag
Anfangs-LTV
LTV Ende Jahr 1
Jahresbruttokaltmiete Jahr 1
gross_yield_y1
NOI-Rendite Jahr 1
Kapitaldienst Jahr 1
DSCR Jahr 1
Cashflow Jahr 1
Minimum Cashflow
Kumulativer Zuschussbedarf
Dauerhaft selbsttragend ab
Immobilienvermögen vor Exit
Verkaufskosten
Terminales Immobilienvermögen nach Exit
ETF-Wert Ende
Net vs ETF vor Exit
Net vs ETF nach Exit
Dauerhafter ETF Break-even

Jahresbruttokaltmiete Jahr 1 bezeichnet gross_rent_y1.

Net vs ETF vor Exit bezeichnet net_vs_etf_before_exit_end. Die Bezeichnung „vor Exitkosten“ wird nicht verwendet.

8. Szenariovergleich

Best, Base und Stress zeigen dieselben KPI-Gruppen.

Base basiert auf aufgelösten Annahmen ohne Szenario-Delta.
Best und Stress verändern nur scenario_adjustable-Felder.
fixed-Felder bleiben unverändert.
ETF-Rendite bleibt zwischen Szenarien konstant.

Jeder Case zeigt:

ScenarioAssessment
ScenarioRating
Begründung des Case Ratings

Nur AnalysisResult zeigt das vollständige Investment Rating. Das Case Rating wird als separate Vergleichsampel gekennzeichnet und nicht als Kaufentscheidung dargestellt.

9. Szenarioeinstellungen

Der Report zeigt:

control_mode = preset oder custom_sliders
verwendete Preset-Version
oder gespeicherte Sliderwerte
wirksame Best-/Stress-Annahmen

Sliderwerte werden aus dem gebundenen PropertyInput gelesen, nicht aus dem aktuellen UI-Zustand.

10. Finanzierung

Gesamtinvestition
Eigenkapitalbeitrag
Darlehen
über den Kaufpreis hinaus finanzierter Betrag
Initialzins und interest_basis
Anfangstilgung
Zinsreset nach Jahr
Reset-Zins und interest_reset_basis
Anfangs-LTV
Restschuldverlauf
Kapitaldienstverlauf
DSCR
Cash-Reserve nach Kauf als Informationsfeld

Pflichthinweis:

Annuitätsnahe Modellnäherung, kein verbindlicher Bank-Tilgungsplan.

Ein Darlehen ohne Kapitaldienst wird als harter kritischer Befund ausgewiesen.

11. Cashflow

NOI:
  Nettokaltmiete
  - Leerstand
  - nicht umlagefähige Betriebskosten

Cashflow vor Steuer:
  NOI
  - Reservebeitrag
  - wiederkehrender CAPEX
  - Sonder-CAPEX
  - Kapitaldienst

Der Report zeigt die gewählte CAPEX-Methode. Hausgeld darf nicht zusätzlich abgezogen werden, wenn relevante Komponenten separat modelliert sind.

Bei equity_contributed = 0 werden keine scheinbaren Prozentwerte gegen einen fiktiven Eigenkapitalnenner dargestellt. Der Report erklärt stattdessen die absoluten Null-Eigenkapitalregeln.

12. Kostenabgrenzung

Reservebeitrag:
  tatsächliche laufende Zuführung

Wiederkehrender CAPEX:
  zusätzliche laufende Investitionen

Sonder-CAPEX:
  nominale Einzelmaßnahme im Ereignisjahr

Doppelzählungsrisiken werden als offene Prüfung ausgewiesen.

13. ETF und Exit

Der Report unterscheidet:

net_vs_etf_before_exit_end
terminal_net_vs_etf_after_exit

Die Hauptaussage verwendet den terminalen Vergleich nach modellierten Verkaufskosten und Restschuld.

Zusätzlich erklären:

ETF-Startwert = eingesetztes Eigenkapital
gleiche negative Nachschüsse auf beiden Seiten
jährliche Zahlungen am Jahresende
positive Cashflows im Side Account
Verkaufskosten im Endvergleich
Spekulationssteuer nicht im MVP

ETF-Break-even-Jahre basieren auf einem hypothetischen Verkauf zum jeweiligen Jahresende.

14. Investment Rating

Anzeigen:

Investment Rating der Gesamtanalyse
Begründung
Profitability
Liquidity
Financing
Robustness aus Stress
Data Quality
harte kritische Befunde

Bei UNRATED:

Keine belastbare Ampel wegen fehlender oder unzureichender Datenqualität.
Fehlende oder unsichere Daten zuerst prüfen.

15. Datenqualität und Mietschätzung

Bei Verwendung eines RentEstimate mindestens anzeigen:

verwendete Nettokaltmiete
rent_basis
estimate_type
P25 / Median / P75, soweit für den Schätztyp vorhanden
Samplegröße, soweit vorhanden
rent_reference_dataset_id, soweit vorhanden
rent_reference_dataset_version, soweit vorhanden
rent_reference_dataset_scope_id, soweit vorhanden
data_from und data_until
matched_location_level
confidence
confidence_level
confidence_method_version
Fallback
Warnungen

Nur veröffentlichte Datasets dürfen als aktive automatische Quelle dargestellt werden. Ein fehlender Datenqualitätsscore wird nicht als 100 dargestellt.

16. Decision Summary

decision_summary_text ist eine modellbasierte Zusammenfassung, keine Kaufempfehlung.

Zulässig:

Das Modell zeigt ...
Die Einschätzung hängt stark von ... ab.
Vor einer Entscheidung sollte ... geprüft werden.

Nicht zulässig:

Kaufen
Nicht kaufen
klare Anlageempfehlung
garantierte Rendite

17. Gespeicherte Objekte

Reports aus Meine Objekte verwenden den gespeicherten Snapshot. Bei älterer Modell-, Engine-, Schema- oder Methodenversion wird dies sichtbar angezeigt. Kein stilles Überschreiben und keine automatische Neuberechnung.

18. Legacy-Kompatibilität

Zulässige Lesealiase stehen in docs/specification/data-quality-and-validation/data-model.md. Reports schreiben keine Legacy-Felder neu und verändern den Snapshot nicht.

19. Modellgrenzen

Jeder Report enthält mindestens:

keine Steuerberatung
keine Rechtsberatung
keine Finanzierungszusage
kein Verkehrswertgutachten
keine technische Gebäudeprüfung
keine Garantie erzielbarer Mieten
keine Garantie der ETF-Rendite
Spekulationssteuer nicht im MVP

20. Export

Aktueller lokaler MVP:

Browser-Druck
Print-to-PDF
CSV-Export gespeicherter Objekte
Reportvorschau für One Pager, Investment Report und Bank Report

Später:

serverseitige PDF-Erzeugung
XLSX-Export
Reportversionierung

21. Tests

Reportwerte stimmen exakt mit AnalysisResult oder PropertyRecord überein.
Unberechnete Formularwerte verändern einen Report nicht.
Terminaler ETF-Vergleich enthält Verkaufskosten und Restschuld.
DSCR ohne Darlehen wird als nicht anwendbar dargestellt.
Best, Base und Stress zeigen gespeicherte Case Ratings.
Nur AnalysisResult zeigt das Investment Rating.
UNRATED wird nicht als RED oder YELLOW interpretiert.
Fehlende Datenqualität wird nicht als 100 dargestellt.
Sliderwerte stammen aus dem PropertyInput-Snapshot.
ETF-Break-even wird als hypothetischer Exit erklärt.
CAPEX-Methode und Kostenabgrenzung werden angezeigt.
RentEstimateReference wird mit kanonischen Dataset-Namen ausgewertet.
Ältere PropertyRecords werden nicht still neu berechnet.
Decision Summary enthält keine Kaufempfehlung.