What connects to lexoffice

lexoffice (now Lexware Office) is the accounting tool many German small businesses, freelancers, and online shops run themselves. It holds contacts, invoices, vouchers, and bank transactions, and when the Steuerberater needs the books, they come out of lexoffice through its DATEV export.

What feeds it is usually commerce and payments. A shop pushes orders and refunds, as in WooCommerce to lexoffice or Shopify to lexoffice. A payment provider adds charges, fees, and payouts that have to stay separate from revenue, as in Stripe to lexoffice. And where the Kanzlei wants more control than the built-in export gives, lexoffice itself becomes the source of a managed lexoffice to DATEV pipeline.

Where lexoffice integrations break

Contacts have no upsert. lexoffice puts no unique constraint on a contact’s email. Post naively and every order creates a new contact, so one repeat buyer becomes twenty Debitoren. Matching has to happen before anything is created.
Finalized means final. Under GoBD a finalized invoice cannot be edited or deleted, only corrected. Refunds go out as credit notes against the original, and every invoice consumes a number from a sequential range, so a duplicate burns one too.
Tax type, not just tax rate. A domestic 19% sale, a 7% item, an intra-community B2B supply, an OSS distance sale, and an export to Switzerland are different taxType and taxSubType values. A wrong one flows straight into the advance VAT return.
Categories, not account numbers. lexoffice books against its own posting categories, referenced by ID, and only maps them to SKR03 or SKR04 in its DATEV export. A pipeline has to speak lexoffice’s model, not DATEV’s.
Two requests per second. The API allows roughly two requests per second per key and answers with HTTP 429 beyond that. Webhooks carry only a resource ID, so every event needs a paced, deduplicated follow-up fetch.