Buchungsstapel und EXTF: Wie Buchungen in die 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 ein Buchungsstapel ist

Ein Stapel 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. Er kann geprüft, korrigiert und ergänzt werden. Erst mit dem Festschreiben werden die Buchungen unveränderbar, wie es die GoBD verlangen. Danach sind Änderungen nur noch über Stornobuchungen möglich.

Diese Zwischenstufe ist der eigentliche Nutzen: Die Kanzlei behält die Kontrolle, prüft stichprobenartig und schreibt erst dann fest.

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.

Der Kopfsatz enthält unter anderem Formatversion, Berater- und Mandantennummer, Wirtschaftsjahresbeginn, Sachkontenlänge sowie den Zeitraum, den der Stapel abdeckt. Diese Angaben müssen zu den Stammdaten des Mandanten passen. Eine abweichende Sachkontenlänge ist einer der häufigsten Gründe, warum ein Import abbricht oder auf falsche Konten läuft.

Danach folgt eine Zeile je Buchungssatz mit den bekannten Feldern: Umsatz, Soll- und Haben-Kennzeichen, Konto, Gegenkonto, Buchungsschlüssel, Belegdatum, Belegfeld, Buchungstext und, je nach Bedarf, Kostenstellen und weitere Angaben.

Die Kodierung ist keine Nebensache

Die Datei muss in Windows-1252 kodiert sein. UTF-8 führt zu falsch dargestellten Umlauten oder zum Abbruch.

Heikel wird es bei Zeichen, die Windows-1252 nicht kennt. Wer eine Kodierbibliothek naiv einsetzt, bekommt für jedes unbekannte Zeichen ein Fragezeichen in die Datei geschrieben, und zwar stillschweigend. In Namensfeldern ist das ein echtes Problem, weil ein Fragezeichen dort unzulässig ist und die Gegenstelle den Satz zurückweist, ohne das Feld zu nennen.

Der richtige Weg ist Transliteration: Zeichen ohne Entsprechung werden auf ihr nächstliegendes Pendant abgebildet, ć wird zu c, ș zu s, ẞ zu SS. Umlaute, ß und die gängigen Akzente bleiben unverändert, weil Windows-1252 sie kennt.

Das klingt nach einem Detail und ist in der Praxis die Ursache für Fehlermeldungen, die stundenlang niemand einordnen kann.

Die Belegverknüpfung ist der kritische Punkt

Ein Buchungssatz ohne den zugehörigen Beleg erfüllt die Nachvollziehbarkeit nach den GoBD nicht. Ein Prüfer muss vom Buchungssatz zum Beleg und zurück gelangen können.

Hier unterscheiden sich die beiden Übergabewege erheblich:

Wer ein Vorsystem bewertet, sollte deshalb nicht als Erstes nach der Trefferquote der Kontierung fragen, sondern danach, wie der Beleg an den Buchungssatz kommt. Eine perfekte Kontierung, deren Beleg in einem anderen System liegt und dort mühsam gesucht werden muss, hat die Arbeit nur verschoben.

Was im Kopfsatz steht und warum jedes Feld zählt

Der Kopfsatz ist die erste Zeile der Datei und beschreibt, was folgt. Er wird beim Bau eines Vorsystems gern als Formalie behandelt und ist tatsächlich die Stelle, an der die meisten Importe scheitern, weil er den Inhalt gegen die Stammdaten des Mandanten prüfbar macht.

Enthalten sind unter anderem folgende Angaben:

• Kennung und Version. Sie unterscheiden eine extern erzeugte Datei von einer aus DATEV-Programmen und legen fest, nach welcher Fassung der Formatbeschreibung die folgenden Zeilen zu lesen sind.
• Formatkategorie und Formatname. Sie unterscheiden einen Buchungsstapel von einem Stammdatenimport. Dieselbe Dateiendung trägt beides, und ein Stammdatenimport, der als Buchungsstapel deklariert ist, wird nicht etwa abgewiesen, sondern falsch verstanden.
• Berater- und Mandantennummer. Sie bestimmen das Ziel. Ein Zahlendreher hier ist der unangenehmste denkbare Fehler, weil der Import formal gelingt und die Buchungen im falschen Mandanten landen.
• Wirtschaftsjahresbeginn. Er ist bei abweichendem Wirtschaftsjahr entscheidend und wird von Vorsystemen häufig fest auf den Jahresanfang gesetzt.
• Sachkontenlänge. Sie muss der Einstellung des Mandanten entsprechen. Weicht sie ab, werden Konten abgeschnitten oder aufgefüllt, und die Buchungen laufen auf Konten, die niemand vorgesehen hat.
• Zeitraum von und bis. Buchungen außerhalb dieses Fensters werden abgewiesen.
• Bezeichnung des Stapels. Sie erscheint in der Stapelübersicht. Eine sprechende Bezeichnung mit Quelle und Periode erspart später die Frage, woher ein Stapel stammt.
• Kennzeichen zur Festschreibung. Es steuert, ob der Stapel bereits festgeschrieben übergeben wird oder zur Bearbeitung offen bleibt.

Das letzte Kennzeichen ist fachlich das folgenreichste. Wird ein Stapel festgeschrieben übergeben, entfällt die Möglichkeit, ihn vor der Übernahme zu prüfen und zu korrigieren. Für einen automatisch erzeugten Bestand ist das im Regelfall die falsche Einstellung, weil damit genau die Kontrollstufe entfällt, die den Nutzen der Zwischenablage ausmacht.

Die Beraternummer verdient eine organisatorische Bemerkung. Vorsysteme werden häufig einmal eingerichtet und danach für weitere Mandanten dupliziert. Wird dabei die Mandantennummer geändert und die Beraternummer nicht, oder umgekehrt, entsteht ein Fehler, der erst auffällt, wenn jemand einen fremden Buchungsbestand im eigenen Mandanten findet. Eine Plausibilitätsprüfung, die vor dem Export den Namen des Mandanten gegen die Nummer stellt, kostet wenig und verhindert genau diesen Fall.

Die Buchungszeile im Detail

Jede weitere Zeile bildet einen Buchungssatz ab. Fachlich tragend sind wenige Felder, und ihre Eigenheiten sind der Grund für einen erheblichen Teil der Rückfragen.

Vier Punkte daraus sind erklärungsbedürftig.

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 das an dieser Stelle umsetzen, und zwar nicht durch ein Minuszeichen, sondern durch Umkehrung der Kennzeichnung. Wird das übersehen, 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 im Kopfsatz genannten Zeitraum abgeleitet. Das ist der Grund, warum Buchungen aus zwei Kalenderjahren nicht in einen Stapel gehören und warum ein Stapel mit Belegen aus dem Dezember und dem Januar auseinanderzunehmen ist.

Der Buchungstext ist längenbegrenzt und wird bei Überschreitung abgeschnitten. Für automatisch erzeugte Texte lohnt es sich, die wichtigste Information nach vorn zu stellen, also Geschäftspartner und Belegnummer vor eine ausführliche Leistungsbeschreibung.

Das Belegfeld ist der Anknüpfungspunkt für den Offene-Posten-Abgleich. Wird dort etwas anderes eingetragen als die Rechnungsnummer, etwa eine interne laufende Nummer des Vorsystems, ist der Abgleich offener Posten später nicht mehr automatisch möglich, und das fällt erst Monate danach auf.

Festschreibung und was danach möglich ist

Die Festschreibung ist der Punkt, an dem aus einem korrigierbaren Bestand eine Buchführung wird. Sie setzt um, was die Unveränderbarkeit verlangt: Ab diesem Zeitpunkt ist der Inhalt einer Buchung nicht mehr änderbar, sondern nur noch durch eine erkennbare Gegenbuchung zu korrigieren.

Daraus ergeben sich drei praktische Konsequenzen.

Erstens sollte die Festschreibung nicht beliebig hinausgezögert werden. Ein Bestand, der über Monate offen bleibt, ist nicht festgeschrieben und damit nicht unveränderbar, was die Anforderungen der GoBD an die zeitgerechte Ordnung berührt. Üblich ist die Festschreibung im Zusammenhang mit der Umsatzsteuervoranmeldung, weil damit ein sachlicher Anlass und ein fester Rhythmus vorliegen.

Zweitens ist eine Korrektur nach der Festschreibung fachlich eine Stornobuchung und keine Änderung. Das ist der Grund, warum eine automatische Übergabe nicht zweimal denselben Zeitraum liefern darf. Ein Vorsystem, das bei einem erneuten Export alle Buchungen der Periode noch einmal erzeugt, verdoppelt den Bestand, sofern niemand den zweiten Stapel vor der Übernahme prüft.

Drittens braucht jedes Vorsystem einen Merker darüber, was bereits übergeben wurde. Ohne diesen Merker ist der Wiederanlauf nach einem abgebrochenen Export unbestimmt: Es lässt sich nicht mehr feststellen, ob eine Buchung schon in der Buchführung angekommen ist. Bewährt hat sich, den Übergabezeitpunkt und die Stapelbezeichnung am einzelnen Beleg zu speichern, statt nur den Zeitraum als erledigt zu markieren.

Wo der Import in der Praxis scheitert

Fünf Ursachen decken den überwiegenden Teil der Fälle ab:

Die Sachkontenlänge passt nicht. Der Kopfsatz nennt eine andere Länge als die Mandantenstammdaten. Der Import läuft, aber die Konten stimmen nicht.

Der Zeitraum liegt außerhalb des Wirtschaftsjahres. Buchungen mit Datum außerhalb des im Kopfsatz genannten Zeitraums werden abgewiesen.

Konten existieren nicht. Das Vorsystem schlägt ein Konto aus dem Standardkontenrahmen vor, der Mandant führt aber einen individuellen Kontenplan ohne dieses Konto.

Der Buchungsschlüssel passt nicht zum Konto. Automatikkonten steuern den Steuersatz selbst. Wird zusätzlich ein Steuerschlüssel gesetzt, entsteht ein Konflikt.

Zeichen aus der falschen Kodierung. Siehe oben.

Die dritte Ursache ist die häufigste bei neu eingeführten Vorsystemen. Sie lässt sich vermeiden, indem der Kontenplan des Mandanten in das Vorsystem übernommen wird, statt gegen den Standardrahmen zu arbeiten. Ein Vorschlag auf ein nicht existierendes Konto ist kein Vorschlag, sondern ein Fehler mit Verzögerung.

Wer den Stapel vor der Übernahme prüft

Die Zwischenstufe zwischen Import und Festschreibung ist nur dann ein Vorteil, wenn jemand sie nutzt. In der Praxis verfällt sie häufig, weil nicht festgelegt ist, wer prüft und woraufhin.

Bewährt hat sich eine feste, kurze Kontrolle je Stapel, die sich in wenigen Minuten durchführen lässt: Summe und Anzahl gegen das Vorsystem, eine Stichprobe aus den betragsstärksten Sätzen, ein Blick auf die Konten, die im Vorjahresvergleich neu sind, und eine Durchsicht der ausgesteuerten Sätze. Wer diese vier Schritte an eine Person und einen festen Zeitpunkt bindet, hält den Aufwand konstant, unabhängig davon, wie groß der Stapel ist.

Der dritte Schritt ist der ergiebigste. Ein Konto, auf das in der Vergangenheit nie gebucht wurde und das plötzlich auftaucht, ist fast immer das Ergebnis einer fehlerhaften Zuordnung im Vorsystem und nicht eines neuen Sachverhalts. Diese Prüfung findet Fehler, die eine Summenkontrolle nicht sichtbar macht, weil die Summe stimmt und nur die Verteilung falsch ist.

Was das für die Auswahl bedeutet

Drei Fragen an jedes Vorsystem, das Buchungen übergibt:

1. Wird der individuelle Kontenplan des Mandanten gelesen oder nur ein Standardkontenrahmen verwendet?
2. Wie kommt der Beleg an den Buchungssatz, und funktioniert das auch nach dem Festschreiben?
3. Was passiert bei einem fehlerhaften Satz? Bricht der gesamte Stapel ab, oder wird der einzelne Satz zur Korrektur ausgesteuert?

Die dritte Frage entscheidet über den Alltag. Ein Stapel, der bei einem einzigen Fehler vollständig abbricht, kostet bei tausend Buchungen mehr Nerven als die manuelle Erfassung von zehn.

Abgrenzung zu benachbarten Übergabewegen

Der Begriff Schnittstelle wird in Anbietergesprächen für sehr unterschiedliche Dinge verwendet. Vier Wege sind zu unterscheiden, und sie lösen unterschiedliche Aufgaben.

Wichtig ist die Unterscheidung zwischen den beiden mittleren Zeilen. 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, also Belege über den einen Weg und Buchungen über den anderen, führt regelmäßig zu doppelten Beständen, weil derselbe Beleg zweimal ankommt und niemand die Zuordnung herstellt.

Der Stammdatenimport wird häufig unterschätzt. Er ist der Weg, über den der individuelle Kontenplan des Mandanten in ein Vorsystem gelangt oder umgekehrt neu angelegte Kreditoren in die Buchführung. Ohne ihn arbeitet das Vorsystem gegen den Standardkontenrahmen und schlägt Konten vor, die es beim Mandanten nicht gibt. Welche Rolle die Wahl zwischen SKR03 und SKR04 dabei spielt, ist in einem eigenen Beitrag beschrieben.

Ein Testvorgehen vor dem Ausrollen

Bevor ein Vorsystem auf einen ganzen Bestand angewendet wird, lohnt ein Testlauf mit einem bewusst gemischten Stapel. Er dauert unter einer Stunde und ersetzt Wochen an verstreuter Fehlersuche.

1. Ein einzelner unstrittiger Satz. Er zeigt, ob Kopfsatz, Mandantenzuordnung und Sachkontenlänge stimmen.
2. Eine Gutschrift. Sie prüft die Umkehrung von Soll und Haben ohne Vorzeichenwechsel.
3. Ein Beleg mit Umlauten und Sonderzeichen im Buchungstext. Er prüft die Kodierung.
4. Eine Buchung mit langem Buchungstext und langer Belegnummer. Sie prüft die Längenbegrenzungen.
5. Ein Satz auf ein Automatikkonto. Er prüft den Umgang mit dem Buchungsschlüssel.
6. Ein Satz auf ein individuelles Konto des Mandanten. Er prüft, ob der Kontenplan gelesen wird.
7. Ein bewusst fehlerhafter Satz. Er zeigt, ob nur dieser eine Satz ausgesteuert wird oder der gesamte Stapel abbricht.
8. Ein Beleg mit Kostenstelle. Er prüft, ob die Stelle im Mandanten existiert und übernommen wird.

Nach dem Import folgt der zweite Teil, der häufiger vergessen wird als der erste: die Kontrolle im Zielsystem. Zu prüfen sind die Summe des Stapels gegen die Summe im Vorsystem, die Anzahl der Sätze, die Verteilung auf die Steuerkonten und die Frage, ob der Beleg vom Buchungssatz aus erreichbar ist. Stimmen alle vier Punkte, ist die Übergabe belastbar.

Der letzte Punkt ist der einzige, der sich nicht rechnerisch prüfen lässt und deshalb am ehesten unterbleibt. Er ist zugleich der wichtigste, weil er die Frage beantwortet, die eine spätere Prüfung stellt. Wie ein Beleg vom Eingang bis zu diesem Punkt läuft, ist im Beitrag zur digitalen Belegstrecke beschrieben.

Was bei einem Systemwechsel zu beachten ist

Wird das Vorsystem oder die Buchführungssoftware gewechselt, sind drei Punkte zu klären, die alle mit der Übergabe zusammenhängen.

Der Übergabestand muss eindeutig sein. Zum Stichtag ist festzuhalten, welche Belege bereits übergeben wurden und welche nicht. Ohne diese Abgrenzung entstehen entweder Lücken oder Doppelbuchungen, und beides fällt erst bei der Abstimmung der Konten auf.

Offene Posten wandern nicht im Buchungsstapel. Ein Stapel überträgt Buchungen einer Periode, keine Salden. Die Übernahme offener Forderungen und Verbindlichkeiten ist ein eigener Vorgang mit eigener Abstimmung, und sie ist der Punkt, an dem Migrationen typischerweise Zeit kosten.

Der Altbestand bleibt aufbewahrungspflichtig. Die erzeugten Dateien sind nicht der Bestand, sie sind nur der Transportweg. Aufzubewahren sind die Buchungen im Zielsystem und die Belege, und zwar über die gesamte Frist. Was daraus für Archivierung und Anbieterwechsel folgt, steht im Beitrag zu den Aufbewahrungsfristen.

Ein letzter Hinweis zur Fehlersuche im laufenden Betrieb. Wenn ein Import scheitert, lohnt es sich, zuerst die Datei selbst anzusehen, bevor der Anbieter eingeschaltet wird. Zwei Blicke genügen meist: die erste Zeile auf Mandantennummer, Zeitraum und Sachkontenlänge, dann eine Stichprobe aus der Mitte der Datei auf Datumsformat, Trennzeichen und Kodierung. Ein erheblicher Teil der Fälle klärt sich damit in wenigen Minuten, weil die Ursache nicht in der Fachlichkeit liegt, sondern in einer Einstellung, die für einen anderen Mandanten gesetzt wurde.