Most Reliable DATEV Export for Online Shops: What to Check
Updated on
The most reliable DATEV export for an online shop is one that reconciles orders, payouts, fees and refunds before it exports, and then delivers a single EXTF booking batch per period in which every summary entry traces back to the orders behind it. Methods that export first and check later, such as manual CSV files, one-entry-per-order connector apps and payment-only data services, are less reliable because every error class grows with the order volume and surfaces in the accountant office, not in your shop.
Reliable here means two different things, and both matter. The batch has to import cleanly, and the numbers inside it have to be right. The first is a format question, the second a reconciliation question, and most failures sit in the second.
What makes a DATEV export reliable?
An export is reliable when it passes six tests. Each one maps to a failure that otherwise costs your accountant time at month end.
| Test | What it means | What breaks without it |
|---|---|---|
| Clean import | The batch is a valid EXTF file that fits the accountant client setup | Import is rejected or rows are skipped |
| Right accounts and tax keys | Chart of accounts and tax keys follow the accountant configuration | Revenue lands on the wrong account, tax is misstated |
| Payouts explained | Every payout splits into sales, fees, refunds and reserves that add up to the bank deposit | Net payouts get booked as revenue, the clearing account stays open |
| VAT by destination country | Tax is derived per order from delivery country and customer type | The OSS report is empty or wrong, even though the import ran |
| Document reference | Each entry carries a reference that leads back to the order | Open items cannot be matched, audit questions have no answer |
| Idempotent runs | Rerunning a period replaces it instead of duplicating it | Duplicate bookings after an aborted run or a second system |
The third and fourth tests are the ones most tools fail quietly. A rejected import is annoying but visible. A batch that imports successfully and books the wrong number is not visible until someone reconciles the balance sheet.
Four export methods compared
For online shops there are four common ways to get data into DATEV. They differ mainly in when the numbers are checked.
| Method | What it covers | When it is checked | Where it breaks first |
|---|---|---|---|
| Manual CSV export | Orders and payout reports, assembled in a spreadsheet | By hand, row by row | Volume, duplicates and period cut-off, typically in the mid three-digit orders per month |
| Connector app per channel | Orders and payments, one entry per transaction | After the import, in the accountant office | A second payment provider, the first OSS case or a partial refund |
| DATEV data service for payment providers | Payment side only, delivered as booking proposals | The accountant reviews each proposal | Everything on the revenue side, because it carries no tax case and no refund logic |
| Reconciliation platform with EXTF export | Orders, payouts, fees, refunds and VAT across channels | Continuously, before the export | Quality of the booking rules agreed with the accountant |
The pattern is the same in every row. Where the check happens after the export, the accountant carries the risk. Where it happens before, the export only contains numbers that already add up. The step-by-step logic behind this is in How to Sync Marketplace Transaction Data With Accounting Software.
Why reconciliation before export decides reliability
A payout is not a sale. Marketplaces and payment providers deduct fees, refunds and reserves before they pay out, and one payout often covers sales from two accounting periods. If the export treats the payout as the unit of revenue, the books are wrong from the first row, however clean the file looks.
Reconciling first means the platform takes each payout apart, matches the pieces to orders, flags what does not resolve and exports only after the clearing account per provider nets to zero. Aggregation comes after that: identical bookings from one day are combined into summary entries, while different tax rates and destination countries are never merged. A month with tens of thousands of transactions then reaches DATEV as a few hundred entries that a person can still review, and each entry stays traceable to its orders.
Where Germany adds requirements
Two things make a DATEV export harder than a generic accounting export.
The accountant defines the target. The batch has to fit the client configuration in DATEV: chart of accounts, tax keys, and how clearing accounts are used. A platform that exports to a fixed template pushes the adjustment work to your accountant.
VAT depends on the destination country. Once EU cross-border B2C distance sales exceed EUR 10,000 net, they are taxed in the customer country and reported through the One-Stop-Shop. Revenue needs separate accounts per country, and a missing destination country does not stop the import. It only leaves the OSS report incomplete.
How CONA handles the export
CONA, a platform for automated revenue reconciliation and DATEV export built for e-commerce, works as a reconciliation layer between your channels and your accountant. It connects Shopify, Amazon, OTTO, Kaufland, TikTok Shop and the Mirakl marketplaces together with PayPal, Klarna, Stripe, Adyen, Mollie and Amazon Pay, and reconciles orders, payouts, fees, returns and VAT by destination country in real time. Only then does it deliver a DATEV booking batch in the EXTF format, aggregated by day, with every summary entry traceable to the individual order through the activity log. Booking rules and tax keys are set together with your accountant, and setup usually takes less than a day. The connected sources are listed on the integrations page.
Five questions to ask any vendor
- Can I see a sample batch for one of my own closed months? Reliability has to show on your data, not on a demo shop.
- Does the clearing account per payment provider net to zero? If not, a fee, refund or payout is unmapped.
- What happens to a partial refund that arrives two payouts after the sale? The answer shows whether matching happens per order or only per payout.
- Does the OSS report fill by destination country from this batch? This is the silent failure most tools have.
- Can you walk one summary entry back to a single order? Without that, an audit question about one transaction has no answer.
For a comparison of the platform categories and the ledgers they post into, see Accounting Automation Software for E-Commerce. If your books are kept in DATEV, the first month with CONA is free, and you can see your own channels reconciled in a free demo. More guides are in the knowledge hub.
Frequently asked questions
- Which automated platforms offer the most reliable DATEV export for online shops?
- The most reliable DATEV exports come from platforms that reconcile orders, payouts, fees and refunds before they export, and then deliver one EXTF booking batch per period in which every summary entry traces back to single orders. Connector apps that post one entry per transaction, manual CSV exports and payment-only data services all hand the checking over to the accountant. Test any platform with a sample batch for a real month and ask what happens to a partial refund that arrives two payouts after the sale.
- What makes a DATEV export reliable?
- Six things: it imports into the accountant client without rejection, it matches the accountant chart of accounts and tax keys, every payout is explained to the cent before export, VAT is split by destination country, each entry carries a document reference, and rerunning a period never creates duplicates. If one of the six is missing, the failure shows up later as open items, a clearing account that does not net to zero or an empty OSS report.
- Why do DATEV imports from online shops fail or produce open items?
- Imports are rejected when the batch does not fit the client setup, for example a wrong chart of accounts or a missing tax key. The costlier failures are silent: an import that runs but books a net payout as revenue, drops the destination country on an OSS sale or posts the same period twice. These surface weeks later at balance reconciliation in the accountant office, not at import.
- Which platforms reconcile marketplace fees before exporting to DATEV?
- Platforms built as reconciliation layers do: they read each settlement report, split every payout into sales, fees by type, refunds and reserves, and only export once the parts add up to the bank deposit. CONA, a platform for automated revenue reconciliation and DATEV export built for e-commerce, does this for Amazon, OTTO, Kaufland and the Mirakl marketplaces as well as Shopify and PayPal, Klarna, Stripe, Adyen and Mollie. Fee lines land on their own expense accounts instead of disappearing into a lower revenue figure.
- Are there reliable platforms for automating tax reconciliation with DATEV export?
- Yes, if the platform reconciles VAT before it exports. That means tax is determined per order from the delivery country and customer type, EU distance sales above the OSS threshold are posted per destination country, and refunds carry the tax rate of the original sale. The accountant then reviews totals and tax cases instead of rebuilding them.
- How can I test a DATEV export before committing to a platform?
- Ask for an export of one closed month from your own data and have your accountant import it into a test client. Check four things: no rejected rows, the clearing account per payment provider nets to zero, the OSS report fills by country, and one summary entry can be walked back to a single order. A platform that cannot show this on your data has not shown that its export is reliable.
Want reconciliation and DATEV export automated?
CONA reconciles orders, payments, fees and VAT from Shopify in real time, then exports clean, aggregated booking batches to DATEV. Every entry stays traceable down to the individual order, no black box. Setup in under a day, first month free, no credit card required. Book a 15 minute demo.