Which files a run hands over, in which format, with which number ranges and accounts, and in which order they are read into DATEV. The same details are in the handout the shop creates per tenant.
The files belong to exactly one export run. For every run the shop keeps a list of all files with their SHA-256 checksum and a fingerprint across the booking and master data files; documents without an image are named individually in the run instead of going missing silently.
| File | Content | Format |
|---|---|---|
EXTF_Buchungsstapel_*.csv | The bookings of the period. Above 99,996 booking lines several files are created ("_01von03", "_02von03" …), each a complete batch with its own header and its own totals. | EXTF 700, category 21, format version 13 |
EXTF_DebKred_Stamm_*.csv | Names and addresses for the personal accounts when every customer gets a debtor of their own. Read in first. | category 16, version 5 |
EXTF_Div-Adressen_*.csv | The addresses for the collective debtor with diverse addresses. Read in first. | category 48, version 2 |
DATEV_Belege_*.zip | The document images as PDFs with a document.xml following the DATEV document schema. It contains exactly what the batch points to through its document links; at most 4,999 documents and 450 MB per package. | ZIP for the document transfer |
| Transaction | What the document field holds |
|---|---|
| Invoices, credit notes, cancellations | the document number from the shop in document field 1, cleaned to the characters DATEV accepts, at most 36 |
| Incoming payments, with the payment export | the invoice number of the settled invoice for open-item matching; without an invoice "Z-" before the order number |
| Refunds, with the payment export | the number of the credit note or cancellation document, dated on the refund date |
| Document field 2 | stays empty on purpose, because it has a fixed meaning for open-item clients |
| Document link (field 20) | the reference to the document image in the document ZIP |
These transactions belong in the bookkeeping and are recorded there.
The shop creates the handout, in German, with one click on the Export page, with the real values of the tenant: advisor number, accounts in use, OSS method, number ranges. Ten sections, from the file header to the import into DATEV.
Yes. The test export writes a real, complete file whose header says "Testexport" instead of "Export". It locks nothing and can be repeated as often as needed - the right way for a trial import and a reconciliation.
Only if you want that. The freeze flag is set per tenant and is off by default; it is written into every booking line (field 114), so that DATEV does not freeze the batch on its own.
The export writes several complete files, ending in _01von03, _02von03 and so on, each with its own header and its own reconciliation totals. Each file is imported on its own; together they make up the period.
Through the document packages: one ZIP per package with a document.xml following the DATEV document schema and the PDFs. Imported through the document transfer, the document link in field 20 connects booking and image automatically.
SKR03 and SKR04, with general ledger accounts of four to eight digits. A new tenant starts with SKR03 and four digits.
The shop owner - every point in the handout can be set in the shop. The protocol of each run shows for every document which tax case applied, which date and which account were used, and why a document was skipped.