Buchungsstapel und EXTF: Wie Buchungen in DATEV gelangen

Wer ein Vorsystem für die Belegverarbeitung einsetzt, trifft früher oder später auf diese Datei. Sie ist der Übergabepunkt, und an ihr entscheidet sich, ob die Automatisierung tatsächlich Arbeit spart.

Was ist ein Buchungsstapel?

Ein Buchungsstapel ist eine Sammlung fertiger Buchungssätze, die als Ganzes in die Finanzbuchführung eingelesen wird. Er ersetzt die Einzelerfassung: Statt tausend Buchungen zu tippen, wird eine Datei importiert. Nach dem Import liegt der Stapel zunächst als nicht festgeschriebener Bestand vor und kann geprüft, korrigiert und ergänzt werden.

Diese Zwischenstufe ist der eigentliche Nutzen: Die Kanzlei behält die Kontrolle und schreibt erst nach der Prüfung fest.

Was ist das EXTF-Format?

EXTF ist eine CSV-Datei mit Semikolon als Trennzeichen und einem festgelegten Kopfsatz. Die Kennung steht für externe Datei, also für Daten aus einem Fremdsystem. Dateien aus DATEV-Programmen selbst tragen die Kennung DTVF. Nach dem Kopfsatz folgt eine Zeile je Buchungssatz.

Die Datei muss in Windows-1252 kodiert sein, UTF-8 führt zu falsch dargestellten Umlauten oder zum Abbruch. Für Zeichen, die Windows-1252 nicht kennt, schreibt eine naiv eingesetzte Kodierbibliothek stillschweigend ein Fragezeichen. In Namensfeldern ist das unzulässig, und die Gegenstelle weist den Satz zurück, ohne das Feld zu nennen.

Der richtige Weg ist Transliteration: ć wird zu c, ș zu s, ẞ zu SS. Umlaute, ß und die gängigen Akzente bleiben unverändert, weil Windows-1252 sie kennt.

Welche Angaben stehen im Kopfsatz?

Der Kopfsatz ist die erste Zeile der Datei und nennt Kennung und Version, Formatkategorie, Berater- und Mandantennummer, Wirtschaftsjahresbeginn, Sachkontenlänge, den abgedeckten Zeitraum, die Bezeichnung des Stapels und das Kennzeichen zur Festschreibung. Er ist die Stelle, an der die meisten Importe scheitern.

• Formatkategorie und Formatname unterscheiden einen Buchungsstapel von einem Stammdatenimport. Dieselbe Dateiendung trägt beides, und ein falsch deklarierter Import wird nicht abgewiesen: Er wird falsch verstanden.
• Berater- und Mandantennummer bestimmen das Ziel. Ein Zahlendreher ist der unangenehmste Fehler, weil der Import gelingt und die Buchungen im falschen Mandanten landen.
• Wirtschaftsjahresbeginn wird von Vorsystemen häufig fest auf den Jahresanfang gesetzt, was bei abweichendem Wirtschaftsjahr falsch ist.
• Sachkontenlänge muss der Einstellung des Mandanten entsprechen, sonst werden Konten abgeschnitten oder aufgefüllt.
• Kennzeichen zur Festschreibung ist bei automatisch erzeugten Beständen meist falsch gesetzt: Festgeschrieben übergeben entfällt die Kontrollstufe.

Vorsysteme werden häufig einmal eingerichtet und danach für weitere Mandanten dupliziert. Wird dabei die Mandantennummer geändert und die Beraternummer nicht, findet jemand irgendwann einen fremden Buchungsbestand im eigenen Mandanten. Eine Prüfung, die vor dem Export den Namen gegen die Nummer stellt, verhindert das.

Welche Felder trägt eine Buchungszeile?

Fachlich tragend sind acht Felder: Umsatz, Soll-Haben-Kennzeichen, Konto und Gegenkonto, Buchungsschlüssel, Belegdatum, Belegfeld, Buchungstext und je nach Bedarf Kostenstellen. Ihre Eigenheiten verursachen einen erheblichen Teil der Rückfragen nach einem Import.

Der Betrag wird ohne Vorzeichen übergeben, die Richtung ergibt sich allein aus dem Soll-Haben-Kennzeichen. Vorsysteme, die intern mit negativen Beträgen für Gutschriften arbeiten, müssen stattdessen die Kennzeichnung umkehren. Sonst entstehen Buchungen mit richtigem Betrag und falscher Richtung, die in der Summe nicht auffallen.

Das Belegdatum trägt kein vollständiges Jahr, es wird aus dem Zeitraum im Kopfsatz abgeleitet, weshalb Buchungen aus zwei Kalenderjahren nicht in einen Stapel gehören. Das Belegfeld ist der Anknüpfungspunkt für den Abgleich offener Posten: Steht dort eine interne laufende Nummer statt der Rechnungsnummer, ist der Abgleich später nicht mehr automatisch möglich.

Wie kommt der Beleg an den Buchungssatz?

Ein Buchungssatz ohne den zugehörigen Beleg erfüllt die Nachvollziehbarkeit nach den GoBD nicht, ein Prüfer muss vom Satz zum Beleg und zurück gelangen können. Beim EXTF-Import ist diese Verknüpfung gesondert herzustellen, beim Buchungsdatenservice wird sie automatisch gesetzt.

Wer ein Vorsystem bewertet, fragt deshalb zuerst danach, wie der Beleg an den Buchungssatz kommt, und nicht nach der Trefferquote der Kontierung. Eine perfekte Kontierung, deren Beleg anderswo gesucht werden muss, hat die Arbeit nur verschoben. Wie ein Beleg bis zu diesem Punkt läuft, steht im Beitrag zur digitalen Belegstrecke.

Was bedeutet die Festschreibung?

Mit der Festschreibung wird aus einem korrigierbaren Bestand eine Buchführung. Ab diesem Zeitpunkt lässt sich der Inhalt einer Buchung nur noch durch eine erkennbare Gegenbuchung korrigieren, nicht mehr direkt ändern, wie es die Unveränderbarkeit nach den GoBD verlangt.

Daraus folgen drei Konsequenzen. Üblich ist die Festschreibung im Zusammenhang mit der Umsatzsteuervoranmeldung. Eine automatische Übergabe darf nicht zweimal denselben Zeitraum liefern, sonst verdoppelt sich der Bestand. Und jedes Vorsystem braucht einen Merker über das Übergebene, am besten am einzelnen Beleg statt am Zeitraum.

Warum scheitern Importe in der Praxis?

Fünf Ursachen decken den überwiegenden Teil der Fälle ab: eine Sachkontenlänge, die nicht zu den Mandantenstammdaten passt, Buchungen außerhalb des im Kopfsatz genannten Zeitraums, Konten, die im Mandanten gar nicht existieren, ein Buchungsschlüssel, der nicht zum Konto passt, und Zeichen aus der falschen Kodierung.

Der Konflikt beim Buchungsschlüssel entsteht, weil Automatikkonten den Steuersatz selbst steuern. Die häufigste Ursache bei neuen Vorsystemen ist aber die dritte: Vorgeschlagen wird ein Konto aus dem Standardkontenrahmen, der Mandant führt einen individuellen Kontenplan. Ein Vorschlag auf ein nicht existierendes Konto ist ein Fehler mit Verzögerung.

Wie testet man die Übergabe vor dem Ausrollen?

Vor dem Einsatz auf einem ganzen Bestand lohnt ein Testlauf mit einem bewusst gemischten Stapel aus acht Sätzen, von denen jeder genau eine Eigenschaft der Schnittstelle prüft. Der Lauf dauert unter einer Stunde und ersetzt Wochen verstreuter Fehlersuche.

1. Ein unstrittiger Einzelsatz. Prüft Kopfsatz, Mandantenzuordnung und Sachkontenlänge.
2. Eine Gutschrift. Prüft die Umkehrung von Soll und Haben ohne Vorzeichenwechsel.
3. Umlaute und Sonderzeichen im Buchungstext. Prüfen die Kodierung.
4. Langer Buchungstext, lange Belegnummer. Prüfen die Längenbegrenzungen.
5. Ein Satz auf ein Automatikkonto. Prüft den Umgang mit dem Buchungsschlüssel.
6. Ein Satz auf ein individuelles Konto des Mandanten. Prüft, ob der Kontenplan gelesen wird.
7. Ein bewusst fehlerhafter Satz. Zeigt, ob nur dieser Satz ausgesteuert wird oder der Stapel abbricht.
8. Ein Beleg mit Kostenstelle. Prüft, ob die Stelle im Mandanten existiert.

Im laufenden Betrieb genügt danach eine kurze Kontrolle je Stapel: Summe und Anzahl gegen das Vorsystem, eine Stichprobe aus den betragsstärksten Sätzen, ein Blick auf die neuen Konten und die Frage, ob der Beleg vom Buchungssatz aus erreichbar ist. Der dritte Schritt ist der ergiebigste, weil ein plötzlich auftauchendes Konto fast immer eine fehlerhafte Zuordnung ist.

Welche Übergabewege gibt es neben dem Buchungsstapel?

Vier Wege sind zu unterscheiden, und sie lösen unterschiedliche Aufgaben: der Buchungsstapel als Datei, der Stammdatenimport, der Belegtransfer und der Datenservice über eine Schnittstelle. Der Begriff Schnittstelle wird in Anbietergesprächen für alle vier verwendet, obwohl nur der letzte Weg Buchungen und Belege zusammen überträgt.

Ein Belegtransfer übergibt den Beleg samt erkannter Daten, die Kontierung entsteht danach in der Buchführung. Ein Buchungsstapel übergibt die fertige Buchung, der Beleg muss separat dorthin gelangen. Beides zu kombinieren führt zu doppelten Beständen, weil derselbe Beleg zweimal ankommt.

Am häufigsten unterschätzt wird der Stammdatenimport: Über ihn gelangt der Kontenplan des Mandanten in das Vorsystem, ohne ihn arbeitet es gegen den Standardkontenrahmen. Welche Rolle die Wahl zwischen SKR03 und SKR04 spielt, steht in einem eigenen Beitrag.

Was ist bei einem Systemwechsel zu beachten?

Beim Wechsel des Vorsystems oder der Buchführungssoftware sind drei Punkte zu klären: Der Übergabestand muss zum Stichtag eindeutig sein, offene Posten wandern nicht im Buchungsstapel mit, und der Altbestand bleibt aufbewahrungspflichtig. Versäumnisse fallen erst bei der Abstimmung der Konten auf.

Ohne eindeutigen Übergabestand entstehen Lücken oder Doppelbuchungen. Die Übernahme offener Forderungen und Verbindlichkeiten ist ein eigener Vorgang mit eigener Abstimmung, weil ein Stapel Buchungen einer Periode überträgt und keine Salden. Und die erzeugten Dateien sind nur der Transportweg, nicht der Bestand: Aufzubewahren sind die Buchungen im Zielsystem und die Belege über die gesamte Frist, siehe Aufbewahrungsfristen.

Scheitert ein Import im laufenden Betrieb, lohnt zuerst ein Blick in die Datei: die erste Zeile auf Mandantennummer, Zeitraum und Sachkontenlänge, dann eine Stichprobe aus der Mitte auf Datumsformat, Trennzeichen und Kodierung. Die Ursache ist meist eine Einstellung, die für einen anderen Mandanten gesetzt wurde.