Zum Inhalt springen

Funktionen

Was heute läuft — und was noch nicht

Diese Seite ist nach Reifegrad sortiert, nicht nach Verkaufsargument. Jede Funktion trägt eine Kennzeichnung, und wo es eine Einschränkung gibt, steht sie darunter. Der Maßstab ist nicht die Länge dieser Liste, sondern ob acht reale Arbeitsabläufe einer Hausverwaltung von Anfang bis Ende durchlaufen — bei der letzten vollständigen Messung war es einer von acht. Die Bruchstellen liegen fast nie in der Fachlogik, sondern an den Rändern.

Buchhaltung & Zahlungsverkehr

Der Teil, an dem die Buchhalterin täglich sitzt — und der Teil, in dem am meisten fertig ist. Die meisten Pakete liegen hinter Schaltern, die in einer frischen Installation ausgeschaltet sind.

  • Im Alpha nutzbar
    Sachkonten nach SKR-04-WoWi
    Kontenrahmen für die Wohnungswirtschaft mit Steuerschlüsseln, sauber getrennt nach Mandant. Eine neu angelegte Organisation bekommt ihn beim Anlegen mit.
  • Teilweise gebaut
    Manuelle Buchung und Eingangsrechnungen
    Kostenbelege erfassen, kontieren und buchen — Grundsteuer, Versicherung, Müllabfuhr, Straßenreinigung, Hausmeister, Wartungsverträge. Mit Kreditorenstamm und Eingangsrechnungserfassung.

    Frisch gebaut und noch nicht in einem echten Jahreslauf erprobt. Bis vor kurzem konnten Kosten nur aus Handwerkerrechnungen ins System kommen; erst dieser Weg macht eine vollständige Betriebskostenabrechnung überhaupt möglich.

  • Im Alpha nutzbar
    GoBD-Härtung
    Unveränderliche Buchungen mit Hash-Kette, lückenlose Änderungshistorie, Prüfpfad über alle Belege.

    Hinter Feature-Flags (GOBD_*), standardmäßig aus. Technisch umgesetzt heißt nicht von einem Prüfer testiert — ein Testat gibt es nicht.

  • Im Alpha nutzbar
    DATEV-Export (EXTF / Z3)
    Buchungsstapel und Belegbilder im DATEV-Format, signiert und mit Kettenprüfung — der Export, den der Steuerberater ohne Nachfrage einliest.

    Hinter Feature-Flag DATEV_EXPORT_ENABLED.

  • Im Alpha nutzbar
    Bankimport & Zuordnung
    Kontoumsätze per CSV (comdirect) oder CAMT.053-XML einlesen und den offenen Posten zuordnen.

    Keine Live-Bankanbindung: FinTS, EBICS und PSD2 sind nicht angebunden, Daten kommen als Datei.

  • Im Alpha nutzbar
    SEPA-Mandate und Lastschrift-Lauf
    Mandatsverwaltung mit Gültigkeitsprüfung, Erzeugung und Schema-Prüfung der SEPA-Lastschriftdatei, Rückläufer-Behandlung.

    Hinter Feature-Flags (SEPA_*). Die Datei wird erzeugt und geprüft; eingereicht wird sie von Ihnen im Bankprogramm, eine EBICS-Anbindung gibt es nicht.

  • Teilweise gebaut
    Zahlungsausgang
    Überweisungen an Handwerker und Lieferanten und die Auszahlung einer Restkaution als SEPA-Überweisungsdatei, mit Vorabprüfung und Gegenbuchung.

    Die Datei entsteht; die Einreichung bei der Bank machen Sie selbst. Noch nicht in einem echten Zahllauf erprobt.

  • Im Alpha nutzbar
    Sollstellungs-Generator
    Monatliche Sollstellung aus den Mietverträgen, tagesgenau anteilig, mit Vorschau und Vorabprüfung.

    Hinter Feature-Flag SOLLSTELLUNG_PIPELINE_ENABLED.

  • Im Alpha nutzbar
    Mahnwesen
    Mehrstufiger Mahnlauf auf offenen Posten, mit Verzugszinsen aus dem gepflegten Basiszins, Karenzzeiten, Aussetzung und Mahnhistorie je Vertrag.

    Hinter Feature-Flag MAHN_PIPELINE_ENABLED. Die Mahnschreiben entstehen als PDF-Bündel zum Ausdrucken; ein Ratenzahlungsplan und eine Inkasso-Übergabe als eigener Vorgang fehlen.

  • Geplant, noch nicht gebaut
    Anlagenbuchhaltung
    Anlagenspiegel, Abschreibungen, Zu- und Abgänge über das Geschäftsjahr.

    Weder Code noch Anforderungsdokument. Für einen vollständigen HGB-Jahresabschluss aus einem System heraus fehlt sie.

  • Geplant, noch nicht gebaut
    E-Rechnung nach EN 16931
    XRechnung und ZUGFeRD empfangen, prüfen und ausstellen.

    Nicht gebaut. Die Empfangspflicht besteht seit dem 1.1.2025, die Ausstellungspflicht kommt 2027 und 2028 gestaffelt. Wer das braucht, braucht es zu einem Termin, den wir heute nicht zusagen können.

Mietverwaltung

Vom Mietvertrag über die Betriebskosten bis zur Kaution — der operative Kern, und die sorgfältigste Fachlogik des Produkts.

  • Im Alpha nutzbar
    Stammdaten und Mietverträge
    Wirtschaftseinheiten, Objekte, Verwaltungseinheiten, Parteien und Mietverträge in einem Datenmodell, das die Wohnungswirtschaft abbildet statt sie zu approximieren.
  • Teilweise gebaut
    Betriebskostenabrechnung
    Abrechnung mit Umlageschlüsseln, Leerstandsanteilen, HeizkostenV-Aufteilung, CO2-Stufen nach CO2KostAufG, Datenqualitätsprüfung vor dem Lauf und Freigabe durch einen Menschen.

    Hinter Feature-Flags (BK_*). Für Warmwasser noch nicht einsetzbar: § 8 Abs. 1 HeizkostenV verlangt die Verteilung nach dem erfassten Warmwasserverbrauch, und ein davon getrennter Messwert fehlt im Datenmodell — der Umbau dafür ist in Arbeit. Ein Widerspruchsvorgang und eine versionierte Korrekturabrechnung fehlen ebenfalls.

  • Im Alpha nutzbar
    Fristen mit Geldfolge
    Abrechnungs- und Einwendungsfrist nach § 556 Abs. 3 BGB, Kündigungsfristen, Kautionsfristen und Fristen der Mieterhöhung — mit Feiertagskalender je Bundesland.

    Der Fristablauf nach § 556 Abs. 3 BGB kostet den gesamten Nachforderungsanspruch. Deshalb rechnet das System die Frist aus; ob daraus rechtzeitig eine Abrechnung wird, bleibt Ihre Arbeit.

  • Im Alpha nutzbar
    Mietanpassung
    Vergleichsmiete nach § 558 BGB, Index- und Staffelmiete — mit historisierten Ständen statt überschriebener Werte.

    Hinter Feature-Flags (MIETANPASSUNG_*).

  • Im Alpha nutzbar
    Kautionsverträge und Zinsen
    Kautionskonten, Zinsberechnung, Abrechnung bei Auszug mit eigenem Genehmigungsschritt.
  • Im Alpha nutzbar
    Schadensmeldung bis Arbeitsauftrag
    Meldung aufnehmen, klassifizieren, Auftrag erzeugen, Handwerker per E-Mail beauftragen, Rechnung zurückführen, Kosten in die Umlage übernehmen.

    Hinter Feature-Flags (OPERATIV_*). Der Mieter kann seinen Schaden nicht selbst melden und der Handwerker nicht selbst zurückmelden; beides läuft über Telefon und E-Mail. Eine sachliche Rechnungsfreigabe im Vier-Augen-Prinzip fehlt.

  • Teilweise gebaut
    Ausgehender Schriftverkehr
    Briefe und Bescheide aus dem Vorgang erzeugen, freigeben, per E-Mail versenden oder als Druckbündel ausleiten — mit Zustellnachweis und Archivierung des Versendeten.

    Gebaut und noch jung. Nicht jeder Vorgang hängt schon daran — Mahnschreiben etwa entstehen weiterhin als eigenes PDF-Bündel.

  • Im Alpha nutzbar
    Energieausweis und Wohnflächen
    Energieausweise verwalten, Pflichtangaben nach GEG § 80 prüfen und die Wohnflächenermittlung nach WoFlV führen.

    Hinter Feature-Flags (ENERGIEAUSWEIS_*, GEG80_*), standardmäßig aus.

  • Im Alpha nutzbar
    Operative Reports und Arbeitsaufträge
    Auswertungen über den operativen Bestand und die daraus abgeleiteten Arbeitsaufträge.

    Hinter Feature-Flags (REPORTS_*).

  • Geplant, noch nicht gebaut
    Vermietung und Interessentenverwaltung
    Leerstand als Vorgang führen, Interessenten und Suchprofile verwalten, Selbstauskunft und Unterlagen prüfen, Besichtigungen planen.

    Kein Code. Der Vorgang „Mieter zieht ein" beginnt heute erst beim Mietvertrag — der Weg dorthin liegt außerhalb des Systems.

  • Geplant, noch nicht gebaut
    Genossenschaftsanteile und Mitgliederbuch
    Mitgliedschaft, Anteile, Ein- und Auszahlungen, Dividende, Mitgliederbuch und Generalversammlung.

    Kein Code, kein Anforderungsdokument. Für eine Wohnungsgenossenschaft ist das kein Zusatz, sondern Pflicht — und deshalb der Punkt, an dem wir uns zuerst messen lassen müssen.

  • Geplant, noch nicht gebaut
    Wirtschaftsplan
    Planung der Bewirtschaftungskosten je Wirtschaftseinheit und Abgleich mit dem Ist.

    Nicht gebaut.

Dokumente & KI

Zuerst die Grundlage — belegbare Antworten auf Dokumente und Geschäftsdaten. Was hier steht, ist bewusst weniger, als die Branche gerade verspricht.

  • Im Alpha nutzbar
    Postbox
    E-Mails und PDFs landen im Eingang, werden kategorisiert und dem richtigen Vorgang zugeordnet.

    Eingang heute als abgelegte .eml-Datei oder PDF; ein Postfachabruf über IMAP ist nicht angebunden, und Anhänge werden noch nicht in die Akte übernommen. Es ist ein Ablagesystem, noch kein Bearbeitungssystem.

  • Im Alpha nutzbar
    Chat über Dokumente und Geschäftsdaten
    Fragen in natürlicher Sprache auf den eigenen Bestand — mit Verweis auf die Quelle, aus der die Antwort stammt.

    Im Self-Hosting mit eigenem Schlüssel für ein Sprachmodell; die Einbettungen laufen lokal über Ollama. Angebunden ist heute genau ein Anbieter.

  • Im Alpha nutzbar
    Dokumentenverwaltung
    Ablage, Verschlagwortung und Suche über den Belegbestand, mit optionaler Texterkennung.

    Hinter Feature-Flag DOKUMENTE_PIPELINE_ENABLED, standardmäßig aus.

  • Im Alpha nutzbar
    Mietvertrags-Import aus PDF
    Ein Mietvertrag als PDF wird gelesen und als Entwurf in die Stammdaten übernommen.
  • Im Alpha nutzbar
    Heizkostenbeleg auslesen
    Die Abrechnung des Messdienstleisters wird als PDF eingelesen, der Anbieter erkannt und die Summen gegengeprüft.

Betrieb & Grundlagen

Was darunter liegt, damit der Rest verlässlich ist.

  • Im Alpha nutzbar
    Multi-Mandant mit Postgres-RLS
    Mandantentrennung wird in der Datenbank durchgesetzt, nicht in der Anwendungsschicht. Ein Zugriff über die Mandantengrenze scheitert dort und nicht erst im Programm.
  • Im Alpha nutzbar
    Anmeldung ohne Passwort
    Passkey oder Magic-Link — kein Passwort, das altern kann.
  • Teilweise gebaut
    Erstinbetriebnahme und Benutzerverwaltung
    Organisation anlegen, Kontenrahmen und Geschäftsjahr einrichten, Benutzer einladen, Rollen vergeben.

    Der Weg vom leeren System bis zur ersten Buchung ist erst seit kurzem durchgängig und noch nicht von außen nachgestellt worden. Bis dahin war er unterbrochen — das ist der Grund, warum er hier nicht als fertig steht.

  • Im Alpha nutzbar
    Self-Hosting per Docker Compose
    Repository klonen, Secrets erzeugen, `docker compose up`. Postgres, Ollama und die Anwendung starten zusammen.
  • Teilweise gebaut
    Datenübernahme aus dem Altsystem
    Parteien, Wirtschaftseinheiten, Objekte, Verwaltungseinheiten, Mietverträge und deren Positionen aus Tabellen übernehmen — mit Spaltenzuordnung, Probelauf und Rücknahme.

    Sechs Stammdaten-Bereiche, mehr nicht. Konten, Salden, offene Posten und Buchungshistorien lassen sich nicht übernehmen, und für die verbreiteten Altsysteme gibt es keine fertigen Zuordnungen. Für einen echten Systemwechsel reicht das noch nicht.

  • Im Alpha nutzbar
    Sanktionslisten und GwG-Legitimation
    Abgleich der Vertragspartner gegen Sanktionslisten, Legitimationsprüfung nach Geldwäschegesetz.

    Hinter Feature-Flags (SANCTIONS_*), standardmäßig aus.

  • Geplant, noch nicht gebaut
    Mieter- und Mitgliederportal
    Mieterinnen, Mieter und Mitglieder sehen ihren Vertrag, ihre Zahlungen und ihre Betriebskostenabrechnung selbst und melden Schäden dort.

    Spezifiziert, kein Code. Ohne Portal gibt es auch keinen Erstlevel-Agenten für Mieteranfragen.

  • Geplant, noch nicht gebaut
    SSO über SAML und SCIM
    Anbindung an Microsoft Entra, Okta oder Keycloak für Organisationen mit eigener IT.

    Kommerzielle Erweiterung, nicht Teil der Community Edition. Noch nicht gebaut.

Agenten

Die Richtung des Produkts — und der Teil, bei dem uns am meisten daran liegt, dass niemand ihn für gebaut hält. Keine der folgenden Funktionen existiert. Die Vorstufen stehen weiter oben unter „Dokumente & KI".

  • Geplant, noch nicht gebaut
    Posteingangs-Agent
    Klassifiziert Post, E-Mails und Rechnungen, ordnet sie Objekt, Einheit, Vertrag und Vorgang zu, legt den Vorgang an und schlägt den Bearbeiter vor.

    Konzept beschrieben, kein Anforderungsdokument, kein Code. Gebaut ist die Postbox, die kategorisiert und zuordnet — ein Vorgang entsteht daraus nicht.

  • Geplant, noch nicht gebaut
    Schadensmeldungs-Agent
    Nimmt die Meldung mit Foto entgegen, bestimmt Gewerk und Dringlichkeit, wählt den Rahmenvertragspartner, entwirft den Auftrag, verfolgt Termin und Rückmeldung und prüft die Eingangsrechnung gegen den Auftrag.

    Konzept beschrieben, kein Code. Die zugrundeliegende Kette aus Meldung, Auftrag und Rechnung ist gebaut und wird von Hand bedient.

  • Geplant, noch nicht gebaut
    Betriebskosten-Widerspruchs-Agent
    Zieht die Belege, prüft die Umlagefähigkeit nach BetrKV, rechnet den Verteilerschlüssel nach, vergleicht mit dem Vorjahr und entwirft die Antwort mit Belegverweis.

    Konzept beschrieben, kein Code. Es gibt im System weder einen Widerspruchsvorgang noch eine Korrekturabrechnung, auf die ein solcher Agent aufsetzen könnte.

  • Geplant, noch nicht gebaut
    Erstlevel-Agent für Mieter und Mitglieder
    Beantwortet wiederkehrende Anfragen — Abrechnungsstand, Untervermietung, Fristen, Bescheinigungen — auf Basis des echten Vertrags und eskaliert an den Menschen, sobald es unklar wird.

    Konzept beschrieben, kein Code. Setzt ein Mieterportal voraus, das ebenfalls noch nicht gebaut ist.

  • Geplant, noch nicht gebaut
    Freigabeschwellen und Begründungspflicht
    Je Prozess einstellbar, wie viel ein Agent selbst tun darf; jeder Schritt mit Belegen, Modellversion, Konfidenz und Freigabevermerk im Prüfpfad.

    Nicht gebaut. Der unveränderbare Prüfpfad für Buchungen und Belege steht bereits — die Erweiterung um Agentenhandlungen nicht.

Self-Hosting in fünf Minuten

Vorausgesetzt sind Docker 24 oder neuer mit dem compose-Plugin und eine Unix-artige Shell. Sonst nichts — kein Node, kein Postgres, keine Ollama-Installation auf dem Host.

Der erste Start lädt das Postgres-Image mit pgvector und ein Embedding-Modell herunter. Auf einem kalten Cache dauert das fünf bis zehn Minuten; danach startet der Stapel in Sekunden.

Eine frische Installation zeigt Stammdaten, Buchhaltung, Banking und Postbox. Alles andere liegt hinter Schaltern, die ausgeschaltet ausgeliefert werden — nachzulesen in der Beispielkonfiguration des Repositories.

# Secrets erzeugen — idempotent
./scripts/bootstrap-env.sh

# Postgres, Ollama und die Anwendung starten
docker compose up -d

# Schema und Erweiterungen einspielen
docker compose exec -T app npm run db:migrate

# Anwendung öffnen
open http://localhost:3000

Was darunter liegt

Gewöhnliche, langlebige Bausteine. Ihre Daten liegen in einer normalen PostgreSQL-Datenbank — auslesbar, sicherbar und portierbar, auch ohne uns.

Anwendung
Next.js 16, React 19, Node.js 24
Datenbank
PostgreSQL 17 mit pgvector und pg_trgm
Datenzugriff
Drizzle ORM, Migrationen im Repository
Hintergrundläufe
pg-boss, dauerhaft in Postgres
Anmeldung
Better-Auth mit Passkey und Magic-Link
Oberfläche
Tailwind CSS v4 und shadcn/ui
KI
AI SDK v6, ein Anbieter angebunden; Einbettungen lokal über Ollama
Bankdaten
CSV und CAMT.053; FinTS, EBICS und PSD2 nicht angebunden

Fahrplan

Eine Absicht, keine Zusage. Wir veröffentlichen sie trotzdem, damit Sie einordnen können, worauf Sie sich einlassen. Ein Termin ohne offenes Ticket dahinter ist kein Termin — deshalb stehen hier Zeitfenster und keine Tage.

  1. Alpha (offener Kern)

    Q3 2026

    In Arbeit
  2. Erste Pilotverwaltung

    Q4 2026

    Geplant
  3. V1 Phase 1 — Fundament

    Q1–Q2 2027

    Geplant
  4. V1 Phase 2 und 3

    Q4 2027 – Q3 2028

    Geplant
  5. V1 allgemein verfügbar

    Q4 2028

    Geplant

Migrieren müssen Sie ohnehin. Reden wir über den Weg.

Der Support für ein System, auf dem ein erheblicher Teil des deutschen Wohnungsbestands verwaltet wird, endet zum 31.12.2028. Wir sind heute nicht so weit, dass wir Ihnen diesen Wechsel abnehmen könnten — aber wir suchen die Häuser, die ihn mit uns vorbereiten. Wenn Sie zwischen 300 und 1.500 Wohneinheiten verwalten und bereit sind, ein System im Alpha-Stadium mit echten Daten zu erproben: schreiben Sie uns. Wir erzählen Ihnen ehrlich, was heute geht und was nicht.