DATEV-Buchungsstapel (EXTF) selbst erzeugen: Format, Fallstricke, Praxis
Einen DATEV-Buchungsstapel zu erzeugen ist keine große Sache — bis der Import mit „Feldanzahl stimmt nicht“ abbricht, alle Belegdaten im Januar landen oder die Umlaute als Kästchen ankommen. Das EXTF-Format ist unspektakuläres CSV mit einer Handvoll Details, die es nicht verzeiht: positionsgebundene Felder, ein Datum ohne Jahr und ein Zeichensatz aus dem letzten Jahrtausend. Dieser Artikel ist die Referenz, die wir beim Bauen unseres Exports selbst gebraucht hätten.
1. Aufbau der Datei: drei Zeilenarten
Eine EXTF-Buchungsstapeldatei besteht aus genau drei Arten von Zeilen, und sie kommen in dieser Reihenfolge:
- Zeile 1 — Header. 31 Felder. Beschreibt Format, Mandant, Wirtschaftsjahr, Stapelzeitraum und Sachkontenlänge. Ohne korrekten Header weiß DATEV nicht, in welche Buchhaltung die Daten gehören.
- Zeile 2 — Spaltenüberschriften. 125 Felder, alle als Text quotiert. Sie werden von DATEV nicht ausgewertet, müssen aber vorhanden sein und in der Anzahl stimmen.
- Ab Zeile 3 — Buchungszeilen. Je Buchung 125 Felder. Von den 125 sind in der Praxis rund 15 relevant, der Rest bleibt leer — aber die Trennzeichen müssen alle da sein.
Die formalen Kennungen der aktuell gängigen Variante: EXTF, Version 700, Formatkategorie 21 („Buchungsstapel“), Formatversion 13. Die Formatversion bestimmt die Feldanzahl der Buchungszeilen; Version 13 hat 125.
2. Die Header-Zeile Feld für Feld
Nicht alle 31 Header-Felder müssen gefüllt sein. Diese hier sind die, die tatsächlich etwas bewirken:
| Feld | Bezeichnung | Beispiel | Bedeutung |
|---|---|---|---|
| 1 | Kennzeichen | "EXTF" | Text, in Anführungszeichen. „DTVF“ wäre eine DATEV-eigene Datei. |
| 2 | Versionsnummer | 700 | Zahl, unquotiert. |
| 3 | Formatkategorie | 21 | 21 = Buchungsstapel. 16 wäre Debitoren/Kreditoren. |
| 4 | Formatname | "Buchungsstapel" | Muss zur Kategorie passen. |
| 5 | Formatversion | 13 | Bestimmt die Feldanzahl der Buchungszeilen (125). |
| 6 | Erzeugt am | 20260803174512034 | JJJJMMTThhmmssfff, mit Millisekunden. |
| 8 | Herkunft | "PK" | Genau zwei Zeichen, frei wählbares Kürzel des erzeugenden Systems. |
| 9 | Exportiert von | "prekonto" | Max. 25 Zeichen. |
| 11 | Beraternummer | 1234567 | Aus den DATEV-Stammdaten des Mandanten. Falsch = Import in die falsche Buchhaltung. |
| 12 | Mandantennummer | 10042 | Ebenso. |
| 13 | WJ-Beginn | 20260101 | JJJJMMTT. Grenze für den Stapelzeitraum. |
| 14 | Sachkontenlänge | 4 | Bestimmt indirekt die Länge der Personenkonten (eine Stelle mehr). |
| 15 | Datum von | 20260701 | Erster Tag des Stapelzeitraums. |
| 16 | Datum bis | 20260731 | Letzter Tag. Aus diesem Zeitraum leitet DATEV das Jahr der TTMM-Belegdaten ab. |
| 17 | Bezeichnung | "Juli 2026 Eingangsrechnungen" | Stapelname in DATEV, max. 30 Zeichen. |
| 19 | Buchungstyp | 1 | 1 = Finanzbuchführung, 2 = Jahresabschluss. |
| 21 | Festschreibung | 0 | 0 = nicht festgeschrieben, korrigierbar. Für Importe die richtige Wahl. |
| 22 | Währungskennzeichen | "EUR" | Währung der Beträge im Stapel. |
| 27 | Sachkontenrahmen | "03" | „03“ oder „04“ für SKR03/SKR04. Informativ, aber gern korrekt. |
Zwei Felder verdienen besondere Aufmerksamkeit. Beraternummer und Mandantennummer (11 und 12) sind die Adresse des Imports. Sind sie falsch, ist die Datei technisch einwandfrei und landet in der Buchhaltung eines anderen Mandanten. Diese beiden Werte gehören deshalb in die Mandantenstammdaten und nicht in ein Formularfeld, das bei jedem Export neu getippt wird.
Sachkontenlänge (Feld 14) ist die stille Hauptperson: Sie legt fest, wie lang Sachkonten sind — und damit auch, wie lang Personenkonten sind, nämlich eine Stelle mehr. Bei Sachkontenlänge 4 heißt der Kreditor also 70023 und nicht 7002. Eine Buchung mit falscher Kontolänge wird abgewiesen, und die Meldung dazu ist nicht besonders gesprächig.
3. Die Buchungszeile: die Felder, die zählen
125 Felder klingt nach viel Arbeit. Für eine gewöhnliche Eingangsrechnung sind es diese:
| Feld | Bezeichnung | Beispiel | Praxishinweis |
|---|---|---|---|
| 1 | Umsatz | 1428,00 | Brutto, immer positiv, Komma als Dezimaltrennzeichen, kein Tausenderpunkt. Die Richtung steckt in Feld 2. |
| 2 | Soll/Haben-Kennzeichen | "S" | S oder H. Ein Storno wird über die Richtung gebucht, nicht über ein Minuszeichen. |
| 7 | Konto | 70023 | Personenkonto des Kreditors. Länge = Sachkontenlänge + 1. |
| 8 | Gegenkonto | 4930 | Sachkonto, ohne BU-Schlüssel — der hat sein eigenes Feld. |
| 9 | BU-Schlüssel | 9 | 1 bis 4 Ziffern. Leer lassen, wenn das Gegenkonto ein Automatikkonto ist. |
| 10 | Belegdatum | 1507 | TTMM, ohne Jahr. Der bekannteste Fallstrick des Formats. |
| 11 | Belegfeld 1 | "RE-2026-004182" | Rechnungsnummer, OPOS-relevant. Max. 36 Zeichen. |
| 12 | Belegfeld 2 | "20260814" | Häufig Fälligkeit oder ein zweites Ordnungsmerkmal. Max. 12 Zeichen. |
| 14 | Buchungstext | "Buerobedarf Juli" | Max. 60 Zeichen. Erscheint im Kontoauszug und ist oft die einzige Spur zum Beleg. |
| 20 | Beleglink | "BEDI \"…\"" | Verknüpfung zum digitalen Belegbild in DATEV Unternehmen online. |
| 37 | KOST1 | "VERTRIEB" | Kostenstelle. Max. 36 Zeichen. |
| 38 | KOST2 | "PROJ-2026-11" | Kostenträger. |
| 40 | EU-Land u. USt-IdNr. | "ATU12345678" | Nur bei EU-Sachverhalten, dann aber Pflicht. |
| 114 | Festschreibung | 0 | Wie im Header: 0. |
| 118 | Generalumkehr | "" | „1“ kehrt die Buchung um. Für normale Eingangsrechnungen leer. |
Der Umsatz ist immer positiv
Feld 1 enthält den Bruttobetrag ohne Vorzeichen. Die Richtung der Buchung steckt ausschließlich im Soll/Haben-Kennzeichen in Feld 2. Ein negativer Betrag ist kein Storno, sondern ein Formatfehler. Wer eine Gutschrift abbilden will, dreht S und H — nicht das Vorzeichen. Als Dezimaltrennzeichen dient das Komma, ein Tausenderpunkt gehört nicht in die Datei: 1428,00, nicht 1.428,00.
Konto und Gegenkonto sind nicht symmetrisch
Bei einer Eingangsrechnung steht in Feld 7 (Konto) das Personenkonto des Kreditors und in Feld 8 (Gegenkonto) das Sachkonto für den Aufwand. Wer die beiden vertauscht, bucht Bürobedarf gegen den Lieferanten — was in der Summe stimmt und in der Auswertung Unsinn ergibt. Welches Sachkonto das richtige ist und wie man es automatisch findet, behandelt der Artikel zum automatischen Ermitteln des Gegenkontos.
4. Belegdatum TTMM und die Wirtschaftsjahr-Grenze
Eine EXTF-Datei enthält drei verschiedene Datumsformate, und alle drei sind eine eigene Fehlerquelle:
| Wo | Format | Beispiel |
|---|---|---|
| Header: WJ-Beginn, Datum von, Datum bis | JJJJMMTT | 20260701 |
| Header: Erzeugt am | JJJJMMTThhmmssfff | 20260803174512034 |
| Buchungszeile: Belegdatum (Feld 10) | TTMM | 1507 |
Das Belegdatum in der Buchungszeile hat kein Jahr. Das ist kein Datenverlust, sondern Absicht: DATEV leitet das Jahr aus dem Stapelzeitraum im Header ab. Genau daraus folgt die Regel, die viele Exporte übersehen:
Der zweite Stolperstein ist die Nachbuchung. Fällt Ihnen im März eine Rechnung vom Dezember auf, gehört sie in einen eigenen Stapel mit dem Zeitraum des alten Wirtschaftsjahres — nicht in den laufenden. Ein Exportdialog, der nur „letzte 30 Tage“ kennt, macht diese Buchung unmöglich oder falsch.
5. ISO-8859-1, Semikolon, CRLF: das Encoding-Minenfeld
Drei technische Vorgaben, drei Klassen von Problemen:
Zeichensatz ISO-8859-1
Nicht UTF-8. Umlaute und ß funktionieren, das Euro-Zeichen nicht — es existiert in ISO-8859-1 einfach nicht. Ebenso fehlen typografische Anführungszeichen („ und “), der Gedankenstrich (–) und die Auslassungspunkte (…). Und genau diese Zeichen kommen aus jedem Rechnungs-PDF und aus jedem Copy-and-Paste-Buchungstext.
Der verbreitete Fehler ist ein blindes Buffer.from(text, "latin1") oder das Äquivalent in anderen Sprachen: Codepoints über 0xFF werden dabei still auf ihr niedrigstes Byte reduziert. Aus „€“ wird ein Steuerzeichen, aus „–“ ein anderes. Die Datei sieht gültig aus und enthält Müll. Der zweite verbreitete Fehler ist die Verwechslung mit Windows-1252: Dort gibt es Gedankenstrich und Euro-Zeichen an Positionen, die in ISO-8859-1 Steuerzeichen sind. Manche Referenzdateien nutzen das, und dann funktioniert der Import in DATEV — bis eine andere Software die Datei lesen will.
Die belastbare Lösung ist eine bewusste Transliteration vor dem Kürzen auf die Feldlänge: „€“ wird zu „EUR“, „…“ zu drei Punkten, „–“ zum Bindestrich. Die Reihenfolge ist wichtig — wer erst kürzt und dann ersetzt, produziert aus einem 60-Zeichen-Buchungstext einen mit 62 Zeichen, und DATEV lehnt die Zeile ab.
Trennzeichen Semikolon, Texte quotiert
Textfelder stehen in doppelten Anführungszeichen, numerische Felder nicht. Ein Anführungszeichen im Text wird durch Verdoppeln maskiert: "Miete ""Haus Nord""". Ein Semikolon in einem quotierten Feld ist unproblematisch — solange das Feld tatsächlich quotiert ist. Buchungstexte aus Rechnungsdaten enthalten überraschend oft Semikolons.
Zeilenende CRLF
\r\n, nicht \n. Unter Linux erzeugte Dateien haben das gern falsch, und der Import reagiert darauf mit Meldungen, die auf alles Mögliche hindeuten außer auf das Zeilenende.
6. Festschreibung 0 — und warum das keine Bequemlichkeit ist
Das Feld Festschreibung kommt zweimal vor: im Header (Feld 21) und in jeder Buchungszeile (Feld 114). Der Wert 1 bedeutet, dass die Buchungen als festgeschrieben gelten und in DATEV nicht mehr geändert werden können. 0 bedeutet: importiert, aber noch korrigierbar.
Für einen automatisch erzeugten Stapel ist 0 die einzig vertretbare Wahl, und das ist ein GoBD-Argument, kein Komfortargument. Die Unveränderbarkeit von Buchungen ist eine bewusste Entscheidung mit Konsequenzen für die Nachvollziehbarkeit — sie gehört dem Steuerberater beim Abschluss der Periode, nicht dem Export-Skript um drei Uhr nachts. Die saubere Kette lautet: Vorschlag → Review → Stapel (Festschreibung 0) → Festschreibung durch den Menschen. Wer den letzten Schritt automatisiert, verliert die Möglichkeit, einen Fehler zu korrigieren, ohne ihn zu stornieren.
7. Belegfeld 1: die Rechnungsnummer als offener Posten
Belegfeld 1 (Feld 11) ist mehr als eine Notiz. DATEV führt darüber die offene-Posten-Verwaltung: Eine Eingangsrechnung mit Belegfeld 1 RE-2026-004182 wird beim späteren Zahlungsausgleich über genau diesen Wert wiedergefunden. Fehlt er oder ist er uneinheitlich, entsteht ein Posten, der manuell zugeordnet werden muss — und der Automatisierungsgewinn aus der Kontierung ist beim Zahlungsabgleich wieder aufgebraucht.
Daraus folgen drei Konventionen, die sich lohnen:
- Immer die Rechnungsnummer des Lieferanten, nie eine eigene laufende Nummer. Der Lieferant mahnt mit seiner Nummer.
- Unverändert übernehmen, inklusive Bindestrichen und führenden Nullen. „004182“ und „4182“ sind für den Abgleich zwei verschiedene Posten.
- 36 Zeichen sind die Grenze. Längere Nummern — typisch bei Portalen und Plattformen — müssen gekürzt werden. Sinnvoll ist, die hinteren Stellen zu behalten, weil dort der unterscheidende Teil steht, und die Kürzung zu protokollieren statt sie zu verschweigen.
Für Fälligkeiten und ein zweites Ordnungsmerkmal gibt es Belegfeld 2 (Feld 12, 12 Zeichen). Kostenstelle und Kostenträger gehören nach KOST1 und KOST2 (Felder 37 und 38) und nicht in den Buchungstext.
8. Automatikkonten und BU-Schlüssel: entweder oder
Der BU-Schlüssel in Feld 9 steuert die Umsatzsteuerbehandlung der Buchung. Für den Alltag reichen zwei Werte: 9 für 19 % Vorsteuer und 8 für 7 % Vorsteuer. Sachverhalte wie Reverse Charge nach § 13b oder der innergemeinschaftliche Erwerb haben eigene Schlüssel und verlangen zusätzlich Feld 40 („EU-Land u. USt-IdNr.“).
Daneben gibt es Konten, die ihre Steuer selbst mitbringen: Automatikkonten. In SKR03 ist 3400 „Wareneingang 19 % Vorsteuer“ so ein Konto — die Kontenfunktion in DATEV weiß, dass hier 19 % Vorsteuer zu ziehen sind. Trägt man zusätzlich einen BU-Schlüssel ein, treffen zwei Steuerlogiken aufeinander.
Umgekehrt gilt: Wer die Steuerwirkung explizit steuern will, benutzt ein Konto ohne Automatikfunktion und setzt den BU-Schlüssel selbst. Beides ist richtig, nur nicht gleichzeitig.
9. Die häufigsten Importfehler und ihre Ursache
| Symptom | Wahrscheinliche Ursache |
|---|---|
| Import bricht mit Feldanzahl-Meldung ab | Eine Zeile hat nicht 125 Felder. Meist ein nicht verdoppeltes Anführungszeichen oder ein unquotiertes Semikolon im Buchungstext. |
| Alle Belege liegen im falschen Monat oder Jahr | Belegdatum als JJJJMMTT statt TTMM geschrieben, oder Stapelzeitraum im Header passt nicht zu den Belegdaten. |
| Umlaute erscheinen als Kästchen oder Fragezeichen | Datei ist UTF-8 statt ISO-8859-1 kodiert. |
| Steuer wird doppelt oder gar nicht gerechnet | BU-Schlüssel auf einem Automatikkonto gesetzt. |
| Buchungen erscheinen, sind aber nicht mehr änderbar | Festschreibung 1 statt 0. |
| Zahlungsausgleich findet die Rechnung nicht | Belegfeld 1 leer, gekürzt oder mit eigener Nummer statt der Rechnungsnummer gefüllt. |
| „Konto nicht vorhanden“ | Kontolänge passt nicht zur Sachkontenlänge im Header, oder das Konto ist im Kontenrahmen des Mandanten nicht angelegt. |
| Stapel importiert, Summen weichen ab | Betrag mit Tausenderpunkt oder mit Vorzeichen statt über Soll/Haben geschrieben. |
10. Vollständiges Minimalbeispiel
Ein Stapel mit einer Buchung, auf die relevanten Felder reduziert. Die Auslassungspunkte stehen für leere Felder, die in der echten Datei als aufeinanderfolgende Semikolons vorhanden sein müssen:
Zeile 1 (Header, 31 Felder): "EXTF";700;21;"Buchungsstapel";13;20260803174512034;;"PK";"prekonto";; 1234567;10042;20260101;4;20260701;20260731;"Juli 2026 ER";;1;;0;"EUR"; ;;;;"03";;;; Zeile 2 (125 Spaltenüberschriften): "Umsatz (ohne Soll/Haben-Kz)";"Soll/Haben-Kennzeichen";"WKZ Umsatz";…;"Festschreibung";… Zeile 3 (Buchung): 1428,00;"S";"EUR";;;;70023;4930;9;1507;"RE-2026-004182";;; "Buerobedarf Juli";…;0;…
Der Dateiname folgt keiner technischen Vorschrift — DATEV liest die Formatkennung aus dem Inhalt. Eine sprechende Konvention hilft allerdings der Kanzlei beim Zuordnen, etwa EXTF_Juli-2026_20260701_20260731.csv. Was der Name unbedingt aushalten muss: Windows-Dateisysteme, den HTTP-Header Content-Disposition und die DATEV-Importmaske. Umlaute im Dateinamen sind deshalb keine gute Idee; transliterieren statt hoffen.
Selbst bauen oder einbinden
EXTF-Export über die API
Wenn Sie das Format nicht selbst pflegen wollen: prekonto erzeugt den Stapel aus geprüften Buchungssätzen und liefert ihn über POST /api/v1/mandanten/{id}/exports samt Download-Route aus — mit Wirtschaftsjahr-Prüfung, ISO-8859-1-Transliteration, Festschreibung 0 und der Prüfung „Automatikkonto ⇒ kein BU-Schlüssel“ vor dem Schreiben. Für KI-Agenten gibt es dasselbe als MCP-Werkzeug export_extf, und das Ereignis export.created als Webhook.
11. Häufige Fragen zum DATEV-Buchungsstapel
Was ist ein DATEV-Buchungsstapel im EXTF-Format?
Eine CSV-Datei, mit der Buchungssätze in die DATEV-Finanzbuchführung importiert werden. „EXTF“ steht für externe Datei, also eine Datei, die nicht aus einem DATEV-Programm stammt. Der Aufbau ist festgelegt: Zeile 1 ist der Header mit 31 Feldern, Zeile 2 enthält die 125 Spaltenüberschriften, ab Zeile 3 folgt je Buchung eine Zeile mit ebenfalls 125 Feldern. Trennzeichen ist das Semikolon, Zeilenende CRLF, Zeichensatz ISO-8859-1.
Welche Formatversion soll ich verwenden?
Für den Buchungsstapel ist Version 700, Formatkategorie 21 („Buchungsstapel“), Formatversion 13 der derzeit gängige Stand. Die drei Angaben stehen in den Header-Feldern 2, 3 und 5 und müssen zusammenpassen: Die Formatversion legt fest, wie viele Felder eine Buchungszeile hat — bei Version 13 sind es 125.
Warum steht im Belegdatum kein Jahr?
Weil DATEV das Jahr aus dem Stapelzeitraum im Header ableitet. Feld 10 einer Buchungszeile enthält nur TTMM, also „1507“ für den 15. Juli. Daraus folgt unmittelbar die wichtigste Einschränkung des Formats: Ein Stapel darf das Wirtschaftsjahr nicht überschreiten, sonst wäre „0301“ nicht mehr eindeutig. Deshalb wird pro Periode exportiert.
Warum ISO-8859-1 und nicht UTF-8?
Weil die Satzbeschreibung es so vorgibt. In der Praxis heißt das: Umlaute funktionieren, das Euro-Zeichen nicht — es existiert in ISO-8859-1 nicht. Auch typografische Anführungszeichen, Gedankenstriche und Auslassungspunkte fehlen. Wer solche Zeichen ungeprüft durchschreibt, produziert entweder Steuerzeichen in der Datei oder eine unlesbare Zeile. Sinnvoll ist eine Transliteration: „€“ wird zu „EUR“, „…“ zu drei Punkten, der Gedankenstrich zum Bindestrich.
Was bedeutet Festschreibung 0?
Festschreibung 1 markiert einen Stapel als festgeschrieben — er ist in DATEV dann nicht mehr korrigierbar. Für einen automatisch erzeugten Import ist das die falsche Voreinstellung: Wer festschreibt, entscheidet über die Unveränderbarkeit von Buchungen, und diese Entscheidung gehört dem Steuerberater. prekonto schreibt deshalb ausnahmslos 0, im Header-Feld 21 und in Feld 114 jeder Zeile.
Wann darf ich keinen BU-Schlüssel setzen?
Wenn das Gegenkonto ein Automatikkonto ist. Solche Konten steuern die Umsatzsteuer selbst über ihre Kontenfunktion — etwa 3400 „Wareneingang 19 % Vorsteuer“ in SKR03. Trägt man dort zusätzlich einen BU-Schlüssel ein, kollidieren zwei Steuerlogiken, und DATEV weist die Zeile ab oder bucht falsch. Die Regel lautet: Automatikkonto und BU-Schlüssel schließen sich aus.
Muss Belegfeld 1 gefüllt sein?
Formal nicht, praktisch ja. Belegfeld 1 ist das Feld, über das DATEV offene Posten führt (OPOS). Fehlt die Rechnungsnummer, entsteht kein zuordenbarer offener Posten, und der Zahlungsausgleich später funktioniert nicht mehr automatisch. Das Feld nimmt bis zu 36 Zeichen; längere Rechnungsnummern müssen gekürzt werden, was bewusst passieren sollte und nicht durch Abschneiden am Ende.
Der Import bricht mit einer Feldanzahl-Meldung ab. Woran liegt das?
Fast immer daran, dass eine Zeile nicht genau 125 Felder hat. Häufigste Ursache: ein nicht verdoppeltes Anführungszeichen in einem Textfeld, oder ein Semikolon in einem Buchungstext, das nicht quotiert wurde. Ein einziges verrutschtes Trennzeichen verschiebt alle folgenden Felder, und DATEV liest dann zum Beispiel den Buchungstext als Skonto-Betrag.
Wie hoch dürfen die Kontonummern sein?
Das hängt an der Sachkontenlänge des Mandanten, die in Header-Feld 14 steht. Bei vierstelligen Sachkonten sind die Personenkonten fünfstellig, bei fünfstelligen Sachkonten sechsstellig — Personenkonten haben immer eine Stelle mehr. Eine Buchung mit vierstelligem Kreditorenkonto in einem Mandanten mit vierstelligen Sachkonten ist deshalb ein Fehler, auch wenn die Zahl an sich existiert.
Weiterlesen
- Rechnungen automatisch kontieren: was 2026 wirklich funktioniert
Die Matching-Kaskade, die Review-Schwelle und die Auto-Quoten, die im Markt tatsächlich belegt sind: 76 bis 85 Prozent. - Gegenkonto automatisch finden: SKR03/SKR04 mit KI statt Bauchgefühl
Historie als Prior, Kontenliste als Enum, Regeln obendrauf — und warum Amazon der harte Grenzfall bleibt.
Quellen und weiterführende Unterlagen
- DATEV-Dokument 9211385: Satzbeschreibung DATEV-Format, Buchungsstapel (Formatkategorie 21), einschließlich Feldkatalog und Feldlängen
- DATEV-Hilfe zu Kontenfunktionen und Automatikkonten in SKR03 und SKR04
- GoBD, insbesondere zur Unveränderbarkeit von Buchungen und zur Trennung von Erfassung, Buchung und Festschreibung
- ISO/IEC 8859-1 (Latin-1) und die Abgrenzung zu Windows-1252