Zurück
— GoBD

GoBD-konformer ZIP-Daten-Export: Was Betriebsprüfer und Steuerberater wirklich aus der Hausverwaltungs-Software bekommen müssen

ImmoGenio·
Übergabe eines Schlüsselbunds zwischen zwei Verwaltern an der Haustür

Wenn der Prüfer in einer Woche vor der Tür steht

Stellen Sie sich folgende Situation vor: Am 14. April erreicht Ihre Verwaltung eine Prüfungsanordnung des Finanzamts. Geprüft werden die Geschäftsjahre 2021 bis 2024, der Außendienstprüfer kündigt sich für den 21. April an. Im begleitenden Schreiben verlangt er einen Z3-Datenträgerzugriff nach § 147 Abs. 6 AO — also einen vollständigen, maschinell auswertbaren Daten-Auszug aller aufzeichnungspflichtigen Bestände. Eine Woche Vorlauf, vier Geschäftsjahre, zehntausende Buchungssätze, Stammdaten, Verträge.

Ihre Hausverwaltungs-Software hat einen DATEV-Export. Das wissen Sie. Sie haben den Stapel schon hundertmal an Ihren Steuerberater geschickt. Aber der Prüfer wird damit nicht zufrieden sein. Er will nicht nur die Buchungen, er will den ganzen Datenstamm: Kontenplan, Belege, Objekte, Einheiten, Mieter, Mietverträge, Eigentümer, Nebenkostenabrechnungen, Audit-Log. Lückenlos. Auswertbar. Mit einer Beschreibung, die er ohne Rückfrage in seine Prüfsoftware einlesen kann.

Genau dafür existiert der GoBD-konforme ZIP-Export. Er ist mehr als ein DATEV-Stapel und weniger als eine vollständige Datenbank-Replikation. Er ist das Format, das die Finanzverwaltung seit der GoBD-Anlage zum BMF-Schreiben vom 28.11.2019 erwartet — und das jeder seriöse SaaS-Anbieter seinen Mandanten bis zum letzten Tag der Vertragsbeziehung schulden muss.

Drei Anlässe, an denen ein vollständiger Daten-Export gebraucht wird

Der GoBD-ZIP-Export ist kein Routine-Werkzeug für die monatliche Buchhaltung. Er ist ein Werkzeug für vier klar abgrenzbare Anlässe, in denen die Datenhoheit den Eigentümer wechselt oder ein Dritter den vollständigen Bestand sehen muss.

Anlass 1: Betriebsprüfung mit Z3-Zugriff. § 147 Abs. 6 AO unterscheidet drei Zugriffsarten der Finanzbehörde. Z1 ist der unmittelbare Lesezugriff auf das Produktivsystem, Z2 der mittelbare Zugriff über Auswertungen durch den Steuerpflichtigen, Z3 die Übergabe eines Datenträgers mit den prüfungsrelevanten Daten. In der Praxis verlangen Prüfer fast immer Z3, weil sie die Daten in ihre eigene Prüfsoftware (IDEA oder ACL) einlesen wollen. Die GoBD-Anlage Rz. 158 ff. legt dafür ein „Beschreibungsstandard”-Format fest — das ist genau der GoBD-ZIP-Export.

Anlass 2: Mandanten-Wechsel. Eine WEG kündigt das Verwaltungs-Mandat und wechselt zur konkurrierenden Verwaltung. Die scheidende Verwaltung muss alle Stammdaten, Buchungsjournale und Verträge in einem Format übergeben, das die übernehmende Verwaltung (oder zumindest deren Steuerberater) sichten kann. Ein proprietäres Datenbank-Backup ist hier untauglich — der Empfänger hat keine Lizenz für Ihr System.

Anlass 3: Steuerberater-Wechsel. Der Mandant wechselt die Kanzlei, der neue Berater braucht Zugriff auf die Buchführung der letzten drei Jahre, einschließlich Kontenplan, Belegen und Erläuterungen. Auch hier reicht der DATEV-Stapel oft nicht — die neue Kanzlei will Stammdaten und Audit-Log zur Plausibilisierung.

Anlass 4: DSGVO-Auskunft nach Art. 20. Ein Eigentümer fordert die Übertragung seiner personenbezogenen Daten in einem strukturierten, gängigen, maschinenlesbaren Format. CSV in einem ZIP erfüllt diese Anforderung. Der GoBD-Export ist damit gleichzeitig die technische Antwort auf das Recht auf Datenübertragbarkeit.

Was die GoBD an einen Export wirklich verlangt

Die GoBD selbst ist kein Gesetz, sondern ein BMF-Schreiben — aber sie konkretisiert die Auslegung der §§ 145 bis 147 AO und ist für die Finanzverwaltung bindend. Die Anlage zum BMF-Schreiben vom 28.11.2019 beschreibt in den Randziffern 158 bis 167 das erwartete Export-Format. Vier Kernanforderungen lassen sich daraus ableiten:

Beschreibungsstandard. Der Export muss eine Beschreibungs-Datei enthalten, die alle exportierten Tabellen, Felder, Datentypen und Schlüsselbeziehungen dokumentiert. In der Praxis hat sich dafür eine index.xml etabliert, die der Prüfer in IDEA direkt einlesen kann. Ohne diese Beschreibung ist der Export wertlos — der Prüfer weiß sonst nicht, welche Spalte welche Bedeutung hat.

Auswertbares Format. CSV oder XML. Kein proprietäres Binär-Format, kein PDF (außer für Belege als Anlage), keine Excel-Datei mit Formeln. Die GoBD bevorzugt klar strukturierte Textformate, weil sie sich in jeder Prüfsoftware verarbeiten lassen.

Vollständigkeit. Der Export muss alle aufzeichnungspflichtigen Daten der gewählten Periode enthalten. „Aufzeichnungspflichtig” bedeutet: alles, was nach AO, HGB, EStG oder Spezialgesetzen (BetrKV, WEG) festzuhalten ist. Eine selektive Auswahl („wir liefern nur die Konten, die der Prüfer explizit nennt”) ist nicht zulässig.

Lesbarkeit. Keine Verschlüsselung, keine Komprimierung, die einen exotischen Wiederhersteller braucht. Ein Standard-ZIP ist ausdrücklich erlaubt — es gilt seit Jahrzehnten als universelles Container-Format. Ein 7zip-Archiv mit Passwort wäre dagegen problematisch.

Mindestbestand für eine Hausverwaltungs-Software

Welche Tabellen gehören in den Export einer professionellen Hausverwaltungs-Plattform? Aus den GoBD-Anforderungen plus den fachlichen Pflichten des Verwalters (HGB, BetrKV, WEG-Recht) ergeben sich zehn Pflicht-Bestandteile, die in jedem ImmoGenio-Export enthalten sind.

Diese zehn Tabellen sind kein willkürlicher Katalog. Sie ergeben sich aus der Pflicht zur lückenlosen Aufzeichnung nach § 145 AO in Verbindung mit den Spezialregelungen für Hausverwalter. Der Prüfer kann an dieser Struktur eine vollständige Plausibilisierung durchführen — von der Eigentümer-Stammakte über das Mietverhältnis bis zur Einzel-Buchung.

SHA-256 als Integritäts-Anker

Ein Export-ZIP ist nur dann beweissicher, wenn der Empfänger nachweisen kann, dass die Datei nicht verändert wurde. Dafür berechnet ImmoGenio einen SHA-256-Hash über das gesamte ZIP-Archiv und liefert ihn auf zwei Wegen aus.

Erstens als HTTP-Response-Header X-Export-SHA256 beim Download. Wer den Export per API zieht, kann den Hash direkt aus der Antwort lesen und mit dem lokal gerechneten Wert vergleichen.

Zweitens als Eintrag im Audit-Log. Der Export-Vorgang selbst wird als Mutation protokolliert — mit Zeitstempel, auslösendem User, gewählter Periode und dem Hash des erzeugten Archivs. Damit ist auch Wochen später nachvollziehbar, welcher Export an wen ausgehändigt wurde. Wenn der Prüfer drei Monate nach der Übergabe Rückfragen stellt, lässt sich am Hash zweifelsfrei prüfen, ob die ihm vorliegende Datei mit dem ausgelieferten Stand identisch ist.

Diese Verzahnung mit dem Audit-Log ist kein Zusatz, sondern Pflicht — wer den Export selbst nicht protokolliert, hat eine Lücke in der Revisionssicherheit. Wir haben die zugrunde liegende Architektur im Beitrag Audit-Trail, Mutationen und revisionssichere Append-Only-Logs ausführlich beschrieben.

Was der GoBD-Export vom DATEV-Export unterscheidet

Eine Frage, die in jedem ersten Gespräch mit Verwaltungen aufkommt: „Wir haben doch einen DATEV-Export, reicht der nicht?” Die ehrliche Antwort lautet: Für die Steuerkanzlei ja, für die Betriebsprüfung nein.

Der DATEV-Export liefert die Buchungsstapel im DATEV-Format mit dem standardisierten 29-Feld-Header in CP1252-Codierung. Er ist optimiert für den Import in DATEV-Kanzleisoftware und enthält genau das, was der Steuerberater für die Jahresabschluss-Erstellung braucht: Buchungen plus Kontenplan plus Belege als gebündeltes ZIP. Wir haben das Format im Beitrag DATEV-Export-Format: 7 CSV-Spezifikationen und Beleg-Bundle detailliert beschrieben.

Was der DATEV-Export aber nicht liefert: den vollständigen Datenstamm. Er enthält keine Mietverträge, keine Eigentümer-Stammdaten, keine Nebenkostenabrechnungen als auswertbare Tabelle, kein Audit-Log. Für den Steuerberater ist das in Ordnung — er braucht nur die Buchungs-Schicht. Für den Betriebsprüfer ist es unzureichend, weil er die Plausibilität der Buchungen gegen die Stammdaten prüfen will. Wenn ein Mietvertrag eine Indexklausel mit Anpassungstermin 1.1.2023 hat, will der Prüfer nachvollziehen können, ob die Mieterhöhung zu diesem Termin tatsächlich gebucht wurde.

Der GoBD-ZIP-Export ergänzt den DATEV-Export, ersetzt ihn nicht. In der Praxis stellen seriöse Plattformen beide Formate parallel bereit: DATEV für die laufende Kanzlei-Übergabe, GoBD-ZIP für Prüfungen und Mandantenwechsel.

Fair-Play als Versprechen, nicht als Marketing-Phrase

Hier kommt die unbequeme Wahrheit. SaaS-Anbieter haben ein strukturelles Interesse, den Datenexport zu erschweren. Wer nur mühsam aus einem System herauskommt, bleibt länger drin. Manche Plattformen liefern keinen vollständigen Export, andere knüpfen ihn an kostenpflichtige Zusatzpakete, wieder andere brauchen vier Wochen Vorlauf für die Bereitstellung.

Aus Sicht des Mandanten ist das Datenhoheits-Verletzung. Die Buchführungsdaten gehören dem Eigentümer, nicht dem Verwalter und schon gar nicht dem Software-Hersteller. Wenn die Verwaltung das Mandat verliert, wenn der Mandant die Plattform wechseln will, wenn der Prüfer einen Z3-Zugriff verlangt — in all diesen Fällen muss der Export sofort und vollständig verfügbar sein.

ImmoGenio formuliert das auf der Landing-Page als Selbstverpflichtung: „bis zum letzten Tag alle Stammdaten und Buchungsjournale als CSV/Excel oder GoBD-konformes ZIP-Archiv”. Das ist keine Marketing-Phrase, sondern eine technische Garantie. Auch nach Kündigung des Mandats bleibt der Export bis zum Ende der Vertragslaufzeit aktiv. Der Mandanten-Admin kann jederzeit ohne Rückfrage einen vollständigen Auszug herunterladen.

Asynchroner Job-Flow für große Bestände

Bei kleinen WEG-Mandanten mit zwölf Einheiten und ein paar tausend Buchungen pro Jahr läuft der Export synchron in zwei bis drei Sekunden durch. Der User klickt auf „Export erstellen”, das ZIP wird im Browser zum Download angeboten, fertig.

Bei großen Mandanten mit zehntausenden Belegen und Audit-Trail-Einträgen über vier Geschäftsjahre wird das problematisch. HTTP-Requests, die länger als 30 Sekunden offen bleiben, sind weder benutzerfreundlich noch zuverlässig — Proxies, Load-Balancer und Browser-Timeouts schließen die Verbindung. Für diesen Fall ist ein asynchroner Job-Flow in Vorbereitung: Der User stößt den Export an, bekommt einen Job-Token zurück, kann den Status pollen und am Ende den fertigen Download abrufen. Das Archiv wird dabei serverseitig gepuffert und nach 24 Stunden gelöscht.

Iteration eins ist synchron und deckt den weit überwiegenden Anteil der Mandanten ab. Die asynchrone Variante folgt im Roadmap-Quartal, wenn die ersten Großmandanten an die Synchron-Grenze stoßen.

Praxisbeispiel: Mandantenwechsel in einer WEG

Eine Verwaltungs-Gesellschaft betreut 14 WEG-Mandanten. Mandant Nr. 7 hat in der letzten Eigentümerversammlung die Verwaltung neu ausgeschrieben und einen Konkurrenz-Anbieter beauftragt. Die abgebende Verwaltung muss bis zum 30.6. den vollständigen Datenstamm übergeben, sonst drohen Schadensersatz-Forderungen.

Der Mandanten-Admin meldet sich in ImmoGenio an, navigiert zum Bereich /dsgvo und wählt den Punkt „Daten-Export (GoBD)”. Er stellt das Geschäftsjahr 2024 ein, klickt auf „Export erstellen”. Der Server lädt parallel Buchungen, Kontenplan, Belege, Objekte, Einheiten, Mieter, Mietverträge, Eigentümer, NK-Abrechnungen und Audit-Log, schreibt jeden Datensatz in eine eigene CSV, generiert die index.xml mit Strukturbeschreibung und die README.txt mit Kontext, packt alles in ein ZIP und berechnet den SHA-256-Hash.

Drei Sekunden später erscheint der Download-Dialog im Browser. Die Plattform zeigt den Hash an: a3f1...c79e. Der Mandanten-Admin notiert ihn, übergibt das ZIP per verschlüsselter Datentransfer-Lösung an die übernehmende Verwaltung und sendet den Hash separat per Mail. Die übernehmende Verwaltung prüft mit shasum -a 256 lokal nach dem Empfang und kann zweifelsfrei bestätigen, dass die Datei unverfälscht angekommen ist.

Der gesamte Vorgang ist im Audit-Log protokolliert: User, Zeitpunkt, Periode, Hash. Sollten Monate später Rückfragen kommen, ist der Stand exakt rekonstruierbar.

Wie ImmoGenio das technisch umsetzt

Das Backend stellt eine Route gobd-export.ts mit dem Endpunkt GET /api/gobd-export/download?year=<YYYY> bereit. Der Service gobd-export.service.ts orchestriert die Loader für die zehn Pflicht-Tabellen, generiert die Strukturbeschreibung und schreibt das ZIP-Archiv in einem Stream zurück. Der SHA-256-Hash wird parallel zum Streaming berechnet und im Response-Header ausgeliefert.

Defensives Error-Handling pro Loader ist Pflicht. Wenn der Belege-Loader fehlschlägt — etwa weil ein PDF in der Objekt-Storage nicht mehr referenzierbar ist — bricht der Export nicht komplett ab. Stattdessen wird ein Fehler-Eintrag in der README.txt hinterlegt („Belege-Tabelle teilweise unvollständig, betroffene IDs: …”), der Rest läuft durch. Der Prüfer hat damit eine ehrliche Aussage über Datenlücken statt einer leeren Datei.

Die Frontend-Komponente unter /dsgvo zeigt einen Jahr-Selector, einen Erstellen-Button und nach erfolgreichem Download den SHA-256-Hash mit Copy-to-Clipboard. Hilfetexte erklären den Anwendungs-Kontext (Betriebsprüfung, Mandantenwechsel, Steuerberater-Wechsel, DSGVO-Auskunft) und verweisen auf die rechtliche Grundlage.

Mandantentrennung ist über Row Level Security garantiert — jeder Export sieht ausschließlich die Daten des aktiven Mandanten, ein Cross-Tenant-Leak ist auf DB-Ebene ausgeschlossen. Hintergrund dazu im Beitrag Row Level Security: Multi-Tenancy und Mandantentrennung.

Die Verbindung zur Aufbewahrungs-Logik

Der GoBD-Export ist nicht isoliert. Er steht in einem Geflecht aus Aufbewahrungspflichten, Lösch-Workflows und Datenübertragbarkeit. Aus dem Export lassen sich Aufbewahrungsfristen direkt ablesen — Buchungen unterliegen zehnjähriger Frist nach § 147 AO, Verträge sechsjähriger nach § 257 HGB, WEG-spezifische Unterlagen folgen der BetrKV. Die systematische Behandlung dieser Fristen haben wir im Beitrag zu Aufbewahrungsfristen nach HGB, AO, WEG und BetrSichV beschrieben.

Auch der Offboarding-Prozess hängt am Export. Wenn der letzte Admin eines Mandanten gehen will, muss er vorher den GoBD-Export anstoßen — sonst verliert der Mandant die Datenhoheit irreversibel. Der Sole-Admin-Guard verhindert genau diesen Fall, dazu mehr im Beitrag User-Offboarding nach DSGVO Art. 17 mit Sole-Admin-Guard.

Grenzen der ersten Iteration

Damit Erwartungen klar bleiben, hier die bewussten Limits der aktuellen Umsetzung. Erstens: synchroner Export. Für Mandanten mit mehreren hunderttausend Belegen wird ein asynchroner Job-Flow nachgezogen. Zweitens: keine inkrementellen Exports. Die Periode wird voll exportiert, Delta-Auszüge zwischen zwei Stichtagen sind nicht vorgesehen — der Prüfer braucht ohnehin die volle Periode, der Mandantenwechsel in der Regel auch. Drittens: kein Re-Import-Workflow auf der Empfänger-Seite. Wer das ZIP in eine andere Plattform einlesen will, muss eine eigene Migrations-Pipeline aufbauen. Das ist eine separate Disziplin und nicht Teil des Export-Scope.

Wo wir stehen

Der GoBD-konforme ZIP-Export ist als Epic 165 produktiv. Alle ImmoGenio-Mandanten haben unter /dsgvo Zugriff auf den Export-Dialog, alle zehn Pflicht-Tabellen sind implementiert, der SHA-256-Hash wird im Response-Header und im Audit-Log protokolliert. Die asynchrone Variante ist im nächsten Quartal eingeplant.

Sprechen Sie uns an

Wenn Sie eine Betriebsprüfung vor sich haben, einen Mandantenwechsel vorbereiten oder Ihre aktuelle Software die Datenhoheit nicht zuverlässig zurückgibt — wir zeigen Ihnen den Export-Dialog gern in einer kurzen Demo. Schreiben Sie an kontakt@immogenio.de oder buchen Sie einen Termin über die Landing-Page.


immoGenio-Newsletter abonnieren

Neue Fachbeiträge zu Hausverwaltung, WEG-Recht und PropTech — sachlich aufbereitet, kostenlos und jederzeit abbestellbar.

Mit Ihrer Anmeldung stimmen Sie unserenDatenschutzbestimmungenzu. Sie können sich jederzeit über den Link am Ende jeder Ausgabe wieder abmelden.

— Voriger Beitrag
Wohnungsmängel nach § 536c BGB: Mangelanzeige, Vermieter-Reaktion und das Recht auf Selbstvornahme
— Naechster Beitrag
Mietkaution nach § 551 BGB aus Vermietersicht: Hinterlegung, Verwendung und das Aufrechnungsverbot