DATEV-Export aus der Hausverwaltung: Format 7.0, CP1252 und das Belegbundle, das die Kanzlei wirklich will

Es gibt eine Szene, die sich in deutschen Hausverwaltungen quartalsweise wiederholt. Der Verwalter zieht aus der Software einen CSV-Export, hängt ihn an eine E-Mail an die Kanzlei, schiebt einen Ordner mit eingescannten Rechnungen hinterher und schreibt: „Anbei die Buchungen für Q1, die Belege folgen separat.” In der Kanzlei wartet eine Buchhaltungskraft, die diese Datei in DATEV Rechnungswesen pro importieren soll. Sie öffnet die CSV, sieht Umlaute als Fragezeichenkästchen, ein Datumsfeld im US-Format, fünf Spalten mehr als erwartet — und ruft zurück. Genau diese Szene wollten wir bei ImmoGenio nicht reproduzieren. Deshalb haben wir den DATEV-Export nicht „irgendwie als CSV” gebaut, sondern strikt entlang der DATEV-Spezifikation für das Format 7.0 mit allem, was dazugehört: Header-Zeile, korrektes Encoding, Validierung der Stammdaten, ZIP-Bundle mit Belegen und einer reproduzierbaren Historie.

Dieser Artikel erklärt, warum dieser Aufwand kein Selbstzweck ist, sondern den Unterschied zwischen einer akzeptierten Buchungsperiode und einem Rückläufer aus der Steuerkanzlei ausmacht.

Was DATEV-Format 7.0 eigentlich ist

Wenn von „DATEV-Export” gesprochen wird, ist in über 90 Prozent der Fälle der Buchungsstapel im DATEV-Format 7.0 gemeint. Es ist das offizielle Importformat für DATEV Rechnungswesen pro, DATEV Kanzlei-Rechnungswesen und auch für DATEV Unternehmen online. Eine fertige Exportdatei besteht aus zwei klar getrennten Bereichen: einem Header in Zeile 1, der 29 Felder umfasst und dem Empfangssystem alle Metadaten zur Verarbeitung mitgibt, und ab Zeile 2 dem eigentlichen Datenteil mit Buchungen, der ebenfalls einer fixen Spaltenstruktur mit 22 nutzbaren Kernspalten folgt. Der Header signalisiert unter anderem das verwendete Format, die Versionsnummer (7), das DATA-Kategorie-Kennzeichen 21 für Buchungsstapel, die Berater- und Mandanten-Nummer, das Wirtschaftsjahr, die Erstkontonummernlänge, den Buchungszeitraum und das verwendete Encoding.

Genau diese Selbstauskunft im Header ist der Grund, warum DATEV den Stapel ohne Rückfrage importieren kann. Fehlt der Header oder ist er strukturell falsch, lehnt das Empfangssystem die Datei ab. Es gibt keinen toleranten Modus.

29 Felder im Header, 22 im Datenteil — und warum drei davon entscheidend sind

Die Header-Zeile mit 29 Feldern ist halbwegs schnell befüllt, weil sie sich aus den Mandanten-Stammdaten und dem aktuellen Buchungszeitraum ergibt. Das eigentliche Spielfeld ist der Datenteil. Die DATEV-Spezifikation listet hier 22 Kernspalten, von denen für eine Hausverwaltung typischerweise immer dieselben relevant sind: Umsatz mit Soll-/Haben-Kennzeichen, WKZ Umsatz, Kurs, Basisumsatz, WKZ Basisumsatz, Konto, Gegenkonto (ohne BU-Schlüssel), BU-Schlüssel, Belegdatum, Belegfeld 1, Belegfeld 2, Skonto, Buchungstext, Postensperre, Diverse Adressnummer, Geschäftspartnerbank, Sachverhalt, Zinssperre, Beleglink und mehrere Felder für Kostenstellen.

Drei dieser Felder verdienen besondere Aufmerksamkeit, weil sie regelmäßig falsch befüllt werden:

Belegfeld 1 und Belegfeld 2 sind die Felder, mit denen DATEV die Buchung später wieder einer Rechnung zuordnet. Belegfeld 1 nimmt typischerweise die Rechnungsnummer auf, Belegfeld 2 ein zweites Identifikationsmerkmal — bei vielen Hausverwaltungen ein interner Belegcode oder die Mietvertragsnummer. Wer diese beiden Felder leert oder vertauscht, verliert die Verknüpfung zwischen Buchung und Beleg. Die Buchhaltung muss dann manuell nachpflegen.

Soll- und Haben-Konto sind keine zwei Felder im DATEV-Sinn. Das Format kennt nur ein „Konto” und ein „Gegenkonto” plus ein Soll-/Haben-Kennzeichen am Umsatz. Wer aus einer doppelten Buchführung naiv „Soll = Spalte X, Haben = Spalte Y” mappt, produziert vertauschte Buchungen. Korrekt ist immer: Konto ist das fachlich führende Konto der Buchung, Gegenkonto ist das gegenläufige, das Vorzeichen entscheidet das Soll-/Haben-Kennzeichen.

Buchungstext ist auf 60 Zeichen begrenzt. Wer hier eine vollständige Mietnebenkostenformel hineinschreibt, bekommt einen abgeschnittenen Text in der Kanzlei. Buchungstexte gehören kuratiert, nicht generiert.

CP1252, CRLF, Komma als Dezimaltrenner — und warum das alles nicht verhandelbar ist

Hier wird es technisch unsexy, aber wichtig. Der DATEV-Buchungsstapel ist eine CSV-Datei, aber er folgt nicht dem RFC 4180 für CSV. Die DATEV-Spezifikation verlangt:

• Encoding: ANSI/Windows-1252, also CP1252. Kein UTF-8, kein UTF-8 mit BOM, kein ISO-8859-15. Der Header signalisiert das Encoding zwar in einem eigenen Feld, in der Praxis akzeptiert das Empfangssystem aber nur CP1252 zuverlässig. Umlaute werden 1:1 als CP1252-Bytes geschrieben, also ä = 0xE4, ö = 0xF6, ü = 0xFC, ß = 0xDF. UTF-8 multibyte-Sequenzen werden im Import als Mojibake interpretiert.
• Zeilenende: CRLF (\r\n). Reines LF wie auf Linux/macOS-Systemen ist nicht spezifikationskonform, einzelne Zeilen können vom Empfänger nicht erkannt werden.
• Feldtrenner: Semikolon, nicht Komma. Komma ist der Dezimaltrenner für Beträge und Kurse. Wer Beträge im US-Format 1234.56 schreibt, importiert Cent-Beträge als Tausenderbeträge.
• Texteinschluss: Anführungszeichen für alle textuellen Felder, einfache Anführungszeichen innerhalb verdoppelt.

Diese vier Punkte sind keine Stilfragen. Verstöße führen zum harten Importabbruch. Wer einen DATEV-Export liefert, der unter macOS in einem UTF-8-Texteditor „gut aussieht”, liefert in 80 Prozent der Fälle eine Datei, die DATEV ablehnt. Der Test ist nicht das Auge, sondern der Hex-Editor. Wir validieren in der ImmoGenio-Pipeline daher byteweise: jede Datei wird nach dem Schreiben gegen ein erwartetes Byte-Profil gehalten, und der Header wird gegen einen festen regulären Ausdruck geprüft. Wer in dieser Pipeline einen Buchungstext mit einem ungeprüften Sonderzeichen einschleust, wird vom Encoder mit einem klaren Fehler abgewiesen — nicht erst von der Kanzlei.

Berater-Nr., Mandanten-Nr., Kontenlänge — Validierung als Zeile 1

Bevor überhaupt eine Buchungszeile geschrieben wird, prüfen wir drei Stammdaten-Felder hart gegen reguläre Ausdrücke:

• Beraternummer: ^\d{7}$ — exakt sieben Ziffern. Sechsstellige oder achtstellige Werte werden abgewiesen.
• Mandantennummer: ^\d{5}$ — exakt fünf Ziffern. Führende Nullen müssen erhalten bleiben.
• Erstkontonummernlänge: ganzzahlig im Bereich 4 bis 8. Sie steuert das Konten-Padding für SKR03/SKR04 und muss zur Konfiguration des Mandanten in DATEV passen.

Diese Validierung steht nicht zufällig am Anfang. Sie ist der Filter, der verhindert, dass eine ganze Buchungsperiode geschrieben wird, nur damit die Kanzlei beim Import in Sekunde 2 abbrechen muss, weil die Beraternummer eine Stelle zu kurz ist. Und sie verhindert, dass Mandanten-Stammdaten unbemerkt aus dem Tritt geraten. Wer schon einmal versucht hat, einen falsch importierten Buchungsstapel in DATEV wieder sauber rückgängig zu machen, weiß, dass die fünf Sekunden Validierung im Voraus den halben Arbeitstag im Nachgang sparen.

Das ZIP-Bundle: Buchungen und Belege gehören zusammen

Ein DATEV-Buchungsstapel ohne Belege ist die Hälfte der Wahrheit. Die Kanzlei kann die Buchungen verbuchen, aber die GoBD-konforme Beleglage ist beim Mandanten — also beim Verwalter — und damit getrennt. Spätestens bei einer Betriebsprüfung wird das schmerzhaft, weil die Prüfungsverwaltung der Finanzbehörden zunehmend digitale Belegketten erwartet.

Wir bündeln Buchungsdatei und Belege deshalb zu einem einzigen ZIP-Archiv. Im Wurzelverzeichnis liegt die EXTF_Buchungsstapel_<Mandant>_<Zeitraum>.csv, daneben ein Unterordner belege/, in dem die zugehörigen PDFs liegen. Die Verknüpfung erfolgt über das Feld Beleglink in der Buchungszeile (Form BEDI "belege/RE-2026-04-0123.pdf"). DATEV Unternehmen online und DATEV Rechnungswesen pro können dieses Belegfeld direkt auflösen, sobald die PDFs in das Belegarchiv eingelesen sind.

Das ZIP-Bundle hat drei harte Vorteile gegenüber dem klassischen „CSV per Mail, Belege per Cloud-Link”:

1. Atomarität: Es gibt einen Stand der Welt, nicht zwei. Entweder ist das Bundle vollständig, oder es wird abgewiesen.
2. Reproduzierbarkeit: Das ZIP ist Snapshot. Es lässt sich in fünf Jahren nochmal entpacken und gegen die Buchhaltung halten.
3. Übergabeschnittstelle: Ein einzelner SHA-256-Hash über das Bundle reicht der Kanzlei, um die Vollständigkeit zu bestätigen.

Wir nutzen für das Bundling die Streaming-fähige archiver-Bibliothek, schreiben das ZIP direkt in einen MinIO-Bucket und geben dem Verwalter einen signierten Download-Link mit begrenzter Gültigkeit. Wer die OCR-Vorstufe nicht mit Mistral Vision aufgesetzt hat, wird bemerken, dass die PDF-Pflege bei diesem Modell der Engpass ist — wir behandeln das im Artikel zur OCR-Belegerfassung.

Generalumkehr statt Vorzeichen-Trick

Negative Beträge sind in der WEG-Buchhaltung Alltag — Stornorechnungen, Gutschriften, Korrekturen aus dem Wirtschaftsplan. DATEV kennt für diese Fälle die sogenannte Generalumkehr. Sie ist kein Vorzeichen, sondern ein eigenes Kennzeichen in der Buchungszeile (Generalumkehr als Spalte, Werte 0 oder 1). Bei einer Generalumkehr wird die Buchung in DATEV intern als Stornierung der Originalbuchung verbucht und nicht als gegenläufige neue Buchung.

Der naive Weg — einfach den Betrag negativ schreiben und das Soll-/Haben-Kennzeichen drehen — funktioniert technisch, ist aber fachlich falsch. Er verschleiert die Stornierungsbeziehung. In der Auswertung tauchen zwei separate Buchungen auf, die fachlich zusammengehören. Bei einer Betriebsprüfung muss man dann manuell rekonstruieren, welche Stornierung zu welcher Originalbuchung gehört.

Wir mappen daher im SKR03-Generator jede Buchung mit einem ursprünglich negativen Wert auf eine Generalumkehr-Buchung mit positivem Betrag und gesetztem Generalumkehr-Flag. Das Mapping erfolgt deterministisch im Export-Layer, nicht in der originären Buchungserfassung — die Buchhaltung selbst bleibt mit Vorzeichen geführt, weil das in der internen Auswertung übersichtlicher ist. Erst der Export übersetzt in die DATEV-Welt.

Reproduzierbarkeit: Snapshot der Mandanten-Metadaten

Eine Betriebsprüfung kann fünf Jahre nach dem Buchungszeitraum auflaufen. Die GoBD (BMF-Schreiben vom 28.11.2019) und die §§ 145 bis 147 AO verpflichten den Steuerpflichtigen, Buchungsdaten und ihre Verarbeitung über zehn Jahre nachvollziehbar zu halten. Ein DATEV-Export ist kein Einmal-Artefakt, er ist ein Stück Buchhaltungs-Historie.

Genau deshalb speichert ImmoGenio jeden Export mit einem vollständigen Metadaten-Snapshot. Die Tabelle datev_exports (Migration 060) hält pro Export-UUID:

• Berater- und Mandantennummer zum Zeitpunkt des Exports
• den Buchungszeitraum (from_date, to_date)
• die SKR-Variante und die Erstkontonummernlänge
• den Hash der erzeugten CSV (SHA-256)
• den Hash des kompletten ZIP-Bundles
• die Anzahl exportierter Buchungen und Belege
• den User, der den Export angestoßen hat
• den MinIO-Object-Key des archivierten Bundles

Migration 061 ergänzt eine datev_exports_belege-Tabelle, die jeden im ZIP enthaltenen Beleg referenziert — mit der Original-Beleg-ID, dem Pfad innerhalb des Bundles und dem Belegdatum. Damit lässt sich auch in fünf Jahren noch beantworten: „Welcher Beleg wurde mit welchem Buchungstext am 12.04.2026 nach DATEV exportiert?”. Die Antwort ist ein SQL-Query, kein Telefonat.

Diese Historie ist eng verzahnt mit dem Archiv- und Aufbewahrungsfristen-Konzept, das die HGB-, AO-, WEG- und BetrSichV-Pflichten zusammenführt.

Wie ImmoGenio den DATEV-Export tatsächlich anbietet

Aus Sicht des Verwalters ist der Export ein Wizard mit drei Schritten:

1. Auswahl: Mandant, Buchungszeitraum, SKR-Variante. Die Software zeigt vorab, wie viele Buchungen und wie viele Belege im Bundle landen werden.
2. Validierung: Beraternummer und Mandantennummer werden gegen die genannten Regular Expressions geprüft. Fehlt eine Stamminfo, wird der Wizard hier blockiert und führt direkt in die Mandanten-Stammdaten.
3. Export: Die CSV wird im Hintergrund mit CP1252/CRLF erzeugt, Belege werden aus dem Belegarchiv geholt und ins ZIP gestreamt, das Bundle landet in MinIO. Der Verwalter sieht im Wizard einen signierten Download-Link, parallel wird die Datei optional direkt per DATEVconnect online übermittelt.

Jeder Export ist über eine UUID identifiziert. Wird derselbe Zeitraum noch einmal exportiert, weil sich nachträglich eine Korrektur eingeschlichen hat, entsteht ein neuer Export mit eigener UUID. Der alte Export bleibt im History-Tab des Mandanten sichtbar, inklusive Hashes und User. Damit ist der Lauf idempotent gegenüber dem Mandanten — die Kanzlei sieht klar, welcher Stand zuletzt verschickt wurde.

Jeder Export schreibt zusätzlich einen Eintrag ins Audit-Log. Der zugehörige History-Tab im Mandantencockpit zeigt nicht nur den Zeitstempel, sondern auch ein Diff zwischen dem aktuellen Mandantenstamm und dem zum Export-Zeitpunkt verwendeten Snapshot. Wer also drei Monate später feststellt, dass die Beraternummer geändert wurde, sieht sofort, welche Exports noch unter der alten Nummer liefen.

DATEVconnect online als nächste Stufe

Der CSV-Export per E-Mail bleibt der pragmatische Standard, aber er ist nicht das Ende der Reise. DATEV bietet mit DATEVconnect online eine REST-Schnittstelle, über die Buchungsstapel und Belege direkt aus der Mandantensoftware in die Kanzlei übermittelt werden — ohne Mailanhang, mit OAuth, mit Bestätigungs-Callback. Sobald die Kanzlei DATEVconnect online aktiviert hat, kann ImmoGenio das Bundle direkt einliefern. Der Verwalter sieht in der Historie nicht mehr nur „heruntergeladen am …”, sondern „eingespielt am …, bestätigt durch …”.

Wir sehen das DATEV-Ecosystem als Teil eines breiteren Schnittstellen-Ansatzes — was wir grundsätzlich von offenen API-Schnittstellen halten, gilt hier explizit auch.

Was bewusst nicht gebaut wird

Ehrlichkeit über das, was nicht im Scope ist, gehört zu jeder Software-Architektur. Beim DATEV-Export verzichten wir bewusst auf:

• KNE/OBE-Postversand: Das alte Postversand-Format ist seit Jahren von DATEV abgekündigt und auf Format 7.0 abgelöst. Wer es noch braucht, hat ein Migrationsproblem mit der Kanzlei, nicht mit unserer Software.
• Bidirektionalen Sync: Wir schreiben aus ImmoGenio nach DATEV, lesen aber keine Buchungen aus der Kanzlei zurück. Der Grund ist fachlich: die führende Buchhaltung liegt entweder bei der Kanzlei oder beim Verwalter, nicht in beiden Systemen gleichzeitig. Ein Sync produziert in der Praxis nur Konflikte und unklare Wahrheiten.
• OP-Listen-Import aus DATEV: Offene Posten werden in ImmoGenio aus den eigenen Sollstellungen und Zahlungseingängen aufgebaut. Die parallele Pflege im DATEV macht für die Kanzlei Sinn, in der Hausverwaltung würde sie doppelte Buchhaltung erzeugen.

Das hält die Verantwortung sauber: ImmoGenio ist Quelle der Hausverwaltungs-Buchhaltung, DATEV ist Empfänger und Konsolidierer in der Kanzlei. Diese Trennung passt zur Logik, die wir auch bei SEPA-Lastschriftläufen nach pain.008 und beim Wirtschaftsplan nach § 28 WEG durchziehen — die Hausverwaltung führt den fachlichen Stand, externe Systeme bekommen klar definierte Snapshots.

Wo wir stehen

Der DATEV-Export im Format 7.0 ist in ImmoGenio produktiv. Mandanten exportieren regelmäßig Quartals- und Monatsstapel, die Validierung greift zuverlässig, das ZIP-Bundle wird in den Kanzleien akzeptiert. Die Historie schreibt sich seit Migration 060/061 sauber, die Audit-Logs sind GoBD-tauglich nachvollziehbar. Was nicht produktiv ist: die direkte Einspielung über DATEVconnect online — das ist der nächste Schritt auf der Roadmap.

Wer die Belegseite parallel modernisiert, profitiert doppelt: ein DATEV-Export mit verlinkten ZUGFeRD- oder XRechnung-Belegen aus dem In-Flight-Swap der E-Rechnungs-Pipeline ist für die Kanzlei deutlich angenehmer als ein PDF-Stapel ohne maschinenlesbare Daten.

Was Sie aus diesem Artikel mitnehmen sollten

DATEV-Export ist kein „Datei-Download-Knopf”. Er ist eine Pipeline, die hart spezifiziert ist und keine Toleranz für Bequemlichkeitslösungen hat. Wer ihn ernst nimmt, baut ihn mit Validierung am Anfang, mit CP1252 und CRLF auf Byte-Ebene, mit Generalumkehr statt Vorzeichen-Trick und mit einem ZIP-Bundle, das Buchungen und Belege als atomare Einheit transportiert. Und er baut ihn mit einer Historie, die in fünf Jahren noch beantworten kann, was wann an wen geliefert wurde.

Genau das verlangt die GoBD (BMF-Schreiben vom 28.11.2019), das fordern die §§ 145 bis 147 AO, und das ist auch die Erwartungshaltung der Kanzlei, wenn sie nach IDW PS 880 ein Softwarezertifikat oder zumindest eine Verfahrensdokumentation einfordert. Software, die diesen Anspruch erfüllt, erspart der Kanzlei Rückfragen — und dem Verwalter den Anruf am Quartalsende.

Fragen, Rückmeldungen oder konkrete Anwendungsfälle aus Ihrer Verwaltung schicken Sie gern an kontakt@immogenio.de.