What connects to WooCommerce

WooCommerce turns a WordPress site into a shop, which makes it a common starting point for smaller merchants. The data it produces is complete but loosely governed: orders move through statuses, SKUs are whatever someone typed, and every plugin for subscriptions, bundles, or gift cards adds data of its own.

Behind the shop sit the systems that need that data in a stricter shape. An ERP needs sales documents against valid customer and material master data, and sends stock, prices, and delivery status back, as in WooCommerce to SAP. Accounting needs revenue, refunds, and gateway fees as bookings, either as a DATEV Buchungsstapel for the Kanzlei, as in WooCommerce to DATEV, or as invoices and vouchers in an accounting tool, as in WooCommerce to lexoffice.

Where WooCommerce integrations break

Order status is not a payment state. Orders sit “on hold”, “pending”, “failed”, or as drafts from abandoned checkouts. Book on the wrong status and you post revenue that never arrived. One status transition has to be defined as the booking event.
A tax rate is not a tax key. WooCommerce stores a tax rate and a rate name. DATEV wants a tax key, lexoffice a taxType, SAP a tax code, and each also encodes domestic, EU, and export treatment.
SKUs are free text. A WooCommerce SKU is whatever a shop manager typed, while SAP material numbers are commonly numeric and zero-padded. Without an explicit mapping, order lines land on the wrong material or on none.
Plugins move money too. Subscriptions, bundles, gift cards, and checkout surcharges each add line types that a naive export flattens into one total that no longer reconciles.
The shop lives on a web host. The REST API pages at 100 orders, runs on your hosting, and a WordPress cron can fire twice. A sync has to throttle, checkpoint, and deduplicate.