DATEV-Export

Das Ergebnis eines Exports ist eine Datei, die DATEV einliest. Diese Seite beschreibt, wie sie aufgebaut ist, welche Felder prekonto füllt und an welchen Stellen ein Buchungsstapel in der Praxis scheitert — Kodierung, Feldlängen und ein Belegdatum ohne Jahr.

Was der Export tut — und was nicht

Sie wählen einen Zeitraum. prekonto sammelt alle exportierbaren Buchungssätze dieses Zeitraums — Status auto oder bestaetigt —, prüft sie noch einmal vollständig und schreibt daraus eine EXTF-Datei. Der Vorgang wird als Stapel protokolliert: Dateiname, Anzahl Buchungen, Summe und alles, was beim Schreiben verändert werden musste.

Vor dem Schreiben läuft die strengste Prüfung der ganzen Kette: die Kontolängen des Mandanten, „Gegenkonto steht in der Kontenliste“, „Automatikkonto ⇒ kein BU-Schlüssel“ und die Wirtschaftsjahr-Grenze. Der Grund ist praktisch: Was hier durchgeht, merkt vor dem DATEV-Import niemand mehr — und dann sitzt jemand in der Kanzlei vor einer Fehlermeldung, die er nicht verursacht hat.

Aufbau der Datei

Die Feldpositionen sind positionsgebunden: DATEV liest Feld 10 als Belegdatum, egal was in der Überschriftenzeile steht. Ein Verschieben um eine Spalte macht aus dem Buchungstext einen Skonto-Betrag — deshalb ist die Zahl 125 keine Schätzung, sondern eine harte Prüfung beim Erzeugen.

Aus den Kopfdaten des Mandanten gehen in den Header: Beraternummer (Feld 11), Mandantennummer (12), Wirtschaftsjahresbeginn (13) und Sachkontenlänge (14), dazu der Stapelzeitraum (15 und 16), die Bezeichnung (17) und der Sachkontenrahmen (27).

Das Belegdatum ohne Jahr

In einer EXTF-Datei stehen drei verschiedene Datumsformate, und alle drei sind Fallstricke:

Praktisch heißt das: pro Periode exportieren, typischerweise monatlich, und über den Jahreswechsel hinweg zwei Stapel. Das Wirtschaftsjahr endet ein Jahr nach dem hinterlegten Beginn minus einen Tag — bei einem abweichenden Wirtschaftsjahr also nicht am 31. Dezember.

Welche Felder gefüllt werden

Von den 125 Feldern einer Buchungszeile werden die folgenden gefüllt. Alle anderen bleiben leer — ein leeres Feld ist eine Aussage, ein geratenes nicht.

ISO-8859-1: der Fallstrick Nummer eins

Die Datei ist ISO-8859-1 (Latin-1) kodiert, nicht UTF-8. Sie wird byteweise so ausgeliefert, wie sie erzeugt wurde, und muss so bei DATEV ankommen.

Zeichen, die es in ISO-8859-1 nicht gibt, werden vor dem Schreiben ersetzt — € wird zu EUR, Auslassungspunkte werden zu drei Punkten. Zeilenumbrüche und Tabulatoren in einem Textfeld werden durch Leerzeichen ersetzt, weil sie sonst die CSV-Zeile sprengen würden. Jeder solche Eingriff erscheint im Schreibprotokoll.

Die Reihenfolge ist dabei wichtig und nicht beliebig: erst umschreiben, dann kürzen. Würde man zuerst kürzen, wäre das Feld nach dem Ersetzen von € durch EUR wieder zu lang — und DATEV lehnte die Zeile ab.

Feldlängen und Kürzungen

Was länger ist, wird hart abgeschnitten und im Schreibprotokoll gemeldet. Das ist die richtige Reihenfolge der Übel: Ein gekürzter Buchungstext ist ärgerlich, eine abgelehnte Zeile hält den ganzen Import auf. Bei Belegfeld 1 lohnt ein Blick, wenn Ihre Lieferanten lange Rechnungsnummern verwenden — dieses Feld trägt die offene-Posten-Verwaltung, und eine gekürzte Nummer ordnet später keine Zahlung mehr zu.

Das Schreibprotokoll

Jeder Stapel trägt dauerhaft ein Protokoll der Eingriffe, die beim Schreiben nötig waren — abrufbar auch später und nicht nur direkt nach dem Erzeugen. Ein leeres Protokoll heißt: nichts verändert.

Jeder Eintrag nennt das Feld, die Zeilennummer und — sofern zuordenbar — die betroffene Buchung. Diese Meldungen sind keine Fehler: Die Datei ist gültig und importierbar, der Wert steht nur nicht mehr so darin, wie er geliefert wurde.

Wenn der Export abgelehnt wird

Lieber eine klare Ablehnung als eine Datei, die in der Kanzlei scheitert. Die Gründe:

Wo es zuordenbar ist, nennt die Antwort die auslösende Buchung. Für die Statuscodes dieser Fälle siehe die Fehlerregel der API. Und noch ein Fall, der nichts mit dem Format zu tun hat: Ist ein Stapel protokolliert, die Datei aber nicht mehr in der Ablage, antwortet der Download mit 410 — dann wird der Stapel neu erzeugt.

GoBD und Festschreibung

Die GoBD verlangen unter anderem, dass Buchungen nachvollziehbar entstehen und nachträgliche Änderungen erkennbar bleiben. Für einen Kontierungsvorschlag heißt das dreierlei: Vorschlag, Buchung und Festschreibung bleiben getrennt, jede Änderung ist nachvollziehbar, und die fachliche Entscheidung bleibt bei einem Menschen.

Was prekonto dafür tut:

• Festschreibung ausnahmslos 0. Der erzeugte Stapel ist in DATEV weiterhin korrigierbar. Ein festgeschriebener Stapel ist es nicht, und diese Entscheidung gehört dem Steuerberater — nicht einem Export. Deshalb ist es eine Konstante im Code und keine Einstellung.
• Korrektur und Bestätigung sind unterscheidbar. Am Buchungssatz steht, ob ein Mensch ihn geändert hat oder nur freigegeben.
• Prüfergebnisse bleiben am Satz. Warum ein Satz automatisch durchlief oder in die Prüfung ging, ist hinterher noch nachlesbar — samt der Confidence, die eingeflossen ist.
• Anweisungen werden zum Abschalten deaktiviert. Die Regel bleibt gespeichert und wirkt nicht mehr — so bleibt nachvollziehbar, unter welcher Regel ein alter Buchungssatz entstand. Löschen ist möglich, aber ein eigener Schritt hinter einer Rückfrage.
• Der Stapel ist protokolliert. Zeitraum, Anzahl, Summe, Dateiname und jeder Eingriff beim Schreiben.