# Stripe lexoffice integration

*Stripe → lexoffice*

**In short:** A Stripe to lexoffice integration turns every Stripe payment, subscription invoice, refund, and dispute into a correctly taxed booking record (Beleg) in lexoffice, linked to the right contact and booking category, so your accounting is complete without anyone re-keying figures. Stripe fees are booked as expenses and each Stripe payout is reconciled against a clearing account so the net amount on your bank statement matches to the cent. Done properly it is not a monthly CSV import - it is an idempotent pipeline that keeps lexoffice in sync with Stripe automatically, ready for the DATEV export to your Steuerberater.

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

## Frequently asked questions

### Can I not just import a Stripe CSV into lexoffice, or use the built-in connector?

For a handful of payments a month at one VAT rate, yes. It breaks down once you have recurring subscriptions, refunds, disputes, multiple currencies, and Stripe fees to account for. A raw export has no contact matching, no split between gross revenue and the Stripe fee, no clearing logic for batched payouts, and no protection against importing the same charge twice. The pipeline moves that logic out of your month-end and runs it continuously.

### How do you get Stripe fees and payouts to reconcile against my bank?

Stripe settles net: it deducts its fee per charge and pays out a batch of many transactions days later as a single bank line. We book gross revenue and the Stripe fee as separate records, then route each payout through a clearing account (Geldtransit / Verrechnungskonto) so the netted lump sum on your bank statement reconciles exactly. This is the part manual imports almost always get wrong.

### Does it handle German and EU VAT correctly?

Yes. Stripe on its own does not determine German VAT treatment, so we apply it: domestic 19% or 7%, EU B2C distance sales under OSS by destination country, EU B2B reverse-charge where a valid USt-IdNr is present, and third-country exports. If you bill as a Kleinunternehmer under section 19, records are created without VAT. The correct tax rate and booking category are set on every voucher.

### How do you match Stripe customers to lexoffice contacts?

Every lexoffice booking record needs a contact. We match Stripe customers to existing lexoffice contacts by email and, for business customers, by VAT ID, and create the contact only when none exists - so you do not end up with a duplicate contact for every guest checkout. The matching rules are agreed with you up front and applied consistently.

### Who operates it after it goes live?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor. If Stripe pins a new API version or lexoffice changes its API, that is our problem to fix, not something your finance team discovers at month-end. You get a named owner, alerting, incident response, and an SLA rather than a script somebody has to remember to run.

## Related integrations

- [Stripe ↔ DATEV](https://seamless.engineering/integrations/stripe-datev/): Stripe DATEV integration
- [Stripe ↔ sevDesk](https://seamless.engineering/integrations/stripe-sevdesk/): Stripe sevDesk integration
- [NetSuite ↔ Stripe](https://seamless.engineering/integrations/netsuite-stripe/): NetSuite Stripe integration
- [Stripe ↔ QuickBooks](https://seamless.engineering/integrations/stripe-quickbooks/): Stripe QuickBooks integration
- [Stripe ↔ Xero](https://seamless.engineering/integrations/stripe-xero/): Stripe Xero integration
- [lexoffice ↔ DATEV](https://seamless.engineering/integrations/lexoffice-datev/): lexoffice DATEV integration

## Browse by system

- [All Stripe integrations](https://seamless.engineering/integrations/stripe/)
- [All lexoffice integrations](https://seamless.engineering/integrations/lexoffice/)
- [Stripe API changelog](https://seamless.engineering/api-changelog/stripe/): No breaking changes or deprecations in the last 90 days
- [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