WooCommerce lexoffice integration

What a WooCommerce to lexoffice integration actually does

WooCommerce knows everything about a sale - the line items, the tax collected per position, the coupon, the shipping, the gateway fee, the partial refund three days later. lexoffice needs all of that expressed as accounting records: a contact for the customer, an invoice or voucher with correctly taxed lines, a credit note for the refund, and posting categories that carry through to the DATEV export your Steuerberater pulls.

The gap between a WordPress shop and a German accounting system is where the work lives. A WooCommerce to lexoffice integration closes it automatically: it reads each relevant order event from WooCommerce, applies your booking logic, deduplicates the customer, and writes a clean record into lexoffice that your finance workflow can rely on without anyone re-keying figures.

What data moves

WooCommerce object / event	Becomes in lexoffice	Notes
Paid order (processing / completed)	Sales invoice (Rechnung) or voucher (Beleg)	Model chosen per your bookkeeping; one record per order
Order billing customer	Contact (Kontakt / Debitor)	Deduplicated on email and VAT ID, not created blindly
Order line items	lexoffice line items with unit price and quantity	Net or gross per your taxType convention
Tax lines	taxType + taxRatePercentage per line	19% / 7% domestic, plus the correct tax subtype cross-border
Shipping line	Separate line item	Shipping is itself taxable and booked on its own position
Fee lines / gateway fees	Separate line or expense voucher	Kept apart from revenue so the net payout reconciles
Coupon / discount	Reduced line amounts	lexoffice has no discount object; the net is applied per line
Refund / partial refund	Credit note (salescreditnote / Rechnungskorrektur)	Same lines and tax keys as the original, dated to the refund

The exact posting categories, tax handling, and invoice-versus-voucher model are agreed once and encoded in the pipeline. After that, nobody maps an order by hand.

The details that break naive syncs

A directory plugin or a one-off export gets you 80% of the way and leaves the expensive 20% on your desk:

• Contact dedup. lexoffice has no upsert. Post naively and every order spawns a fresh Kontakt, so one repeat customer becomes twenty debitors and your receivables view is meaningless. Matching on email and VAT ID before create-or-link is not optional.
• Tax subtype, not just rate. A 19% domestic sale, a 7% reduced item, an EU B2B sale under intra-community supply, and an export to Switzerland are not four tax rates - they are different taxType and taxSubType values in the lexoffice API. Get one wrong and the Umsatzsteuervoranmeldung is wrong.
• Categories, not SKR. lexoffice books revenue against its own posting categories (Kategorien) referenced by ID, then maps those to SKR03/SKR04 in its DATEV export. The pipeline has to resolve the correct category ID per product type, not a raw account number.
• Invoice numbers are sacred. Creating a lexoffice Rechnung consumes a sequential invoice number. Re-run a naive import and you either burn numbers on duplicates or create gaps - both of which your Steuerberater will flag. Where you only need the booking, a voucher (Beleg) avoids the number entirely.
• Rate limits and partial failures. The lexoffice API caps at roughly two requests per second and returns 429 under load; WooCommerce paginates at 100 orders per page and lives on your shared web host. A sync that does not throttle, retry, and checkpoint will drop orders mid-run and leave lexoffice half-populated.
• Refund timing. A partial refund in WooCommerce has to become a credit note against the exact lines and tax keys of the original order, dated to the refund - not a negative line bolted onto a new document.

How we build and run it

We treat this as a pipeline, not a plugin. WooCommerce order and refund events are pulled on a schedule (or by webhook), validated, deduplicated against existing lexoffice contacts, transformed into your agreed lexoffice records, and written through the lexoffice Invoices or Vouchers endpoint - with throttling that respects the API rate limit and backs off cleanly on 429.

The pipeline is idempotent: every WooCommerce order carries a stable ID, so a retry or a re-run never creates a second invoice, a duplicate voucher, or a phantom contact. It runs on cloud-native, fully EU-hosted AWS infrastructure, so order and customer data never leaves the EU - which keeps your DPA/AVV and your GDPR obligations clean, and matters given lexoffice is itself a German system.

Then we keep it running. Monitoring, alerting, incident response, and watching for WooCommerce and lexoffice API changes are our responsibility under contract. Your month-end stops depending on a WordPress cron job nobody owns.

When this integration is worth building

If you process a handful of orders a month at a single VAT rate, a directory plugin or even manual entry into lexoffice is genuinely fine, and we will tell you so. The integration earns its place when volume climbs, when you sell across EU borders and need correct tax subtypes, when refunds and multiple payment gateways make reconciliation a monthly chore, or when duplicate contacts and broken invoice numbers are already costing you time your Steuerberater bills back to you. At that point a plugin on your web server is a liability, and a managed, EU-hosted pipeline with a named owner earns its keep.