DATEV data formats: The destination picks the format, not you

DATEV publishes three file formats with their own specifications, and the common assumption about them is wrong in a specific way. They are not three ways to send the same data. Each one belongs to a different destination, and the destination is what selects it.

Read the middle column and the practical consequence appears. Choosing a format is the same decision as choosing a DATEV product, which means it is already made by the time you get to the file: what your product produces decides the target, and the target decides the format.

Which product a payload belongs to is the subject of the comparison between Unternehmen Online and Rechnungswesen, and it answers the format question as a side effect.

It is the file the DATEV Rechnungswesen API takes: a CSV with a fixed file name prefix, EXTF_, and a three-part structure that catches most teams once. Line one is a header carrying the metadata DATEV needs to process the file. Line two is the header line for the user data. The records start on line three.

That first line is the trap, because it looks like a column row and is not one. Reading it as column names gives you DATEV’s processing metadata instead of the fields, and the mistake surfaces after the upload rather than during it.

The posting batch layout is 125 columns wide, and 56 of them are the numbered pairs DATEV reserves for extra information: 40 columns of Zusatzinformation and 16 of Beleginfo. The rest is the booking itself, from Umsatz and Soll/Haben-Kennzeichen through Konto, Gegenkonto and BU-Schlüssel to Festschreibung.

Four encoding rules decide whether a correct booking is read correctly, and all four are easy to get wrong from a language whose defaults differ. Fields are separated by semicolons, every line ends with CR/LF, text fields are wrapped in quotation marks and a quotation mark inside one is doubled.

The number formatting is the one that produces silent damage. The decimal separator is a comma, and thousands separators are generally not used. A locale-formatted amount does not fail loudly here, it books a different number.

The XML interface online is UTF-8 encoded and carries invoice and cash data into the DATEV Unternehmen Online API. Structurally it is the opposite of the CSV route: hierarchical rather than flat, and validated against a schema rather than accepted on trust.

That validation is the trade. It is work up front, because a document has to satisfy DATEV’s schema before it goes anywhere, and it is the reason an XML mistake is cheaper: it fails in your pipeline instead of in your customer’s books.

There is a second layer to it that is easy to miss when reading the requirements, and it is literal: DATEV publishes two sets of interface requirements per data service, one for the service and one for the file format. The Buchungsdatenservice has its own plus one for the DATEV format; the Rechnungsdatenservice 1.0 has its own plus one for the DXSO format. Meeting the first does not mean you have met the second, which is why the format is a subject in this ecosystem rather than a field on a request.

ASCII is the format of DATEV’s Lohnimportdatenservice. An ASCII import file carries payroll master data or current data from an external system to the DATEV data centre, where it is retrieved into DATEV LODAS or DATEV Lohn und Gehalt.

So it sits on a different axis from the other two. CSV and XML deliver bookkeeping data to bookkeeping applications; ASCII delivers payroll data to payroll applications, through its own service and its own scope, hr:files.

For a bookkeeping integration that makes it the format you do not need, and knowing so early saves a detour. It also means a payroll feature is a different project rather than a variant of an accounting one, with a different service, a different destination and its own approval.

Two layers here rather than one, because the honest answer includes a limit on our side: Maesn’s data model covers accounting objects and carries no payroll objects today, so the ASCII route is outside what you can reach through this interface.

Neither file is posted to an endpoint that answers with a result. Both go through a job, and the job has four steps: you create it with the file, you start it, you poll its status and you evaluate what it returns.

The service names follow the format. The XML route runs as a DXSO job on accounting:dxso-jobs, the Rechnungsdatenservice 1.0. The CSV route runs as an EXTF job on accounting:extf-files, the Buchungsdatenservice.

Three consequences follow, and they are design decisions rather than details. There is no immediate answer, so your interface needs a pending state. The outcome can be partial, so a job that succeeded is not the same as every record inside it succeeding. And the failure detail lives in the job result, so your logging has to keep the job reference next to the document it belongs to.

Through Maesn none of that is your loop. You post the common data model, and the file generation, the encoding rules and the job are handled on our side, which is also why asynchronous processing exists as its own subject: the queueing is the product of the systems behind it rather than of our interface.

The decision follows the destination, and the destination follows what your product produces. Read the table by the first column.

The last row is the one the format question usually forgets. Reading does not involve any of the three formats: it runs through the export service, and what it returns is data rather than a file. The guide to the DATEV Datenservice Export Rechnungswesen covers what that means for freshness, and the Rechnungswesen integration guide covers the two connections behind it.

Three things stop being yours:

• The file. Generating a 125-column CSV with the right prefix, separator, line ending, quoting and decimal comma, or a schema-valid XML document, happens here.
• The job. Creating it, starting it, polling it and reading the result is one interface rather than two shapes for two formats.
• The service mapping. Which data service a payload travels through is derived from what you post rather than chosen by you.

Two things do not move:

• What the destination accepts. A booking that violates an accounting rule is refused whatever generated the file, and no abstraction can make a destination accept something it rejects.
• Payroll. The ASCII route serves a different family of DATEV applications and is not part of the accounting object model, so it stays a separate project.