Warum Sie DATEV-Buchungsstapel besser nicht mit Excel & Co. bearbeiten sollten

Warum Sie DATEV-Buchungsstapel besser nicht mit Excel & Co. bearbeiten sollten

Seit ein paar Monaten kann Kontolino! auch DATEV-Buchungsstapel einlesen. Dieses Feature wird super gut angenommen, schliesslich kann man so ein in einem anderen Buchhaltungsprogramm begonnenes Buchungsjahr mal eben nach Kontolino! übernehmen und vergleichen. Oder man kann Buchungen von einem Faktura-, Reisekosten-, Projektverwaltungsprogramm oder Onlineshop übernehmen.

Der Import is ein super praktisches Feature, das schier endlose Möglichkeiten eröffnet. Im Grunde ist das Buchungsstapel-Format der DATEV auch recht einfach aufgebaut und hat sich deswegen zu einem Quasi-Standard für den Austausch von Buchungen zwischen Programmen etabliert. Als einfache Textdatei, die fast ein bischen wie eine CSV-Datei (CSV= Comma-separated values, also eine einfache Textdatei, in der Werte durch Kommata, Semikola oder Tabulatoren voneinender getrennt sind) aussieht, lädt das Format auch wirklich dazu ein, einfach mal rein zu schauen…

Bitte nur Gucken!

Leider gibt es aber immer wieder mal Probleme mit den Dateien, die nicht eingelesen werden können, weil irgendwas an dem Format nicht stimmt. Und oft gibt es dafür eine ganz einfache Erklärung: der Nutzer hat die DATEV-Datei mal eben in einem Tabellenkalkulationsprogramm bearbeitet. Und das geht in den meisten Fällen gründlich daneben.

Das Problem ist hier, dass Tabellenkalkulationsprogramme wie Excel, LibreOffice Calc oder Numbers versuchen, den Benutzer mit intelligenten Funktionen zu ünterstützen. Eigentlich eine tolle Sache. Aber leider eben manchmal auch ein Fluch. Beispiele gefällig?

Das Belegdatum ist nur der Anfang

In der DATEV-Datei ist das Belegdatum als vierstellige Zahl dargestellt. Die ersten beiden Ziffern stehen dabei für den Tag und die letzten beiden für den Monat. Das Jahr ist in der Datei nicht enthalten, es steckt in den Kopfdaten. So ist also der 19. April im DATEV-Buchungsstapel als ‚1904‘ abgelegt. Das wieder einzulesen, ist super simpel: die ersten zwei Ziffern sind der Tag, die letzten zwei der Monat. Der 2. Mai ist dann eben ‚0205‘.

Und genau hier beginnt das Elend: Excel und Co. schlagen beim Einlesen dieser Daten fatal in den Quark. Wenn man CSV-Dateien mit einer Tabellenkalkulation einliest, versucht diese nämlich, aus dem Text heraus zu orakeln, um was für einen Datentyp es sich hier handeln könnte. Steht in der Zelle also ‚0205‘, sind da nur Ziffern. der Fall ist klar: das muss eine Zahl sein. Und Bumms: die Zahl 0205 mit führenden Nullen ist eine etwas komisch dargestellte 205.

Wenn man nun also die Datei wieder speichert, schreibt das Programm die Zahl 205 in die Datei. Wo vorher ‚0205‘ stand, steht nach dem Speichern ‚205‘. Wenn nun ein Programm versucht, daraus wieder ein Datum zu machen, geht es her und liest die ersten beiden Ziffern und interpietiert  sie als Tagesdatum. In unserem Fall also 20. Dann bleibt nur noch ein Zeichen übrig. Hier kann sich das Programm nun entscheiden, ob es einen Fehler ausgibt und den Import abbricht, oder etwas fataleres zu tun.

Natürlich kann man als importierendes Programm ebenfalls intelligent sein und erstmal schauen, ob hier 3 oder 4 Ziffern stehen. Stehen nur 3 in der Spalte, ist natürlich nur die erste Ziffer der Tag, und die anderen beiden der Monat.

Wo der Spaß dann aber wirklich aufhört

Es gibt aber noch ein viel fataleres Problem: Genau das selbe passiert bei Kontonummern. In fast allen Kontenrahmen gibt es Konten, deren Nummer mit einer führenden Null beginnt. Im SKR 04 sind das zum Beispiel alle Anlagevermögenskonten, also etwa „0420 Technische Anlagen“.

Hier passiert in Excel & Co. exakt das selbe: die Programme lesen ‚0420‘ ein und speichern dann ‚420‘.

Was kann ein importierendes Programm nun tun? Klar, Die DATEV-Kontenrahmen kennen eigentlich keine 3-stelligen Kontonummern (der IKR dagegen schon, z.B. 087). Aber wo fehlt denn nun bei ‚420‘ etwas? Vorne oder hinten? Vermutlich fehlt vorne etwas, aber vielleicht gab es in dem Kontenplan des exportierenden Programms auch ein Konto, das 420 hieß (es könnte ja ein Programm gewesen sein, das 3-stellige Kontonummern durchaus akzeptiert). Ist also nun das Konto ‚0420 Technische Anlagen‘ gemeint oder ein Konto aus der Kontenklasse 4 (Ertragskonten)? Oder was ganz anderes?

Das importierende Programm kann also nur entweder feststellen, dass es kein Konto 420 gibt, oder aber anfangen, zu raten, was mit 420 gemeint sein könnte. Die Chance, dass es hier daneben liegen wird, ist groß.

Noch viel lustiger wird es, wenn es im importierenden Programm ein Konto 420 gibt. Die Chancen, dass hier etwas völlig falsch läuft, ist nahezu 100%. Das Fatale dabei ist, dass der Satz völlig problemlos eingelesen und verbucht wird. Nur eben auf einem vermutlich komplett falschen Konto! Aus einem Zu- oder Abgang von Anlagevermögen wird so ein Umsatzerlös.

Nicht anfassen. So einfach ist das

Die Moral von der Geschicht‘: bitte bearbeiten Sie niemals eine DATEV-Buchungsstapel-Datei mit einem Tabellenkalkulationsprogramm. Sie können gerne in eine solche Datei hinein schauen, aber niemals dürfen Sie diese abspeichern und diese veränderte Datei in ein Buchhaltungsprogramm einlesen. Wenn Sie Glück haben, gibt es beim Import Fehlermeldungen. Wenn Sie aber Pech haben, läuft der Import einfach durch und verbucht völligen Mist.