EXTF einfach erklärt
EXTF ist das Dateiformat, mit dem Buchungen in DATEV importiert werden. Technisch ist es eine CSV-Datei mit Semikolon als Trennzeichen. Praktisch ist es die Tür, durch die Buchhaltungsdaten aus einem beliebigen anderen Programm in die Kanzlei gelangen.
Das Kennzeichen am Dateianfang sagt, woher die Datei stammt: EXTF steht für eine Datei, die ein externes Programm geschrieben hat, DTVF für eine, die DATEV selbst erzeugt hat. Wer Buchungen von außen einliefert, schreibt also EXTF.
Warum das Format wichtiger ist, als es klingt
Für ein Software-Produkt, das deutsche Buchhaltung berührt, ist die entscheidende Frage nicht "wie kommen wir an eine DATEV-Partnerschaft", sondern "wie kommen die Buchungen zur Kanzlei". EXTF beantwortet das ohne Vertrag.
Der Buchungsstapel wird als Datei übergeben, die Kanzlei importiert ihn wie jeden anderen Stapel, mit dem Werkzeug, das sie ohnehin täglich benutzt. Kein neues Programm, kein Zugang, keine Schulung, keine Freigabe von irgendjemandem. Für ein junges Produkt ist das der Unterschied zwischen "wir müssen erst jahrelang eine Partnerschaft aufbauen" und "wir können ab morgen liefern".
Das heißt nicht, dass eine spätere, tiefere Anbindung über die DATEV-Datenservices uninteressant wäre. Es heißt, dass sie kein Startvoraussetzung ist.
Wie eine Datei aufgebaut ist
Eine EXTF-Datei besteht aus zwei Kopfzeilen und danach den Buchungszeilen.
Zeile 1, die Metadaten. Sie beschreibt den Stapel selbst, nicht die Buchungen:
EXTF;700;21;Buchungsstapel;13;20260728120000000;;;;;0000000;00000;20260101;4;20260701;20260731;Stablewerk Krypto;SW;1;0;0;EUR;...
Position 1 ist das Kennzeichen (EXTF), Position 2 die Versionsnummer des Formats (700), Position 3 die Format-Kategorie (21 steht für Buchungsstapel). Weiter hinten stehen Berater- und Mandantennummer, der Beginn des Wirtschaftsjahres, die Sachkontenlänge, der Zeitraum des Stapels und die Währung.
Zeile 2, die Spaltennamen. Umsatz, Soll/Haben-Kennzeichen, Währung, Konto, Gegenkonto, BU-Schlüssel, Belegdatum, Belegfeld, Buchungstext und weitere.
Ab Zeile 3, die Buchungen. Eine Zeile pro Buchungszeile:
11900,00;S;EUR;;;;1370;8400;;1407;BEL-2026-0413;;;Verrechnung Krypto 0x7f3a...c412
10000,00;H;EUR;;;;8400;1370;;1407;BEL-2026-0413;;;Erloese 19 % USt 0x7f3a...c412
1900,00;H;EUR;;;;1776;8400;;1407;BEL-2026-0413;;;Umsatzsteuer 19 % 0x7f3a...c412
Das ist ein echter Ausschnitt aus einem von Stablewerk erzeugten Stapel, nur die Wallet-Adresse ist gekürzt. Man sieht daran gut, was der Import erwartet und was nicht.
Die Details, an denen ein Import scheitert
Das Format ist offen dokumentiert, aber nicht nachsichtig. Vier Punkte fallen in der Praxis am häufigsten auf die Füße:
Die Zeichenkodierung ist Windows-1252, nicht UTF-8. Wer eine UTF-8-Datei einliefert, bekommt aus "Erlöse" ein "Erlöse". Deshalb steht in unseren Buchungstexten oben auch "Erloese" ohne Umlaut: Umlaute sind machbar, aber jeder Umlaut ist eine Stelle, an der eine falsch kodierte Datei später auffällt.
Der Dezimaltrenner ist ein Komma. 11900,00, nicht 11900.00. Ein Punkt macht aus dem Betrag im besten Fall einen Fehler und im schlechteren eine stille Fehlinterpretation.
Das Belegdatum trägt kein Jahr. 1407 ist der 14. Juli. Das Jahr ergibt sich aus dem Wirtschaftsjahr im Kopf der Datei. Wer den Kopf falsch setzt, bucht sauber aussehende Zeilen in die falsche Periode.
Zeilenenden sind CRLF, und der Buchungstext ist begrenzt. Wir kürzen ihn auf 60 Zeichen, weshalb ein Transaktions-Hash im Text immer abgekürzt erscheint und der vollständige Hash im Prüfpfad steht, nicht im Buchungstext.
Was wir hier ehrlicherweise noch nicht behaupten können
Ein Punkt, den wir lieber selbst schreiben, als ihn jemanden entdecken zu lassen: Unser EXTF-Writer folgt der dokumentierten Feldreihenfolge, aber der erzeugte Metadaten-Kopf ist noch nie durch eine echte DATEV-Installation zurückgespielt worden. Der Hinweis steht seit dem ersten Tag als Kommentar im Quelltext, und er steht dort nicht dekorativ.
Das heißt konkret: Die Struktur folgt der Spezifikation, aber ungetestet ist ungetestet, und zwar in der ganzen Datei, nicht nur im Kopf. Beim Schreiben dieses Artikels ist uns genau daran ein Fehler in unserem eigenen Export aufgefallen, den wir gerade beheben: In EXTF ist eine Zeile bereits ein vollständiger Buchungssatz, weil DATEV die Gegenbuchung automatisch auf dem Gegenkonto ausführt. Wer wie wir jede Seite einer dreizeiligen Buchung als eigene Zeile schreibt und dabei jeweils ein Gegenkonto mitgibt, bucht den Vorgang doppelt. Der erste echte Testimport bei einer Kanzlei ist deshalb ein Punkt auf unserer Liste, nicht ein erledigter Haken. Wer mit uns im Gründungskreis startet, macht diesen Import gemeinsam mit uns, nicht auf gut Glück.
Häufige Fragen
Braucht die Kanzlei zusätzliche Software, um den Stapel zu importieren? Nein. Der Import ist Teil der DATEV-Umgebung, die ohnehin genutzt wird. Der Stapel wird eingelesen und vor der Verbuchung geprüft wie jeder andere auch.
Kann ein importierter Stapel geprüft werden, bevor er verbucht wird? Ja, und genau so sollte es laufen. Ein Stapel landet zunächst als Stapel, wird kontrolliert und erst danach festgeschrieben. Ein Import ist keine unwiderrufliche Verbuchung.
Warum nicht direkt über eine Schnittstelle statt über eine Datei? Weil eine Datei ohne Vertragsbeziehung funktioniert und in jeder Kanzlei sofort verstanden wird. Eine tiefere Anbindung über die DATEV-Datenservices ist für einen späteren Ausbau vorgesehen, aber sie ist kein Ersatz für den Weg, den heute alle kennen.
Ist EXTF an einen bestimmten Kontenrahmen gebunden? Nein. Im Stapel stehen Kontonummern; welcher Kontenrahmen dahintersteht, ergibt sich aus dem Mandanten. Passt der Stapel nicht zum Kontenrahmen der Kanzlei, sind die Nummern falsch, nicht das Format.
Dieser Beitrag ist Teil einer Glossar-Reihe zu den Begriffen, die in der Krypto-Buchhaltung ständig vorkommen: SKR03, GoBD, EXTF, Soll und Haben, Reverse Charge. Er ersetzt keine steuerliche Beratung.