EXTF explained
EXTF is the file format used to import bookings into DATEV. Technically it is a CSV file with semicolons as separators. Practically it is the door through which accounting data from any other program reaches a German tax firm.
The marker at the start of the file says where the file came from: EXTF denotes a file written by an external program, DTVF one that DATEV produced itself. Anyone delivering bookings from outside writes EXTF.
Why the format matters more than it sounds
For a software product touching German accounting, the decisive question is not "how do we get a DATEV partnership," it's "how do the bookings reach the tax firm." EXTF answers that without a contract.
The posting batch is handed over as a file, and the firm imports it like any other batch, using the tool they already use daily. No new program, no access grant, no training, no approval from anyone. For a young product that is the difference between "we must first spend years building a partnership" and "we can deliver tomorrow."
That doesn't make a deeper integration via the DATEV data services uninteresting later. It means it isn't a precondition for starting.
How a file is built
An EXTF file consists of two header lines followed by the posting lines.
Line 1, the metadata. It describes the batch itself, not the bookings:
EXTF;700;21;Buchungsstapel;13;20260728120000000;;;;;0000000;00000;20260101;4;20260701;20260731;Stablewerk Krypto;SW;1;0;0;EUR;...
Position 1 is the marker (EXTF), position 2 the format version (700), position 3 the format category (21 means Buchungsstapel, a posting batch). Further along sit the consultant and client numbers, the start of the financial year, the account number length, the period the batch covers, and the currency.
Line 2, the column names. Amount, debit/credit indicator, currency, account, contra account, tax key, document date, document field, posting text and others.
From line 3, the bookings. One line per posting:
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
That is a real excerpt from a batch Stablewerk produced, with only the wallet address shortened. It shows well what the import expects, and what it does not.
The details that make an import fail
The format is openly documented, but it is not forgiving. Four points bite most often in practice:
The encoding is Windows-1252, not UTF-8. Deliver a UTF-8 file and "Erlöse" arrives as "Erlöse". That's why the posting texts above read "Erloese" without the umlaut: umlauts are workable, but every one of them is a place where a wrongly encoded file shows up later.
The decimal separator is a comma. 11900,00, not 11900.00. A period turns the amount into an error at best, and a silent misreading at worst.
The document date carries no year. 1407 is 14 July. The year comes from the financial year in the file header. Set the header wrong and clean-looking lines post into the wrong period.
Line endings are CRLF, and the posting text is capped. We truncate at 60 characters, which is why a transaction hash always appears abbreviated in the text, with the full hash living in the audit trail rather than the posting text.
What we honestly cannot claim yet
One point we would rather write ourselves than let someone discover: our EXTF writer follows the documented field order, but the metadata header it produces has never been round-tripped through a live DATEV installation. That caveat has sat as a comment in the source since day one, and it isn't decorative.
Concretely: the structure follows the spec, but untested is untested, across the whole file rather than just the header. Writing this very article surfaced a bug in our own export, which we are now fixing: in EXTF one line is already a complete double entry, because DATEV posts the contra side automatically to the account in the Gegenkonto field. Writing each leg of a three-line entry as its own row, each carrying a contra account the way ours did, books the transaction twice. A first real test import at a tax firm is therefore an item on our list, not a ticked box. Anyone starting with us in the Founding Circle does that import together with us, not on a hope.
Frequently asked questions
Does the tax firm need extra software to import the batch? No. Importing is part of the DATEV environment they already use. The batch is read in and reviewed before posting, like any other.
Can an imported batch be reviewed before it's posted? Yes, and that is exactly how it should go. A batch arrives as a batch, gets checked, and only then is committed. An import is not an irreversible posting.
Why a file rather than a direct interface? Because a file works without a contractual relationship and is immediately understood in every firm. A deeper integration through the DATEV data services is intended for a later stage, but it is no substitute for the route everyone already knows today.
Is EXTF tied to a particular chart of accounts? No. The batch contains account numbers; which chart sits behind them follows from the client setup. If a batch doesn't match the firm's chart, the numbers are wrong, not the format.
This post is part of a glossary series covering the terms that come up constantly in crypto bookkeeping: SKR03, GoBD, EXTF, debit and credit, reverse charge. It is not tax advice.