Online retailers generate large volumes of financial data every month. Amazon, Shopify, eBay and other sales channels provide orders, credit notes, fees and settlement data. PayPal, Stripe, Klarna, Mollie and Shopify Payments add payment and payout records. Invoice systems create sales invoices, while supplier invoices, fee documents and bank transactions are often stored in additional systems.

At first glance, the task appears simple: export all records, place them in a CSV file and import the file into DATEV. In practice, the file extension does not determine whether a DATEV export for online retail works. The decisive questions are whether the file follows the DATEV technical specification, whether the accounting logic is correct and whether sales data, payment data, invoices and supporting documents remain clearly linked.

An import can succeed technically and still create poor accounting records. Revenue can be duplicated, net marketplace payouts can be misclassified as sales, open items can remain unpaid, documents can be inaccessible or foreign VAT transactions can be posted to the wrong accounts. Conversely, a correct accounting model can fail at import because a required field is empty, a character is invalid or the header does not match the posting period.

This article explains what a compliant DATEV export for e-commerce must contain, how posting batches, document links and open items work, and how online retailers and tax firms can prevent typical import errors.

What is a DATEV export file (EXTF format)?

DATEV does not process generic CSV files directly. It requires a specific file structure known as the DATEV Format (EXTF format). This file format is defined by DATEV eG and follows strict technical rules regarding headers, column counts, field lengths, number formats and date structures.

A valid DATEV EXTF file consists of three main parts:

Header row (Kopfzeile): Contains metadata such as client number (Berater-/Mandantennummer), financial year start, chart of accounts (SKR03 / SKR04), currency (EUR) and posting period.
Column headers (Spaltenüberschriften): Defines the exact sequence of standard DATEV fields (Umsatz, Soll/Haben-Kennzeichen, Konto, Gegenkonto, BU-Schlüssel, Belegdatum, Belegfeld 1, Belegfeld 2, Buchungstext, etc.).
Data rows (Buchungszeilen): The actual journal entries formatted according to DATEV field validation rules.

If the header is missing, if a column is shifted or if a date is formatted as 2026-07-29 instead of 2907, DATEV will reject the import with an error message.

Core requirements for an e-commerce DATEV export

A high-quality DATEV export for online retail must fulfill both technical and accounting criteria:

1. Correct Chart of Accounts & Tax Keys (BU-Schlüssel)

The file must use the client's active chart of accounts (SKR03, SKR04 or custom firm schema). Every revenue transaction must include the correct DATEV tax key (BU-Schlüssel):

Standard 19% domestic sales (BU 3 / SKR03 8400)
Reduced 7% domestic sales (BU 2 / SKR03 8300)
Intra-Community tax-exempt supplies (BU 11)
OSS tax rates for EU B2C destination countries
Reverse-charge foreign service fees (BU 19 / § 13b UStG)

2. Document Field 1 (Belegfeld 1) for OPOS Matching

In e-commerce, Belegfeld 1 is the primary matching key. It should contain the unique transaction reference, such as:

Amazon Order ID (e.g. 302-1234567-8901234)
Shopify Order Number (e.g. #10542)
Payment Transaction ID (e.g. PayPal / Stripe Transaction ID)

Consistent use of Belegfeld 1 allows DATEV's automated open-item engine (OPOS-Ausgleich) to match customer receivables against provider payouts instantly.

3. Document Links (Beleglink / Digitaler Beleg)

Under GoBD compliance rules, every journal entry should be linked to its digital source document. Advanced DATEV exports include a digital document reference (Beleglink) formatted for DATEV Unternehmen Online or DATEV Belegtransfer. When the tax adviser clicks the transaction in DATEV Kanzlei-Rechnungswesen, the original PDF invoice or settlement report opens immediately.

Open-Item Accounting (OPOS) vs Direct Posting

There are two main approaches to posting e-commerce transactions into DATEV:

Approach A: Direct Posting (Debtor-less)

Orders are posted directly from revenue to the payment provider clearing account.

Entry: Payment Clearing Account (Soll) ➔ Revenue (Haben)
Pros: Simpler, fewer total lines.
Cons: No individual customer debtor tracking; harder to trace unpaid or disputed orders.

Approach B: Open-Item Accounting (OPOS)

Orders are posted against individual or collective debtor accounts, and cleared when payment is confirmed.

Entry 1 (Sale): Customer Debtor / Debtor Clearing (Soll) ➔ Revenue (Haben)
Entry 2 (Payment): Payment Clearing Account (Soll) ➔ Customer Debtor (Haben)
Pros: Fully audit-proof; complete open-item tracking (OPOS-Liste); easy identification of unpaid orders.
Cons: Requires precise Belegfeld 1 matching to prevent open-item backlogs.

For high-volume merchants and tax firms, OPOS accounting with automated Belegfeld 1 matching is the gold standard for GoBD compliance.

Common DATEV Import Errors and How to Fix Them

Tax advisers and accountants frequently encounter import errors when loading third-party e-commerce exports into DATEV. The most common issues include:

Import Error	Root Cause	Solution
"Header record invalid" / "Kopfzeile fehlerhaft"	Missing metadata, wrong client number, or invalid file structure.	Re-generate file using official DATEV EXTF header specification.
"Date format invalid" / "Ungültiges Belegdatum"	Date formatted as `YYYY-MM-DD` or `DD.MM.YYYY`.	DATEV requires `DDMM` (e.g. `2907` for 29 July) within monthly batches.
"Field length exceeded" / "Belegfeld 1 zu lang"	Belegfeld 1 exceeds 36 characters (e.g. long marketplace IDs).	Truncate or map order IDs cleanly within DATEV's 36-character limit.
"Invalid tax key" / "Unzulässiger BU-Schlüssel"	Tax key does not match account type or chart of accounts.	Verify tax key mapping against active SKR03/SKR04 master data.
"Unbalanced posting batch" / "Stapel nicht ausgeglichen"	Total debit does not equal total credit in the batch.	Ensure all clearing entries and fee deductions balance to zero.
"Invalid character" / "Unzulässiges Zeichen in Buchungstext"	Special characters (emojis, tabs, line breaks) in text.	Sanitize booking text fields before exporting.

Step-by-Step: Importing an E-Commerce Posting Batch into DATEV

To import an e-commerce posting batch into DATEV Kanzlei-Rechnungswesen:

Step 1: Open DATEV Kanzlei-Rechnungswesen and select the client and financial year.
Step 2: Navigate to Stapolverarbeitung ➔ Importieren ➔ DATEV-Format.
Step 3: Select the EXTF export file generated by your e-commerce interface (e.g. KudTax).
Step 4: Review the pre-import validation report for any warnings or field errors.
Step 5: Click Importieren and process the batch into the general ledger.
Step 6: Run the automated OPOS clearing process to match receivables with clearing accounts.

How KudTax guarantees error-free DATEV Exports

KudTax eliminates manual CSV editing and DATEV import failures by serving as a dedicated e-commerce DATEV interface:

Strict EXTF Compliance: Generates 100% compliant DATEV EXTF files pre-validated against official DATEV schema rules.
Automated Tax Key Mapping: Maps sales across domestic 19%/7%, EU OSS, intra-Community and reverse-charge transactions to correct DATEV tax keys automatically.
Seamless Document Links: Includes document links so PDF invoices and settlement reports can be viewed directly inside DATEV.
OPOS & Clearing Automation: Clears open items automatically using clean Belegfeld 1 mapping for Amazon, Shopify, PayPal, Stripe, Klarna and others.

Tax advisers and online merchants can test KudTax for free to generate clean, audit-proof DATEV exports for e-commerce.

Official and further sources

This article provides general information for tax professionals and online merchants and does not constitute formal legal or tax advice.

DATEV Export for Online Retailers: Journal Entries, Document Links, Open Items and Import Errors