WooCommerce DATEV integration

What a WooCommerce to DATEV integration actually does

WooCommerce knows everything about a sale - the line items, the tax collected, the coupon, the shipping, the refund three days later, the Stripe payout that lands next Tuesday net of fees. 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 reached the bank.

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

Because WooCommerce is a WordPress store you host and extend yourself, its data is richer and messier than a locked-down platform. That is a feature for your shop and a hazard for your books - which is exactly what a proper pipeline is built to absorb.

What data moves

WooCommerce object / event	Becomes in DATEV	Notes
Paid order (processing / completed)	Revenue booking, split by VAT rate	Coded to the correct SKR03 / SKR04 revenue account per tax treatment
Order tax lines	Correct tax key (Steuerschlüssel / BU-Schlüssel)	Domestic 19% / 7%, EU OSS, reverse-charge, third-country export
Coupons & shipping lines	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
Plugin fee lines (e.g. surcharges)	Explicit fee / income booking	Mapped case by case, never lumped into revenue
Gateway payout (Stripe / PayPal / Mollie)	Clearing-account settlement	Pulled from the gateway API, reconciled per provider
Gateway transaction 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 WooCommerce-to-DATEV plugin gets you 80% of the way and leaves the expensive 20% on your desk:

• WooCommerce order status is not a payment state. An order can be “on hold”, “pending”, “failed”, or a draft left by an abandoned checkout. Booking on the wrong status posts phantom revenue. We agree exactly which status transition is the booking event and ignore the rest.
• 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 German 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. WooCommerce stores a tax rate and a rate name, not a DATEV Steuerschlüssel - the mapping is ours to get right, or the advance VAT return (Umsatzsteuervoranmeldung) is wrong.
• The payout is not the revenue. Stripe and PayPal settle net of fees, days later, in a batch spanning many orders. WooCommerce records only the transaction ID, so the payout and fee figures come from the gateway API and post through a clearing account, never as revenue.
• Plugin sprawl. Subscriptions, bundles, gift cards, and checkout surcharges each add their own line types and can each move money. A naive export flattens them into a single total that no longer reconciles.
• Idempotency. Re-run a naive export - or let a WordPress cron fire twice - and you book March twice. The pipeline knows it already sent a given order and never posts it again.

How we build and run it

We treat this as a pipeline, not a batch job. WooCommerce order and refund events are pulled through the REST API (or by webhook), gateway payouts and fees are read from Stripe, PayPal, or Mollie, everything is 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 WooCommerce order 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 changes in the WooCommerce REST API, your payment plugins, and DATEV are our responsibility under contract. WooCommerce and its plugins update on their own release cadence; when a schema shifts, we catch it before your books do. You get a named owner and an SLA, and 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 through one gateway, 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 gateways make reconciliation a monthly chore, when subscription or marketplace plugins complicate every order, or when your tax advisor is charging you to clean up exports that a pipeline should have delivered correctly in the first place.