Buchhaltungsübergabe / Deutschland
Ihr Steuerberater will keine CSV-Datei
Er will einen EXTF-Buchungsstapel: eine semikolongetrennte, CP1252-kodierte Datei, die DATEV Rechnungswesen ohne Widerrede importiert. Hier steht, was diese Datei verlangt und an welchen fünf Stellen ein allgemeiner Export daran scheitert.
Was die Datei tatsächlich ist
- 1Eine Kopfzeile mit MetadatenSie deklariert Format, Version, Berater- und Mandantennummer sowie das Wirtschaftsjahr des Stapels. Das Jahr jeder einzelnen Buchung stammt aus dieser Zeile.
- 2Eine Zeile mit SpaltenüberschriftenSie benennt jedes Feld. DATEV liefert mehrere Formatversionen mit unterschiedlichen Feldsätzen aus, weshalb ein einziger Testimport mehr wert ist als jede Herstellerzusage.
- 3Ein Datensatz pro BuchungSemikolongetrennt, mit CRLF-Zeilenenden. Jeder Satz enthält einen Betrag, ein Vorzeichenkennzeichen, ein Konto, ein Gegenkonto, ein Belegdatum und eine Belegnummer.
Die fünf Dinge, die schiefgehen
Nichts davon ist exotisch. Jeder dieser Punkte ist eine Voreinstellung, die fast überall sonst in der Software richtig ist und hier falsch.
DATEV importiert EXTF standardmäßig als ANSI, also CP1252. Moderne Laufzeitumgebungen geben nur UTF-8 aus. Ein naheliegend geschriebener Export erzeugt deshalb eine Datei, in der jeder Umlaut zerstört ist: aus „Gehälter“ wird „Gehälter“.
Die Lösung ist, byteweise selbst zu kodieren. ASCII und Latin-1 lassen sich eins zu eins abbilden, was ä ö ü ß abdeckt. Das Eurozeichen und einige CP1252-Sonderzeichen brauchen eine ausdrückliche Zuordnung, und alles wirklich nicht Kodierbare wird zu „?“, statt die Zeile zu zerstören.
Beträge verwenden ein Dezimalkomma und kein Tausendertrennzeichen. 1463.70 ist keine Zahl, die DATEV liest. 1463,70 schon.
Es gibt keine negativen Beträge. Jeder Wert ist positiv, und die Richtung trägt getrennt das Soll/Haben-Kennzeichen: S für Soll, H für Haben. Ein Export, der -1463,70 schreibt, beschreibt etwas, das DATEV nicht kennt.
Das Belegdatum im Buchungsstapel ist TTMM: nur Tag und Monat, vier Ziffern. Das Jahr steht überhaupt nicht im Datensatz. Es kommt aus dem Wirtschaftsjahr der Kopfzeile, weshalb ein Stapel auch niemals zwei Jahre umfassen darf.
Das ist der Punkt, an dem ein allgemeiner Export still scheitert, denn es ist keine Formatierungsregel. Es ist ein struktureller Unterschied zwischen der Art, wie ein modernes Hauptbuch eine Buchung speichert, und der Art, wie DATEV sie speichert.
Das Zerlegungsproblem
Eine DATEV-Buchung ist ein Paar: ein Konto, ein Gegenkonto, ein Betrag. Eine Buchung im Hauptbuch ist kein Paar. Sie ist eine Menge von Zeilen, die sich ausgleichen, und hat regelmäßig drei oder mehr.
Nehmen Sie einen gewöhnlichen Verkauf mit Zahlungseingang: Soll Bank 1.463,70, Haben Erlöse 1.230,00, Haben Umsatzsteuer 233,70. Drei Zeilen, zwei davon auf derselben Seite. Es gibt kein einzelnes Konto und Gegenkonto, das man schreiben könnte.
Wenn es einen Ankerpunkt gibt
Steht auf einer Seite genau eine Zeile, ist diese Zeile der Anker. Jede Zeile der Gegenseite wird zu einer eigenen Buchung gegen diesen Anker. Das Beispiel oben ergibt zwei Sätze: Erlöse gegen Bank über 1.230,00 und Umsatzsteuer gegen Bank über 233,70. Nichts wird erfunden, und die Summen bleiben unverändert.
Wenn die Buchung wirklich mehrseitig ist
Eine Lohnbuchung hat mehrere Zeilen auf beiden Seiten und keinen Anker. Die verlockende Abkürzung ist, ein Verrechnungskonto zu erfinden und alles darüber zu paaren. Damit steht eine Zahl in Ihren Büchern, der kein Geschäftsvorfall zugrunde liegt, und Ihr Steuerberater wird danach fragen.
Redlich ist, jede Zeile als eigene ausgeglichene Buchung mit leerem Gegenkonto auszugeben und über die Belegnummer zu gruppieren, sodass DATEV sie als einen Vorgang zusammenhält. Die Buchung bleibt unversehrt, und nichts wird erfunden.
Wenn Sie Ihre Bücher nicht in Euro führen
Ein Unternehmen, das in mehreren Währungen handelt, bilanziert trotzdem in Euro. Jede Buchungszeile muss einen Euro-Basisbetrag zum Kurs des Buchungstages tragen, und genau dieser Basisbetrag geht in den Export. Erst beim Export umzurechnen, zum Kurs des Tages, an dem Sie die Schaltfläche drücken, schreibt die Vergangenheit still um.
DATEV veröffentlicht mehrere Formatversionen mit unterschiedlichen Feldsätzen. Werte, Kodierung, Zerlegung und Ausgleich sind versionsunabhängig und entweder richtig oder nicht. Der Feldsatz ist es nicht.
Lassen Sie also einen Testimport in der tatsächlichen DATEV-Version Ihres Steuerberaters laufen und bestätigen Sie den Feldsatz, bevor ein echter Jahresabschluss davon abhängt. Wer Ihnen sagt, dieser Schritt sei entbehrlich, hat ihn nicht gemacht.
Häufige Fragen
Ist ein CSV-Export dasselbe wie DATEV-Unterstützung?
Nein. DATEV Rechnungswesen importiert einen EXTF-Buchungsstapel mit vorgeschriebener Kopfzeile, definiertem Feldsatz, CP1252-Kodierung und Konto-Gegenkonto-Paaren. Eine allgemeine CSV-Datei hat nichts davon, sodass der Import entweder scheitert oder Buchungen erzeugt, die Ihr Steuerberater von Hand korrigieren muss.
Warum sind die Umlaute in meinem jetzigen Export kaputt?
Die Datei ist mit großer Wahrscheinlichkeit UTF-8. DATEV erwartet standardmäßig ANSI (CP1252), sodass jeder Umlaut und jedes ß als zwei falsche Zeichen gelesen wird. Die Datei muss beim Export byteweise als CP1252 kodiert werden. Die Dateiendung zu ändern oder neu zu speichern behebt es nicht.
Kann eine Exportdatei zwei Wirtschaftsjahre umfassen?
Nein. Das Belegdatum enthält nur Tag und Monat, das Jahr stammt aus dem Wirtschaftsjahr der Kopfzeile. Ein Stapel über einen Jahreswechsel hinweg würde die Hälfte seiner Sätze still ins falsche Jahr buchen.
Welchen Kontenrahmen verwendet Softbooq für deutsche Mandanten?
SKR03 und SKR04 sind beide enthalten, zwei von fünf gesetzlichen Kontenrahmen neben PCG für Frankreich, PGC für Spanien und SYSCOHADA. Die Konten im Export sind die Konten, die Ihr Steuerberater erwartet, statt allgemeiner Nummern, die nachträglich zugeordnet werden.
Softbooq erzeugt diese Datei direkt aus gebuchten Journaleinträgen, mit korrekter Kodierung, Vorzeichenlogik, Datumsformat und beiden Zerlegungsfällen. Das Verhalten ist durch automatisierte Tests abgedeckt, die vor jeder Auslieferung laufen.
Zum Finanzmodul