Stripe lexoffice integration

What a Stripe to lexoffice integration actually does

Stripe is where the money happens - the successful payment, the monthly subscription invoice, the refund three days later, the disputed charge, the fee Stripe keeps, the payout that lands in your bank account on Thursday net of everything. lexoffice is where all of that has to become bookkeeping: the right contact, the right tax rate, the right booking category, and revenue cleanly separated from the money that actually arrived.

The gap between those two systems is manual work that lands on someone every month. A Stripe to lexoffice integration closes it automatically: it reads each relevant event from Stripe, applies your tax and booking logic, and writes a clean record into lexoffice - ready for lexoffice to hand on to your Steuerberater via its DATEV export, with nobody touching a spreadsheet.

What data moves

Stripe object / event	Becomes in lexoffice	Notes
Successful payment (payment_intent.succeeded / charge)	Sales voucher (Beleg)	Booked to a revenue category with the correct tax rate
Paid subscription invoice (invoice.paid)	Sales voucher with line items	Tax and line detail taken from the Stripe invoice
Stripe customer	Contact (Kontakt)	Matched by email / VAT ID; created only if missing
Refund	Credit-note voucher (salescreditnote)	Reverses the original record, dated to the refund
Dispute / chargeback	Reversing voucher + fee expense	Lost dispute reverses revenue; the dispute fee is booked as cost
Stripe fee (per balance transaction)	Expense voucher	Payment-processing cost, netted against gross revenue
Payout	Clearing-account settlement	A batch of transactions reconciled to one bank line
Invoice / receipt PDF	File attached to the voucher	Source document kept for the audit trail

The contact-matching rules, the booking categories, and the tax treatment are agreed with you once and encoded in the pipeline. After that, nobody maps them again by hand.

The details that break naive imports

A CSV import or a generic connector gets you 80% of the way and leaves the expensive 20% on your desk:

• Amounts are in minor units, and currencies differ. Stripe stores every amount in the smallest currency unit (cents), with zero-decimal exceptions, and can settle in currencies other than EUR. A record booked without correct conversion and rounding is wrong from the start.
• The payout is not the revenue. Stripe deducts its fee per charge and pays out a batch of many charges, days later, as a single net figure. Book that figure as revenue and nothing reconciles. Gross sale, Stripe fee, and net payout have to be three linked bookings joined by a clearing account.
• VAT is your job, not Stripe’s. Without Stripe Tax, Stripe does not decide German VAT treatment. A domestic 19% sale, a 7% item, an EU B2C sale under OSS, a B2B reverse-charge with a valid USt-IdNr, and a third-country export are all different - and the Umsatzsteuervoranmeldung is wrong if the tax rate is.
• lexoffice does not take raw account numbers. You book to a lexoffice contact, a booking category, and a tax rate - not a free-form SKR03 or SKR04 account. lexoffice and your Steuerberater handle the DATEV account mapping downstream, so the pipeline has to speak lexoffice’s model, not DATEV’s.
• Refunds and disputes must reverse the original. A refund or a lost dispute has to reverse the exact category and tax rate of the original charge, on its own date - and a dispute also carries a separate fee.
• Idempotency. Stripe delivers webhooks at least once and can redeliver events. Every record must be keyed to a stable Stripe ID so a retry or a re-run never books the same charge twice.

How we build and run it

We treat this as a pipeline, not a monthly import. Stripe events arrive by webhook (with a backfill over the Stripe list API for historical data), are validated, transformed into your agreed lexoffice contact, category, and tax treatment, and written as vouchers - with the source PDF attached and each payout reconciled through a clearing account.

The pipeline is idempotent: every record is keyed to a stable Stripe identifier, so a webhook redelivery or a re-run never produces a duplicate booking. It runs on cloud-native, fully EU-hosted AWS infrastructure. Card data never leaves Stripe’s PCI environment - we move transaction metadata and contact details only - which keeps the DPA / AVV and your GDPR obligations clean.

Then we keep it running. Monitoring, alerting, incident response, respecting lexoffice’s API rate limit, and watching for Stripe API version changes and lexoffice API changes are our responsibility under contract. Your close stops depending on someone remembering to run an import.

When this integration is worth building

If you take a handful of one-off payments a month at a single VAT rate, manual voucher entry or a basic connector is genuinely fine, and we will tell you so. The integration earns its place when recurring subscription volume climbs, when you sell across EU borders under OSS, when refunds and disputes make reconciliation a monthly chore, when multiple currencies enter the picture, or when reconciling Stripe payouts against your bank has become the slowest part of your month-end close.