Shopify DATEV integration

What a Shopify to DATEV integration actually does

Shopify knows everything about a sale - the line items, the tax collected, the discount, the shipping, the refund three days later, the payout from Shopify Payments next Tuesday. DATEV, and the tax advisor working inside it, needs all of that expressed as bookings: the right account, the right tax key, the right posting date, split correctly between the revenue and the money that actually landed in the bank.

The gap between those two worlds is where the work lives. A Shopify to DATEV integration closes it automatically: it reads each relevant event from Shopify, applies your accounting logic, and hands DATEV a clean booking batch your Kanzlei can import without touching a spreadsheet.

What data moves

Shopify event	Becomes in DATEV	Notes
Paid order	Revenue booking, split by VAT rate	Coded to the correct SKR03 / SKR04 revenue account per tax treatment
Tax lines	Correct tax key (Steuerschlüssel / BU-Schlüssel)	Domestic 19% / 7%, EU OSS, reverse-charge, third-country export
Discounts & shipping	Separate booking lines	Shipping is itself taxable and needs its own account
Refund / partial refund	Reversing booking	Same accounts and tax keys as the original, dated to the refund
Payment-provider payout	Clearing-account settlement	Shopify Payments / PayPal / Klarna each reconciled separately
Provider fees	Expense booking	Netted payout matched to gross sales plus fees

The exact account numbers, tax keys, and clearing accounts are agreed once with your tax advisor and encoded in the pipeline. After that, nobody maps them again by hand.

The details that break naive exports

A CSV export or a generic connector app gets you 80% of the way and leaves the expensive 20% on your desk:

• Chart of accounts. SKR03 and SKR04 number the same concept differently. Revenue, shipping, and each VAT treatment need the correct account for your Kontenrahmen, not a plugin’s default.
• Tax keys. A 19% domestic sale, a 7% reduced-rate item, an EU distance sale under OSS, and an export to Switzerland are four different tax keys. Get one wrong and the advance VAT return (Umsatzsteuervoranmeldung) is wrong.
• The payout is not the revenue. Shopify Payments settles net of fees, days later, in a batch that spans many orders. Booking the payout as revenue double-counts nothing and reconciles to nothing. The sale and the settlement must be separate bookings joined by a clearing account.
• Refunds and chargebacks. A partial refund has to reverse the exact accounts and tax keys of the original order, on the refund’s date, not the sale’s.
• Idempotency. Re-run a naive export and you book March twice. A pipeline has to know it already sent a given order and never post it again.

How we build and run it

We treat this as a pipeline, not a batch job. Shopify order, refund, and payout events are pulled on a schedule (or by webhook), validated, transformed into your agreed DATEV coding, and written out as a DATEV-Format booking batch - or delivered through the DATEV Rechnungsdatenservice into DATEV Unternehmen online where that suits your Kanzlei’s workflow.

The pipeline is idempotent: every Shopify event carries a stable identifier, so a retry or a re-run never produces a duplicate booking. It runs on cloud-native, fully EU-hosted AWS infrastructure, so order and customer data never leaves the EU - which keeps the DPA / AVV with your tax advisor and your GDPR obligations clean.

And then we keep it running. Monitoring, alerting, incident response, and - critically - watching for Shopify and DATEV API changes are our responsibility under contract. The month-end close stops depending on someone remembering to run an export.

When this integration is worth building

If you process a handful of orders a month at a single VAT rate, a manual export is genuinely fine and we will tell you so. The integration earns its place when volume climbs, when you sell across EU borders under OSS, when refunds and multiple payment providers make reconciliation a monthly chore, or when your tax advisor is charging you to clean up exports that a pipeline should have delivered correctly in the first place.