# WooCommerce lexoffice integration

*WooCommerce → lexoffice*

**In short:** A WooCommerce to lexoffice integration turns each paid WooCommerce order into the matching record in lexoffice - a sales invoice (Rechnung) or booking voucher (Beleg) with correct line items, the right taxType and taxRatePercentage per position, and a deduplicated contact (Kontakt) as the debitor. Refunds become credit notes, shipping and fees get their own lines, and EU or third-country sales carry the correct tax subtype for reverse-charge, intra-community supply, or export. Done properly it is not a nightly CSV import: it is an idempotent pipeline that keeps lexoffice in sync with your shop so your bookkeeping and Steuerberater start from clean, correctly taxed data.

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

## Frequently asked questions

### Can I not just use a WooCommerce lexoffice plugin from the WordPress directory?

For a low-volume shop on a single VAT rate, a plugin is often fine and we will say so. Plugins struggle once you have refunds, mixed tax rates, EU cross-border sales, or several payment gateways, because they run inside WordPress on the same server as your shop and share its uptime, its cron, and its failure modes. When a sync silently stops or double-creates an invoice, nobody is on the hook. The integration moves that logic off your web server into a monitored pipeline that someone actually operates.

### Does it create an invoice or a booking voucher in lexoffice?

Whichever fits your bookkeeping. For shops that need a compliant customer invoice per order we create a lexoffice sales invoice (Rechnung) via the Invoices endpoint. For pure bookkeeping, where the shop or the payment provider already issued the document, we post a sales voucher (Beleg) via the Vouchers endpoint so your revenue is booked without generating a duplicate invoice number. We agree which model you need before build, so lexoffice and your DATEV export stay consistent.

### How does it handle German and EU VAT correctly?

Each line carries the correct taxType and taxRatePercentage, and cross-border cases get the right tax subtype - intra-community supply for EU B2B with a valid VAT ID, third-country delivery for exports, and vatfree where the Kleinunternehmerregelung under section 19 UStG applies. The destination country and the customer's tax status drive the coding, so what lands in lexoffice is already correct rather than something your Steuerberater has to reclassify.

### How are customers matched so I do not get duplicate contacts in lexoffice?

lexoffice has no native upsert, so a naive sync creates a new Kontakt for every order. We match on email and, for business customers, VAT ID against existing lexoffice contacts before deciding to link or create. That keeps one debitor per customer with a clean history instead of hundreds of near-duplicate records that break your receivables view.

### Who operates it after go-live?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor, independent of your WordPress host. If WooCommerce or the lexoffice API changes, that is our problem to fix under contract, not something your finance team discovers at month-end. You get a named owner, alerting, incident response, and an SLA - plus a DPA/AVV so the whole flow stays GDPR-clean.

## Related integrations

- [Shopify ↔ lexoffice](https://seamless.engineering/integrations/shopify-lexoffice/): Shopify lexoffice integration
- [WooCommerce ↔ DATEV](https://seamless.engineering/integrations/woocommerce-datev/): WooCommerce DATEV integration
- [lexoffice ↔ DATEV](https://seamless.engineering/integrations/lexoffice-datev/): lexoffice DATEV integration
- [Stripe ↔ lexoffice](https://seamless.engineering/integrations/stripe-lexoffice/): Stripe lexoffice integration
- [WooCommerce ↔ SAP](https://seamless.engineering/integrations/woocommerce-sap/): WooCommerce SAP integration
- [Amazon ↔ DATEV](https://seamless.engineering/integrations/amazon-datev/): Amazon DATEV integration

## Browse by system

- [All WooCommerce integrations](https://seamless.engineering/integrations/woocommerce/)
- [All lexoffice integrations](https://seamless.engineering/integrations/lexoffice/)
- [lexoffice API changelog](https://seamless.engineering/api-changelog/lexoffice/): 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