DATEV-Buchungsstapel (EXTF): Aufbau, Pflichtfelder und Prüfung

Wer Buchungen aus einer Vorsystem-Software an die Finanzbuchhaltung übergibt, landet in Deutschland fast immer beim DATEV-Format. Der Buchungsstapel ist dabei die Datei, die Buchungssätze transportiert. Dieser Ratgeber erklärt den Aufbau so, wie ihn die öffentliche Formatbeschreibung vorgibt – und die Fehler, auf die wir bei der Entwicklung des Exports in Mandaxa selbst gestoßen sind.

Abgrenzung: Es geht hier um das Dateiformat. Eine Datei im DATEV-Format ist keine Schnittstelle zu DATEV und ersetzt keinen Import in DATEV Rechnungswesen. Den Import führt die Kanzlei mit ihrer eigenen DATEV-Lizenz durch.

Aufbau einer Buchungsstapel-Datei

Eine Buchungsstapel-Datei ist eine Textdatei mit Semikolon als Trennzeichen. Sie besteht aus drei Teilen:

Die Kopfzeile beginnt beim Buchungsstapel mit EXTF;700;21;"Buchungsstapel";13. Das bedeutet: extern erzeugte Datei, Versionsnummer 700, Datenkategorie 21 (Buchungsstapel), Formatname und Formatversion 13. Danach folgen unter anderem Beraternummer, Mandantennummer, Beginn des Wirtschaftsjahres, Sachkontenlänge und der Zeitraum des Stapels.

Wichtig ist die Sachkontenlänge: Sie legt fest, wie viele Stellen ein Sachkonto hat (zum Beispiel vier). Konten, die nicht dazu passen, werden beim Import als Personenkonto oder als unbekannt interpretiert.

Die fünf Mussfelder

Von den 125 Feldern einer Buchungszeile sind laut der maschinenlesbaren Formatdefinition, die das DATEV-Prüfprogramm mitbringt, genau fünf Mussfelder:

Alle anderen Felder – Belegfeld 1 (zum Beispiel die Rechnungsnummer), Buchungstext, Kostenstellen oder der BU-Schlüssel – sind optional. Optional heißt aber nicht bedeutungslos: Ohne Rechnungsnummer im Belegfeld wird die spätere Abstimmung mühsam.

Gutschriften ohne Minuszeichen

Ein häufiger Denkfehler: Eine Gutschrift wird nicht mit negativem Betrag exportiert. Der Umsatz bleibt positiv, die Richtung dreht das Soll/Haben-Kennzeichen. In Mandaxa haben wir das bewusst so modelliert – Vorzeichen laufen ausschließlich über Soll/Haben.

Zeichensatz, Anführungszeichen und Zeilenenden

Drei technische Details verursachen einen großen Teil aller Importprobleme:

1. Zeichensatz: Die Formatbeschreibung nennt ISO-8859-1. Unicode (UTF-8) ist nur mit Byte Order Mark vorgesehen. Ohne passende Kodierung werden aus „Büromaterial“ unleserliche Zeichen.
2. Textfelder in Anführungszeichen: Textfelder stehen in doppelten Anführungszeichen – auch wenn sie leer sind (""). Ein leeres Textfeld ohne Anführungszeichen beanstandet das Prüfprogramm. Genau diesen Fehler hat es bei uns im Feld „WKZ Basis-Umsatz“ gefunden.
3. Zeilenenden: Die Musterdateien von DATEV verwenden CR/LF. Wer auf macOS oder Linux exportiert, sollte das ausdrücklich setzen.

BU-Schlüssel: kein Mussfeld, aber fachlich wichtig

Der BU-Schlüssel (Feld 9) steuert unter anderem die Umsatzsteuer einer Buchung. Zwei Befunde aus der Praxis:

• Länge: Die Formatbeschreibung dokumentiert für Feld 9 einen vierstelligen Ausdruck. DATEVs eigene Musterdatei enthält dort aber ein- bis vierstellige Werte (zum Beispiel "9", "40", "401"), keinen davon mit führender Null. Maßgeblich für die erzeugte Datei ist, was die Prüfroutine akzeptiert – auffüllen sollte man nicht.
• Quelle der Schlüssel: Welche Schlüssel für welchen Steuerfall gelten, veröffentlicht DATEV in einer eigenen Steuerschlüssel-Tabelle je Kontenrahmen. Die Inhalte sind urheberrechtlich geschützt. Eine Software sollte die Zuordnung daher konfigurierbar machen: Die Kanzlei pflegt die Schlüssel aus ihrer eigenen Lizenz, mit Quellenangabe.

Wird kein verifizierter Schlüssel gepflegt, bleibt Feld 9 besser leer, als dass ein geratener Wert exportiert wird.

Vor dem Import prüfen

DATEV stellt auf dem Developer Portal ein Prüfprogramm für das DATEV-Format bereit. Es prüft Kopfzeile und Buchungszeilen gegen die Formatdefinition und meldet Fehler, Warnungen und Hinweise.

Damit eine Prüfung aussagekräftig ist, lohnen sich zwei Kontrollen:

• Positivkontrolle: Die offizielle Musterdatei muss ohne Fehler durchlaufen. Sonst stimmt die Prüfumgebung nicht.
• Negativkontrolle: Eine absichtlich beschädigte Kopie muss beanstandet werden. Sonst sagt „0 Fehler“ nichts aus.

Was das Prüfprogramm nicht prüft: ob Konten, Kreditorennummern und Steuerschlüssel zum Bestand und zu den Automatikkonten des Mandanten passen. Deshalb gehört vor den ersten echten Export ein Testimport in einen Testmandanten.

Vom Beleg zum Stapel: der Ablauf in fünf Schritten

Ein sauberer Buchungsstapel entsteht nicht erst beim Export, sondern schon bei der Belegbearbeitung. Bewährt hat sich diese Reihenfolge:

1. Beleg erfassen und lesen: Der Beleg wird hochgeladen, die Texterkennung liefert Lieferant, Rechnungsnummer, Datum und Beträge. Diese Werte sind ein Vorschlag, keine Tatsache.
2. Kontieren: Konto, Gegenkonto und Steuerfall werden zugeordnet – idealerweise gestützt auf Kontierungsregeln der Kanzlei. Bei mehreren Steuersätzen entstehen mehrere Buchungszeilen für einen Beleg.
3. Prüfen und freigeben: Eine berechtigte Person prüft Summen, Steuerfall und Kontierung und gibt die Buchung frei. Grenzfälle wie Gutschriften oder Reverse Charge brauchen eine bewusste Entscheidung.
4. Stapel bilden und festschreiben: Freigegebene Buchungen eines Zeitraums werden zu einem Stapel zusammengefasst. Mit der Festschreibung ist der Inhalt eingefroren.
5. Datei erzeugen und prüfen: Erst jetzt entsteht die Datei im DATEV-Format. Sie wird mit dem Prüfprogramm geprüft und anschließend in der Buchhaltung importiert.

Festschreibung und Korrekturen

Nach der Festschreibung sollte eine Buchung nicht mehr still geändert oder storniert werden können – sonst verliert die Festschreibung ihren Sinn, und die exportierte Datei passt nicht mehr zum Datenstand. Eine Korrektur läuft dann über einen eigenen Korrekturbeleg im nächsten Stapel. Bei der Entwicklung von Mandaxa haben wir genau diese Lücke im eigenen Abnahmetest gefunden: Ein Storno konnte zunächst eine bereits festgeschriebene Buchung aus dem Stapel lösen. Heute wird das mit einer klaren Fehlermeldung abgelehnt.

Kreditoren als Gegenkonto

Bei Eingangsrechnungen ist das Gegenkonto häufig ein Kreditorenkonto (Personenkonto des Lieferanten). Damit der Import funktioniert, muss die Kreditorennummer zum Nummernkreis und zur Sachkontenlänge des Mandanten passen. Dubletten – derselbe Lieferant unter zwei Nummern – sind eine häufige Ursache für mühsame Abstimmungen. Eine gepflegte Kreditorenliste mit bekannten Schreibvarianten des Lieferantennamens verhindert das.

Typische Importfehler und ihre Ursachen

Prüfen, bevor die Kanzlei prüft

Ein kurzer Eigentest spart die meiste Arbeit: Datei in einem Texteditor öffnen, der die Kodierung anzeigt, die erste Zeile auf EXTF und die Formatversion kontrollieren, die Feldzahl einer Buchungszeile zählen (sie muss zur Überschriftszeile passen) und stichprobenartig Belegdatum, Betrag und Soll/Haben prüfen. Erst danach lohnt der Lauf gegen das Prüfprogramm, und erst nach dessen fehlerfreiem Durchlauf der Testimport.

Wie Mandaxa den Buchungsstapel erzeugt

Mandaxa erzeugt aus freigegebenen, kontierten Belegen einen festgeschriebenen Stapel im DATEV-Format. Dabei gilt:

• Nur freigegebene Buchungen: Speichern, Prüfen und Freigeben sind getrennte menschliche Schritte. Jede Änderung setzt Prüfung und Freigabe zurück.
• Geprüftes Format: Dateien aus synthetischen Testdaten haben das offizielle Prüfprogramm mit 0 Fehlern, 0 Warnungen und 0 Hinweisen bestanden – inklusive Mischsteuersatz, Reverse Charge und Gutschrift.
• Keine mitgelieferten Steuerschlüssel: Die Kanzlei hinterlegt Schlüssel je Steuerfall mit Quelle. Fehlt ein verifizierter Schlüssel, wird der betroffene Stapel gesperrt statt geraten.
• Ehrliche Grenze: Ein Import in DATEV Rechnungswesen mit echten Kanzleidaten ist bisher nicht nachgewiesen. Er hängt vom Bestand der Kanzlei ab und gehört vor dem produktiven Einsatz in einen Testmandanten.

Mehr zum Weg vom Beleg zur Buchung lesen Sie im Beitrag über Kontierungsregeln in der Steuerkanzlei.

Häufige Fragen

Was bedeutet EXTF in einer DATEV-Datei?

EXTF kennzeichnet in der ersten Zeile eine Datei, die von einem externen Programm im DATEV-Format erzeugt wurde. Dahinter folgen unter anderem Versionsnummer, Datenkategorie, Formatname und Formatversion – beim Buchungsstapel zum Beispiel Kategorie 21 und Formatversion 13.

Welche Felder sind im Buchungsstapel Pflicht?

Nach der Formatdefinition des DATEV-Prüfprogramms sind es fünf Mussfelder: Umsatz, Soll/Haben-Kennzeichen, Konto, Gegenkonto und Belegdatum. Der BU-Schlüssel ist kein Mussfeld.

Darf ein Betrag im Buchungsstapel negativ sein?

Nein, die Richtung einer Buchung wird über das Soll/Haben-Kennzeichen (S oder H) ausgedrückt. Der Umsatz steht immer positiv in der Datei – auch bei Gutschriften.

Welcher Zeichensatz gilt für DATEV-Dateien?

Die Formatbeschreibung nennt ISO-8859-1. Unicode ist nur mit Byte Order Mark (BOM) vorgesehen. Falsch kodierte Umlaute sind eine häufige Ursache für unleserliche Buchungstexte.

Ist eine Datei, die das Prüfprogramm besteht, auch fachlich richtig?

Nicht automatisch. Das Prüfprogramm prüft Format und Feldwerte. Ob Konten, Kreditorennummern und Steuerschlüssel zum Kontenrahmen und zu den Automatikkonten Ihres Bestands passen, zeigt erst ein Testimport in einen Testmandanten.

Quellen

1. DATEV Developer Portal – Formatbeschreibung Buchungsstapel (abgerufen am 17.09.2026)

Dieser Beitrag beschreibt Abläufe und allgemeine Fachinformationen. Er ersetzt keine steuerliche oder rechtliche Beratung im Einzelfall.