SoftbooqAccounting handoff / Germany
Your Steuerberater does not want a CSV
They want an EXTF Buchungsstapel: a semicolon-delimited, CP1252-encoded file that DATEV Rechnungswesen imports without an argument. Here is what that file requires, and the five places a generic export gets it wrong.
What the file actually is
- 1A metadata header lineDeclares the format, the version, the consultant and client numbers, and the fiscal period the batch covers. The year of every booking in the file comes from here.
- 2A column caption lineNames each field. DATEV ships several format versions with different field sets, which is why one test import matters more than any vendor claim.
- 3One record per bookingSemicolon-delimited, CRLF line endings. Each record carries an amount, a sign flag, an account, a counter-account, a document date and a reference.
The five things that go wrong
None of these are exotic. Each one is a default that is correct almost everywhere else in software, and wrong here.
DATEV imports EXTF as ANSI, meaning CP1252. Modern runtimes only emit UTF-8, so an export written the obvious way produces a file where every umlaut is mangled. "Gehälter" arrives as "Gehälter".
The fix is to byte-encode manually. ASCII and Latin-1 map one to one, which covers ä ö ü ß Ä Ö Ü. The Euro sign and a handful of CP1252 specials need an explicit mapping, and anything genuinely unencodable becomes "?" rather than corrupting the line.
Amounts use a decimal comma and no thousands separator. 1463.70 is not a number DATEV will read. 1463,70 is.
There are no negative amounts. Every value is positive and the direction is carried separately by a Soll/Haben flag: S for debit, H for credit. An export that writes -1463,70 is describing something DATEV has no concept of.
The Belegdatum in a Buchungsstapel is TTMM: day and month only, four digits. The year is not in the record at all. It comes from the fiscal period in the header line, which is also why a single batch must not span two years.
This is the one a generic export quietly gets wrong, because it is not a formatting rule. It is a structural mismatch between how a modern ledger stores an entry and how DATEV stores a booking.
The decomposition problem
A DATEV booking is a pair: one account, one counter-account, one amount. A general ledger journal entry is not a pair. It is a set of lines that balance, and it routinely has three or more.
Take an ordinary sale settled to the bank: debit Bank 1.463,70, credit Revenue 1.230,00, credit VAT 233,70. Three lines, two of them on the same side. There is no single Konto and Gegenkonto to write.
When there is one anchor
When exactly one line sits on one side, that line is the anchor. Every line on the opposite side becomes its own booking against it. The example above produces two records: Revenue against Bank for 1.230,00 and VAT against Bank for 233,70. Nothing is invented and the totals are unchanged.
When the entry is genuinely multi-sided
A payroll entry has several lines on both sides and no anchor. The tempting shortcut is to invent an interim clearing account and pair everything through it. That puts a number in your books that no business event created, and your advisor will ask about it.
The honest handling is to emit each line as its own balanced booking with an empty Gegenkonto, grouped by the document reference so DATEV keeps them together as one transaction. The entry stays intact and nothing is fabricated.
If you do not keep your books in euro
A business trading in several currencies still files in euro. Each journal line has to carry a euro base amount recorded at the rate on the posting date, and it is that base amount which goes into the export. Converting at export time, using the rate on the day you press the button, silently restates history.
DATEV publishes several format versions with different field sets. Values, encoding, decomposition and balancing are version independent and either correct or not. The field list is not.
So run one test import in your advisor’s actual DATEV version and confirm the field set before a real Jahresabschluss depends on it. Any vendor who tells you this step is unnecessary has not done it.
Common questions
Is a CSV export the same as DATEV support?
No. DATEV Rechnungswesen imports an EXTF Buchungsstapel, which has a required header line, a defined field set, CP1252 encoding and account/counter-account pairs. A generic CSV has none of those, so the import either fails or produces bookings your advisor has to correct by hand.
Why are the umlauts broken in my current export?
The file is almost certainly UTF-8. DATEV expects ANSI (CP1252) by default, so every umlaut and ß is read as two wrong characters. It has to be byte-encoded as CP1252 at export time; changing the file extension or re-saving does not fix it.
Can one export file cover two fiscal years?
No. The Belegdatum in each record is day and month only, and the year comes from the fiscal period declared in the header line. A batch spanning a year boundary would silently book half its records into the wrong year.
Which chart of accounts does Softbooq use for German tenants?
SKR03 and SKR04 are both included, two of five statutory charts alongside PCG for France, PGC for Spain and SYSCOHADA. The accounts in the export are the accounts your advisor expects to see, rather than generic numbers mapped after the fact.
Softbooq exports this file directly from posted journal entries, with the encoding, the sign convention, the date format and both decomposition shapes handled explicitly. The behaviour is covered by automated tests that run before every release.
See the Finance module