Shopify lexoffice integration

What a Shopify to lexoffice integration actually does

Shopify records everything about a sale - the customer, the line items, the discount code, the shipping, the VAT collected, the refund three days later. lexoffice (now lexware office) needs that same sale expressed as clean bookkeeping: a contact for the buyer, an invoice or voucher with the right tax rate on every line, and a credit note when money goes back. In between sits a surprising amount of judgement that a CSV import or a generic plugin simply does not make.

A Shopify to lexoffice integration closes that gap automatically. It reads each relevant order and refund from Shopify, matches or creates the right lexoffice contact, and writes a correctly taxed invoice or sales voucher - without your bookkeeper re-typing a single figure and without duplicate customers piling up in the Kontakte list.

What data moves

Shopify object / event	Becomes in lexoffice	Notes
Paid order	Finalized invoice (Rechnung) or sales voucher (Beleg)	Choice depends on who issues the legal invoice; agreed once
Customer / billing address	Contact (Kontakt, role customer / Debitor)	Deduplicated by email and address to avoid duplicate contacts
Line items	Invoice / voucher line items	Net or gross unit price plus taxRatePercentage per item
Discount code	Line-item or document discount	Applied so the document total matches the Shopify total
Shipping line	Separate line item	Shipping is taxable and needs its own line and rate
Tax lines	taxType + tax rate (19% / 7%)	Domestic straightforward; cross-border is the hard part
Refund / partial refund	Credit note (Rechnungskorrektur)	References the original document; original stays locked
Payment / transaction	Document marked paid	Optional, where lexoffice tracks payment status
Payout & provider fees	Bank booking / expense voucher	Reconciled in the lexoffice bank feed, not on the sales invoice

The mapping - which orders become vouchers, which tax rate applies where, how contacts are matched - is agreed once and encoded in the pipeline. After that, nobody maps an order by hand.

The details that break naive syncs

A nightly export or an off-the-shelf connector gets you most of the way and leaves the expensive edge cases on your desk:

• Contact deduplication. lexoffice puts no unique constraint on a contact’s email, and Shopify guest checkouts carry no persistent customer id. Without a matching strategy you get a fresh Debitor per order and a Kontakte list nobody can reconcile. Matching has to happen on email plus address before any contact is created.
• GoBD immutability. Once a lexoffice invoice is finalized it cannot be edited or deleted, only corrected. A pipeline that tries to “update” a booked document fails - refunds and corrections must go out as credit notes against the original, never as an edit.
• Invoice or voucher. If Shopify already issued the customer’s receipt, creating a second numbered lexoffice invoice double-issues the document. Deciding between a finalized invoice and a sales voucher is an accounting decision, not a default, and it changes your numbering.
• The 2-requests-per-second limit. The lexoffice API caps writes at roughly two per second per key. A bulk backfill or a sale-day spike hits 429s immediately, so writes must be queued, paced, and retried with backoff rather than fired in a loop.
• Cross-border VAT. Domestic 19% and 7% are easy. EU distance sales under OSS, reverse-charge B2B, and third-country exports each need the right tax treatment, and lexoffice’s OSS handling is the weakest link - the destination country and the customer’s tax status have to drive the coding.
• Rounding. Shopify computes totals its own way; lexoffice recomputes from line items. Net-versus-gross rounding can leave a cent of difference that has to be resolved on a line, or the document total will not match the order.
• Idempotency. Re-run a naive import and the same order is booked twice against an immutable ledger you then cannot simply delete. The pipeline must know it already created a document for a given Shopify order and never create it again.

How we build and run it

We treat this as a pipeline, not a nightly job. Shopify order and refund events are pulled by webhook or on a schedule, validated, matched to the right lexoffice contact, and written out as the agreed invoice or voucher - with refunds emitted as credit notes against the original document.

The pipeline is idempotent: every Shopify order carries a stable identifier that we map to its lexoffice document, so a retry or a re-run never creates a duplicate against GoBD-locked records. It respects the lexoffice rate limit by design, paces and retries writes, and isolates partial failures so one malformed order never blocks the batch. 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 GDPR obligations clean.

And then we keep it running. Monitoring, alerting, incident response, and watching for Shopify and lexoffice API changes are our responsibility under contract, with a named owner and an SLA. Your books stop depending on someone remembering to run an import.

When this integration is worth building

If you process a handful of domestic orders a month at a single VAT rate, lexoffice’s own import or a light connector is genuinely fine, and we will tell you so. A managed pipeline earns its place when order volume climbs, when guest checkouts and duplicate contacts start polluting your Kontakte, when refunds and GoBD corrections become a monthly chore, or when you sell across EU borders under OSS and the tax coding has to be right the first time - because a locked, wrong invoice is far more expensive to fix than a correct one is to build.