# WooCommerce DATEV integration

*WooCommerce → DATEV*

**In short:** A WooCommerce to DATEV integration turns each WooCommerce order, refund, and gateway payout into correctly coded bookings your Steuerberater can import as a Buchungsstapel - with the right SKR03 or SKR04 accounts, the correct tax keys for domestic, EU OSS, and third-country sales, and Stripe or PayPal payouts reconciled against a clearing account. Because WooCommerce is a WordPress store you also control, its data can be messy: draft orders, plugin-added fees, and status changes all need handling. Done properly it is a daily, idempotent pipeline, not a one-off export re-keyed at month-end.

## 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.

## Frequently asked questions

### Can I not just export a CSV from WooCommerce and import it into DATEV?

You can, and for a few orders a month it is fine. It breaks down once volume, refunds, and mixed VAT rates appear. WooCommerce order exports have no chart-of-accounts logic, no DATEV tax keys, no split between the sale and the gateway payout, and no guard against importing the same month twice. Each export becomes manual clean-up in Excel before your tax advisor will touch it. The integration moves that logic into a pipeline that runs itself.

### Which DATEV format do you deliver into?

Whichever your tax advisor works with. Most commonly we produce a DATEV-Format booking batch (Buchungsstapel, the EXTF/DTVF structure DATEV Kanzlei-Rechnungswesen imports) and, where the workflow calls for it, deliver documents and booking proposals via the DATEV Rechnungsdatenservice into DATEV Unternehmen online. We agree the target with your Kanzlei up front so the import is clean on their side.

### We use Stripe and PayPal through WooCommerce. How do payouts get handled?

The sale and the money arriving are two different events. We book the revenue when the order is paid and route each gateway payout (Stripe, PayPal, Mollie) through its own clearing account (Geldtransit / Verrechnungskonto), then match gateway fees and the netted payout so the bank booking reconciles to the cent. WooCommerce only stores the transaction reference, so we pull the payout and fee detail from the gateway itself.

### Does it cope with our WooCommerce plugins and custom order statuses?

Yes, and this is where WooCommerce differs from a closed platform. Subscription renewals, plugin-added fees, custom order statuses, and draft or failed orders all show up in the data. We agree which statuses count as a booking event (typically processing and completed, plus refunded) and map plugin fee lines explicitly, so only real, paid transactions become bookings.

### Who operates it after it goes live?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor. If WooCommerce, a payment plugin, or DATEV changes an API, that is our problem to fix, not a surprise your finance team discovers at month-end. You get a named owner, alerting, and an SLA rather than a WordPress cron job somebody has to remember to check.

## Related integrations

- [Amazon ↔ DATEV](https://seamless.engineering/integrations/amazon-datev/): Amazon DATEV integration
- [eBay ↔ DATEV](https://seamless.engineering/integrations/ebay-datev/): eBay DATEV integration
- [JTL ↔ DATEV](https://seamless.engineering/integrations/jtl-datev/): JTL DATEV integration
- [Shopify ↔ DATEV](https://seamless.engineering/integrations/shopify-datev/): Shopify DATEV integration
- [Shopware ↔ DATEV](https://seamless.engineering/integrations/shopware-datev/): Shopware DATEV integration
- [WooCommerce ↔ lexoffice](https://seamless.engineering/integrations/woocommerce-lexoffice/): WooCommerce lexoffice integration

## Browse by system

- [All WooCommerce integrations](https://seamless.engineering/integrations/woocommerce/)
- [All DATEV integrations](https://seamless.engineering/integrations/datev/)
- [DATEV API changelog](https://seamless.engineering/api-changelog/datev/): No breaking changes or deprecations in the last 90 days

## Request a scoping call

Need this integration built and permanently operated? Tell us which systems connect and what data has to move. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact