DATEV and WooCommerce integration

What moves between them

The flow runs from WooCommerce into DATEV. ml-connector reads completed WooCommerce orders, the refunds recorded against them, and the customer records behind them, then posts the revenue and tax as bookings into DATEV, either as an EXTF CSV batch to Rechnungswesen or as a DXSO XML booking suggestion to Unternehmen Online. Invoice and receipt PDFs, where the store produces them, are uploaded through the DATEV documents API against the correct client-specific document type. Bookings are one-way write-only in DATEV, so ml-connector never reads posted journal entries back into WooCommerce, and the store remains the source for orders while DATEV remains the source for the ledger.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the WooCommerce side it sends the Consumer Key and Secret over HTTP Basic to the merchant's own store URL, which it accepts as an input since there is no shared host, and falls back to query-string credentials when a host strips the Authorization header. On the DATEV side it runs the OAuth PKCE login once with the tax advisor, then refreshes the 15-minute access token automatically, sending only the client_id on refresh as DATEV requires. WooCommerce order.completed and refund webhooks act as triggers, with each delivery verified against the HMAC-SHA256 signature before processing, and a scheduled poll over the orders endpoint backfills anything a webhook missed, since WooCommerce disables a webhook after five failed deliveries. Each order is turned into an EXTF booking batch with debit and credit accounts, a tax code, the document date, and the order number in Belegfeld 1, then submitted as an async job and polled until it reports complete or failed. Because DATEV cannot return its chart of accounts, the GL accounts, tax codes, and cost centers are mapped up front so every booking line lands on a valid account. WooCommerce has no idempotency header, so ml-connector dedupes on the order id and a BullMQ jobId, and EXTF filenames are generated deterministically so a re-submitted batch is rejected by DATEV as a duplicate rather than double-booked. Every record carries a full audit trail and can be replayed if a DATEV job fails.

A real-world example

A German direct-to-consumer brand with roughly forty staff sells through a WooCommerce store and hands its books to an outside tax advisor on DATEV. Before the integration, a bookkeeper exported the month's orders to a spreadsheet, matched refunds by hand, and typed the totals into a DATEV booking batch, which meant revenue posted late, tax codes were occasionally wrong, and the advisor sent back queries at every close. With DATEV and WooCommerce connected, each completed order and its refunds post into DATEV as a booking within the polling window, allocated to the right revenue and VAT accounts, and the customer records follow. The monthly re-keying is gone and the advisor receives clean batches instead of a spreadsheet.

What you can do

• •Post completed WooCommerce orders into DATEV as EXTF CSV booking batches or DXSO XML booking suggestions.
• •Record WooCommerce refunds as offsetting bookings against the matching DATEV revenue and tax accounts.
• •Upload WooCommerce invoice and receipt PDFs into DATEV Unternehmen Online under the correct client-specific document type.
• •Bridge the WooCommerce Consumer Key with DATEV's interactive OAuth PKCE login and 15-minute token refresh.
• •Trigger on signed WooCommerce webhooks, poll each DATEV import job to completion, and keep a full audit trail with replay.

Questions

Which direction does data move between DATEV and WooCommerce?

The flow is WooCommerce into DATEV. Completed orders, refunds, and customer records move from WooCommerce into DATEV as bookings, submitted as EXTF CSV batches or DXSO XML suggestions. DATEV bookings are write-only and its chart of accounts cannot be read over the API, so ml-connector never writes ledger entries back into WooCommerce.

Does DATEV confirm a posting the moment ml-connector sends it?

No. DATEV processes booking files asynchronously, so ml-connector submits each EXTF or DXSO job, receives a job id, and polls the status endpoint with backoff until it reports complete or failed. DATEV has no webhooks, so polling is the only way to confirm a posting, and the result is recorded in the audit trail.

How are GL accounts and tax codes kept correct when DATEV cannot return them?

DATEV does not expose its full chart of accounts over the API, so the revenue accounts, VAT codes, and any cost centers are mapped in ml-connector up front. Every WooCommerce order line is resolved to a configured DATEV account before the booking is built, so each EXTF or DXSO line lands on a valid account rather than being rejected at processing time.