Wer als Eigentümer oder Hausverwaltung mehr als zehn Objekte betreut, kennt das Problem: Irgendwo läuft eine Prüffrist ab, ein Bauwerksbuch muss aktualisiert werden, ein externer Sachverständiger braucht Zugriff auf genau ein Haus. Und die Tabelle, die das alles abbilden soll, wird zur Fehlerquelle. Mit den neuen gesetzlichen Anforderungen in Österreich verschärft sich diese Situation erheblich. Eigentümer von Gebäuden, die vor 1919 errichtet wurden, müssen ihr Bauwerksbuch bis Ende 2027 registrieren lassen; für Bauten aus den Jahren 1919 bis 1945 gilt eine Frist bis 2030.
Dieser Beitrag analysiert, warum strukturierte Portfolioverwaltung und objektisolierter Zugriff zwei grundlegend verschiedene Anforderungen sind, die sich nicht in einer gemeinsamen Tabelle abbilden lassen. Er zeigt, welche Konsequenzen das für Hausverwaltungen mit 20 oder 50 Objekten hat, warum der ROI spezialisierter Software nicht primär in Zeitersparnis liegt und was Eigentümer sowie Eigentümergemeinschaften bei der Wahl ihrer Verwaltungslösung anders gewichten sollten als bisher.
Das Problem wächst mit jedem weiteren Objekt
Wer zehn Objekte verwaltet, kommt mit einer gepflegten Tabelle noch durch. Bei zwanzig oder fünfzig Objekten versagt dasselbe Werkzeug, nicht weil die Tabelle zu klein wäre, sondern weil das Datenmodell strukturell falsch ist. Mehr Zeilen lösen das Problem nicht.
§ 128a der Bauordnung für Wien schafft zwei parallele Fristhorizonte. Gebäude mit Baujahr bis einschließlich 1918 unterliegen Frist 1 mit 31.12.2027. Gebäude mit Baujahr 1919 bis einschließlich 1945 unterliegen Frist 2 mit 31.12.2030. Ein gemischtes Portfolio enthält damit gleichzeitig zwei unterschiedliche Compliance-Horizonte. Welche Frist für welches Objekt gilt, erklärt die Stichtage nach Baujahr im Detail. Ausgenommen sind Gebäude mit nicht mehr als 50 m² bebauter Grundfläche sowie Kleingartenhäuser. Wer diese Objekte nicht korrekt als ausgenommen erfasst, erzeugt Aufwand für Häuser, für die keine Pflicht besteht.
Das Zeitfenster für Frist-1-Objekte wird enger. Die MA 37 hat bereits auf mehrmonatige Wartezeiten hingewiesen. Wer den Überblick erst im Herbst 2027 herstellt, findet kaum noch Kapazitäten bei Ziviltechnikern oder Baumeistern. Eine Hausverwaltung mit zwölf Frist-1-Häusern muss heute wissen, welche davon noch nicht beauftragt sind. Einen vollständigen Überblick, welches Gebäude bis wann eingetragen sein muss, liefert die verlinkte Übersicht nach Baujahr.
Das eigentliche Skalierungsproblem ist nicht die Datenmenge. Es ist die Frage der Gleichzeitigkeit: Welches Haus ist als nächstes fällig? Aus einer unsortiert gewachsenen Tabelle mit Frist-1-, Frist-2- und ausgenommenen Objekten ist diese Frage nicht zuverlässig zu beantworten.
Warum Tabellenlösungen ab einer bestimmten Objektzahl strukturell scheitern
Das Kernproblem ist strukturell, nicht quantitativ. Eine Tabelle kennt nur eine Ebene: jede Zeile steht gleichwertig neben der anderen. Sobald ein Gründerzeithaus nicht eine, sondern mehrere Prüfpositionen hat, zum Beispiel Dach, Feuermauer und auskragende Fassadenelemente, wird jede Position zur eigenen Zeile. Das Objekt als Einheit löst sich im Tabellenraster auf.
Gestaffelte Prüfintervalle je Bauteil verschärfen das Problem. Wer sie korrekt führen will, muss jede Bauteil-Zeile mit dem übergeordneten Objekt verknüpfen. In der Praxis geschieht das über wiederholte Adressspalten oder Farbmarkierungen. Filter und Sortierung erzeugen kurzfristig Ordnung, aber sie verändern die Datenstruktur nicht. Wer das Thema Bauwerksbuch-Software und die Grenzen von Tabellenlösungen bereits kennt, weiß: Das Modell selbst ist das Problem.
Ein konkretes Bild aus der Wiener Praxis: Eine Hausverwaltung betreut 25 Objekte. Zwölf davon haben Baujahr bis einschließlich 1918 und unterliegen Frist 1. Acht haben Baujahr 1919 bis einschließlich 1945 und unterliegen Frist 2. Fünf Objekte sind wegen nicht mehr als 50 m² bebauter Grundfläche ausgenommen. Zwei Ziviltechniker sind für jeweils unterschiedliche Objekte zuständig. In einer gemeinsamen Tabelle treffen diese Datenebenen aufeinander. Zuständigkeiten verschwimmen, Fristen werden nicht nachgeführt, eine Änderung in Zeile 14 überschreibt versehentlich Zeile 15.
Manuelle Versionierung löst das nicht. Wer die Tabelle monatlich als neue Datei speichert, hat keine verlässliche Antwort darauf, welche Version gilt und wer zuletzt etwas geändert hat.
Das eigentliche Versagen zeigt sich nicht bei zehn Objekten, sondern in dem Moment, in dem mehrere Personen gleichzeitig auf dieselbe Datengrundlage zugreifen müssen. Damit ist das zweite Kernproblem benannt: die Zugriffssteuerung.
Portfolio-Sicht und objektisolierter Zugriff: zwei verschiedene Anforderungen
Zugriffssteuerung ist das eigentliche Kernproblem, sobald mehrere Personen mit denselben Objektdaten arbeiten. Dabei geht es um drei Rollen mit strukturell verschiedenen Informationsbedürfnissen.
Die Portfolio-Sicht beantwortet die Frage der Hausverwalterin: Welches Objekt hat die nächste Prüffrist? Welche Mängel sind noch offen? Wo steht das Bauwerksbuch im Erstellungsprozess? Diese Perspektive setzt Aggregation voraus. Sie funktioniert nur, wenn alle Objekte als einheitliche Datenbasis zusammengeführt werden.
Der objektisolierte Zugriff beantwortet eine andere Frage. Ein Ziviltechniker oder Baumeister, der mit der Erstellung eines Bauwerksbuchs beauftragt ist, braucht Zugang zu genau einem Haus: seinen Bauplänen, der Fotodokumentation nach Stiege und Top, dem Inspektionsplan je Bauteil. Er darf weder andere Objekte sehen noch Daten anderer Eigentümer einsehen.
Eigentümer und Eigentümergemeinschaften stehen zwischen diesen Polen. Sie interessieren sich ausschließlich für ihr Gebäude, nicht für das Gesamtportfolio der Hausverwaltung. Ihre Ansicht muss objektorientiert sein, ohne auf die Verwaltungsebene zuzugreifen.
Eine Tabelle kann diese drei Rollen nicht trennen. Wer Zugriff auf die Datei hat, sieht alles. Das ist kein Komfortproblem, sondern ein Datenschutz- und Haftungsproblem.
Eine Software, die nur die Portfolio-Sicht löst, lässt den beauftragten Ziviltechniker ohne gesicherte Arbeitsumgebung. Eine Software, die nur den Einzelobjektzugriff abbildet, lässt die Hausverwaltung bei der Koordination allein. Welche konkreten Anforderungen sich daraus für den Funktionsumfang einer spezialisierten Lösung ergeben, erläutert Ihre Vorteile als Hausverwaltung im Detail. Beide Anforderungen müssen gleichzeitig gelöst sein.
Ein konkretes Szenario aus der Wiener Altbaupraxis
Was diese abstrakte Anforderung in der Praxis bedeutet, lässt sich an einem konkreten Objekt durchspielen.
Eine Hausverwaltung betreut unter anderem ein Gründerzeithaus in Wien mit Baujahr 1904. Das Objekt unterliegt Frist 1 nach § 128a der Bauordnung für Wien, das Bauwerksbuch muss bis 31.12.2027 registriert sein. Prüfpflichtige Bauteile sind das Dach, die Straßenfassade mit Stuckverzierungen, auskragende Balkone, die Hoffassade und die Feuermauer. Für jeden dieser Bauteile gelten eigene Inspektionsintervalle. Eine strukturierte Übersicht dazu, welche Prüfintervalle für Wiener Wohngebäude im Allgemeinen gelten, verdeutlicht, wie vielschichtig die Dokumentationspflicht schon bei einem einzelnen Objekt ist.
Ein Baumeister wird über einen Marktplatz mit der Erstellung des Bauwerksbuchs beauftragt. Er benötigt Zugang zur Fotodokumentation nach Stiege und Top, zu den vorhandenen Bauplänen und zur aktuellen Mängelliste. Die anderen zwölf Objekte der Hausverwaltung gehen ihn nichts an. Sein Zugang muss auf dieses eine Haus beschränkt bleiben.
Parallel dazu erkundigt sich die Eigentümergemeinschaft nach dem Bearbeitungsstand. Sie möchte wissen, welche Mängel dokumentiert sind und welche Maßnahmen geplant sind. Auch hier gilt: Einblick in das eigene Objekt, kein Einblick in Fremdobjekte.
Die Hausverwaltung wiederum braucht gleichzeitig die Portfolioperspektive. Sie muss sehen, dass dieses Objekt in Bearbeitung ist, welche weiteren Häuser mit Frist 1 noch keinen beauftragten Baumeister haben und ob der verbleibende Zeitraum bis 31.12.2027 realistisch ausreicht.
Drei Rollen, drei Informationsbedürfnisse, ein Sachverhalt. Das Problem ist nicht die Datenmenge. Das Problem ist die Gleichzeitigkeit. Eine Tabellendatei kann diese drei Perspektiven nicht nebeneinander abbilden, ohne dass mindestens eine davon Zugang zu Daten erhält, die sie nicht sehen darf.
Was eine spezialisierte Software in diesem Kontext leisten muss
Das Szenario macht die Anforderungen sichtbar. Die Frage ist, was eine Software konkret erfüllen muss, damit es nicht beim Überblick bleibt.
Objekte als eigenständige Einheiten. Jedes Objekt braucht seinen eigenen Inspektionsplan je Bauteil, seine eigene Mängelverwaltung mit Fristen und Fotos sowie eine separate Dokumentenablage. Ein Gründerzeithaus mit Dach, Hoffassade und Feuermauer ist keine Zeile, sondern eine strukturierte Einheit mit mehreren Ebenen.
Automatisch aggregierte Portfolioansicht. Die Übersicht, welches Objekt als nächstes fällig ist, wo Mängel offen sind und welche Objekte noch keinen beauftragten Ersteller haben, darf nicht durch manuelle Pflege entstehen. Sie muss sich aus den Einzelobjektdaten automatisch ergeben. Sobald ein Datensatz im Objekt aktualisiert wird, ändert sich die Portfolioansicht ohne weiteres Zutun.
Granulare Zugriffsrollen. Ein Baumeister oder Ziviltechniker erhält Zugang zu genau dem Objekt, für das er beauftragt wurde, und zu keinem anderen. Die Hausverwalterin sieht alle Objekte ihres Portfolios. Der Eigentümer sieht sein Gebäude. Diese Trennung ist keine Komfortfunktion, sondern eine strukturelle Voraussetzung für den sicheren Parallelbetrieb mehrerer Projekte.
Automatische Fristermittlung aus Stammdaten. Trägt die Hausverwaltung Baujahr und bebaute Grundfläche ein, leitet die Software Frist 1 oder Frist 2 ab, oder sie stellt fest, dass das Objekt wegen nicht mehr als 50 m² bebauter Grundfläche ausgenommen ist. Dieser Schritt schützt vor Eingabefehlern, die in Tabellen bei manueller Zuweisung regelmäßig entstehen. Wie die Prüfung im Einzelnen abläuft, beschreibt die Software Schritt für Schritt.
Vom Überblick zur Aktion ohne Werkzeugwechsel. Die Beauftragung eines befugten Erstellers über einen integrierten Marktplatz und die Abstimmung des Begehungstermins direkt im System schließen die Lücke zwischen Erkenntnis und Umsetzung.
Software-Abschreibung als Kaufargument. Für Eigentümer, die das Objekt im Betriebsvermögen führen, können Anschaffungskosten für spezialisierte Software als Betriebsausgabe geltend gemacht werden. Die genauen Voraussetzungen sind mit dem Steuerberater zu klären. Dieser Aspekt ist bei der Kaufentscheidung relevant und wird in der Praxis häufig übersehen.
Der eigentliche ROI liegt nicht in der Zeitersparnis
Zeitersparnis ist messbar und deshalb beliebt als Rechtfertigungsargument. Bei der Verwaltung von Bauwerksbüchern greift dieses Argument zu kurz. Der entscheidende Wert liegt in der Verlässlichkeit der Information und der Vermeidung von Fristversäumnissen.
Eine versäumte Frist nach § 128a der Bauordnung für Wien ist kein Komfortproblem. Die zuständige Behörde ist die MA 37. Die Konsequenzen eines nicht rechtzeitig erstellten Bauwerksbuchs treffen unmittelbar die Eigentümer, die die Hausverwaltung beauftragt haben. Wer als Verwalter nicht nachweisen kann, welche Objekte fristgerecht bearbeitet wurden, steht in einem Haftungsverhältnis ohne Dokumentationsgrundlage.
Tabellen erzeugen hier eine trügerische Sicherheit. Eine befüllte Tabelle wirkt vollständig. Ob die letzte Aktualisierung einen Monat oder ein Jahr zurückliegt, ob ein Objekt irrtümlich als ausgenommen markiert wurde, ob ein Ziviltechniker bereits beauftragt wurde oder nur vorgemerkt ist: Das ist aus einer Tabellendatei nicht zuverlässig ablesbar. Was Definition und Zweck des Bauwerksbuchs verlangt, ist eine lückenlose, nachvollziehbare Dokumentation. Eine Tabelle kann das strukturell nicht leisten.
Der eigentliche ROI einer spezialisierten Software ist daher die Dokumentierbarkeit selbst. Die Hausverwaltung kann gegenüber Eigentümern jederzeit belegen, welche Objekte geprüft wurden, welche Mängel offen sind und welche Fristen laufen. Dieser Nachweis ist ein eigenständiger Wert, unabhängig davon, wie viele Stunden gespart werden.
Für Eigentümergemeinschaften kommt ein weiterer Aspekt hinzu. Das Bauwerksbuch ist nach seiner Erstellung fortzuführen. Komponenten mit Nachweisintervallen, Zwischenkontrollen und laufende Fotodokumentation sind kein einmaliges Projekt. Eine Software, die diesen Prozess über Jahre trägt, amortisiert sich durch die Laufzeit, nicht durch einen einmaligen Effizienzgewinn.
Was Eigentümer und Eigentümergemeinschaften anders gewichten
Eigentümer und Eigentümergemeinschaften stellen andere Fragen als Hausverwaltungen. Ihr Interesse gilt nicht dem Portfolio, sondern einem einzigen Gebäude: Was wurde geprüft? Welche Mängel sind dokumentiert? Wann ist die nächste Begehung fällig? Diese Transparenz ist ihre Kernanforderung.
Die Frist ist dabei keine abstrakte Behördenvorgabe. Ein Eigentümer eines Gründerzeithauses mit Baujahr 1910 hat nach § 128a der Bauordnung für Wien bis 31.12.2027 Zeit, das Bauwerksbuch registrieren zu lassen. Die MA 37 versendet keine Erinnerungen. Die Initiative liegt vollständig beim Eigentümer.
Für Eigentümer, die das Objekt im Betriebsvermögen führen, ist auch die steuerliche Einordnung relevant. Anschaffungskosten für eine spezialisierte Verwaltungslösung können als Betriebsausgabe behandelt werden. Die genaue Einordnung, insbesondere die Frage der Software-Abschreibung, ist mit dem Steuerberater zu klären.
Vollständige und strukturierte Unterlagen entfalten darüber hinaus Wirkung bei Dritten. Versicherungen und Banken, die einen belegten Gebäudezustand benötigen, verlassen sich nicht allein auf das Bauwerksbuch. Laufende Mängelberichte und dokumentierte Instandhaltungsmaßnahmen stärken die Position des Eigentümers bei Bewertungen und Finanzierungsgesprächen.
Ein isolierter Objektzugang hat schließlich einen praktischen Nebeneffekt in der Eigentümer-Verwalter-Beziehung. Wer den aktuellen Stand seines Gebäudes selbst einsehen kann, ist nicht darauf angewiesen, die Hausverwaltung um Auskunft zu bitten. Das schafft Klarheit auf beiden Seiten.
Fazit: Zwei Anforderungen, eine Lösung
Die unterschiedlichen Perspektiven von Hausverwaltungen und Eigentümern verdeutlichen dasselbe strukturelle Problem aus zwei Blickwinkeln. Die Lösung muss beide Ebenen gleichzeitig tragen.
Eine Hausverwaltung mit zwanzig oder fünfzig Objekten benötigt den zentralen Portfolioüberblick und den isolierten Objektzugang für externe Ersteller zur selben Zeit. Eine Tabelle kann diese beiden Anforderungen nicht trennen. Wer Zugang zur Datei hat, sieht alles. Das ist kein Komfortproblem, sondern ein strukturelles Versagen.
Die Frist 1 endet am 31.12.2027. Der Zeitpuffer für Beauftragung, Begehung und Registrierung schrumpft mit jedem Monat. Portfolios mit mehreren Objekten mit Baujahr bis einschließlich 1918 sollten die Planung nicht auf das zweite Halbjahr 2027 verschieben. Qualifizierte Ziviltechniker und Baumeister sind ein begrenztes Ressourcenkontingent.
Eine spezialisierte Software löst beide Anforderungen parallel. Auf Portfolioebene zeigt sie, welches Objekt als nächstes fällig ist. Externen Erstellern gibt sie isolierten Zugang zu genau dem Objekt, für das sie beauftragt sind, und zu keinem anderen.
Der eigentliche Wert liegt in der Dokumentierbarkeit. Wer gegenüber Eigentümern und der MA 37 jederzeit nachweisen kann, welche Prüffristen laufen und welche Mängel offen sind, handelt nicht nur effizienter, sondern auch rechtssicher. Diese Verlässlichkeit entsteht nicht durch mehr Pflege einer Tabelle, sondern durch eine andere Datenstruktur.
Bauwerksbuchhaltung unterstützt Hausverwaltungen in Wien dabei, Objekte zu verwalten, Prüfpflichten automatisch zu ermitteln, Ersteller über einen integrierten Marktplatz zu beauftragen und das Bauwerksbuch nach der Erstellung fortzuführen. Der Einstieg beginnt mit der Anlage eines Objekts unter app.bauwerksbuchhaltung.com.
