Shopware DATEV integration

What a Shopware to DATEV integration actually does

Shopware knows everything about a sale - the line items, the tax per position, the discount, the shipping cost, the invoice document it generated, the credit note two days later, the Stripe settlement that lands next week net of fees. DATEV, and the tax advisor working inside it, needs all of that expressed as bookings: the right revenue account, the right tax key, the right posting date, split correctly between the revenue and the money that actually reaches the bank.

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

What data moves

Shopware object / event	Becomes in DATEV	Notes
Paid order (order)	Revenue booking, split by tax rate	Coded to the correct SKR03 / SKR04 revenue account per tax treatment and sales channel
Invoice document (document, type invoice)	Booking keyed to the Belegnummer	The sequential invoice number lands in the DATEV Belegfeld for the audit trail
Order line-item tax (calculatedTaxes)	Correct tax key (Steuerschlüssel / BU-Schlüssel)	Domestic 19% / 7%, EU OSS, reverse-charge, third-country export
Shipping & discounts	Separate booking lines	Shipping is itself taxable and needs its own account
Credit note / cancellation (document, type credit_note / storno)	Reversing booking	Same accounts and tax keys as the original invoice, dated to the credit note
Payment transaction (order_transaction)	Clearing-account settlement	PayPal / Stripe / Klarna / Mollie each reconciled separately per method
Provider fees	Expense booking	Netted settlement matched to gross sales plus fees
Customer (customer, optional)	Debtor master record	Only where you keep per-customer debtor accounts rather than a collective account

The exact account numbers, tax keys, clearing accounts, and per-channel mapping 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 plugin 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 tax treatment need the correct account for your Kontenrahmen, not a plugin default that assumes SKR03.
• Tax keys, not tax rates. 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 even where two share a percentage. Shopware stores the calculated tax and the customer country; the correct BU-Schlüssel has to be derived from both, not copied from the rate.
• Order versus invoice document. A Shopware order can be edited after the fact, but the invoice document it generated is the audit-relevant record with the sequential Belegnummer. Book the wrong one and your number range has gaps your tax advisor will flag.
• The settlement is not the revenue. Stripe or PayPal settles net of fees, days later, in a batch that spans many orders. Booking the payout as revenue reconciles to nothing. The sale and the settlement must be separate bookings joined by a clearing account per payment method.
• Credit notes and cancellations. A partial credit note has to reverse the exact accounts and tax keys of the original invoice, on the credit note date, not the sale date. Shopware treats cancellation and credit note as distinct document types, and each needs its own booking logic.
• Multi-channel and currency. Shopware runs multiple sales channels and currencies from one instance. Each channel may post to its own revenue account or cost centre, and foreign-currency orders need a defined conversion and rounding rule so the batch balances.
• Idempotency. Re-run a naive export and you book the period twice. A pipeline has to know it already sent a given document and never post it again.

How we build and run it

We treat this as a pipeline, not a batch job. Shopware order, document, and payment-transaction events are pulled from the Admin API on a schedule (or by webhook), validated, transformed into your agreed DATEV coding, and written out as a DATEV-Format booking batch (Buchungsstapel) - or delivered through the DATEV Rechnungsdatenservice into DATEV Unternehmen online where that suits your Kanzlei workflow.

The pipeline is idempotent: every Shopware document carries a stable identifier and number, 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 Shopware Admin API changes and DATEV format updates are our responsibility under contract. The month-end close stops depending on someone remembering to run an export or on a plugin surviving the next Shopware upgrade.

When this integration is worth building

If you process a handful of orders a month at a single tax rate through one sales channel, a manual export or a stock plugin 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 credit notes and multiple payment providers make reconciliation a monthly chore, when you run several sales channels or currencies from one Shopware instance, or when your tax advisor is charging you to clean up exports that a pipeline should have delivered correctly in the first place.