Identify the data DATEV needs
Shopify provides order, transaction and payout data. An order CSV is not a ready-made DATEV accounting batch and does not automatically replace the associated invoices. Sales, tax, fees, refunds and document references must be reconciled.
The transfer route depends on where you create invoices, match payments and which DATEV applications your adviser uses. A generic “Shopify export” does not adequately describe all these tasks.
One route: accounting software as an intermediate step
Create documents: Transfer Shopify orders to sevdesk or Lexware Office using a suitable integration. The required invoices are created there. Tax cases, line items and references must already be correct at this stage.
Transfer data: Then use the accounting software’s export or transfer procedure agreed with your adviser. This is a common route, but not the only possible architecture.
The decisive point: the quality of the DATEV export depends almost entirely on the quality of stage one. What arrives wrong there exports cleanly wrong afterwards.
DATEV’s service for Shopify Payments
DATEV offers a “Datenservice Zahlungsdienstleister für Shopify”, transferring relevant Shopify Payments data into the DATEV workflow. Check prerequisites, setup and coverage for your account with your adviser.
This payment data service is separate from invoice creation. A complete workflow still requires invoice documents that can be matched to the payments. Other payment providers and marketplaces can need their own data routes.
DATEV Unternehmen Online
Many firms work with DATEV Unternehmen Online — a platform on which client and tax adviser exchange documents and accounting data.
For you that usually means uploading documents or exporting them there from your accounting software, and the firm works on from there. Whether your adviser uses that route or another is worth settling before you choose an export method.
Where it snags in practice
The typical queries from a tax adviser rarely arise at the export itself. They arise before it:
- Payouts booked as revenue. Shopify pays out in batches and deducts fees. The payout amount is not revenue — the gross amount per order belongs in the books, with the fee separately.
- Fees not recorded. Let them disappear inside the payout figure and you lose a business expense and gain a discrepancy nobody can explain.
- Tax cases not separated. Domestic, intra-Community, OSS and non-EU have to remain distinguishable. Land them all on one account and the VAT return becomes manual work.
- No own invoice number. The Shopify order number is not sufficient under tax law. Without an own number range, the trace is missing.
- Refunds not treated as credit notes. A refund is not negative revenue but a document in its own right.
What to settle with your tax adviser first
Talking these points through once at the start saves more time over a financial year than any optimisation of the export.
- Which chart of accounts does the firm use — SKR03 or SKR04?
- Which account do the payment provider fees belong on?
- How should OSS sales be separated?
- How are refunds and chargebacks handled?
- Do you work through DATEV Unternehmen Online or via a file export?
- At what rhythm should the export run — monthly, quarterly?
Where zrapp sits in this chain
zrapp covers stage one: paid Shopify orders become documents in sevdesk or Lexware Office, with the assigned tax case, individual line items, shipping and discounts — and with a reference back to the order.
Stage two is not zrapp's job. The DATEV export then runs from the accounting software itself. That is not a gap but a division of labour: the interface there is maintained, and a second one beside it would be an extra place for things to go wrong.
What zrapp does influence is the quality of what gets exported — tax cases, document references and the separation of invoice amount from payout. Setup is described in connecting Shopify to sevdesk and connecting Shopify to Lexware Office.
