# Shopify sevDesk integration

*Shopify → sevDesk*

**In short:** A Shopify to sevDesk integration turns each paid Shopify order into a correctly taxed sevDesk record - an invoice (Rechnung) or booking voucher (Beleg) - posted against a matched contact (Debitor), while Shopify Payments, PayPal, and Klarna payouts flow into a sevDesk clearing account and get matched back to the open items so invoices close as paid. Done properly it is not a nightly CSV import: it is an idempotent pipeline that keeps sevDesk in sync with the shop, handles refunds and OSS VAT, and reconciles net payouts against gross sales plus fees without anyone re-keying figures.

## What a Shopify to sevDesk integration actually does

Shopify holds the commercial truth of every sale: the line items, the tax collected per rate, the discount, the shipping, the refund three days later, and the Shopify Payments payout that lands next week net of fees. sevDesk is where that has to become accounting: a contact (Debitor), an invoice or booking voucher with the right tax type, and a bank transaction that closes the open item once the money actually arrives.

The work lives in the gap between those two systems. A Shopify to sevDesk integration closes it automatically. It reads each relevant order, refund, and payout from Shopify, applies your bookkeeping rules, and writes clean records into sevDesk that your bookkeeper - and by extension your tax advisor pulling the DATEV export out of sevDesk - can trust without re-checking figures by hand.

## What data moves

| Shopify object / event | Becomes in sevDesk | Notes |
| --- | --- | --- |
| Paid order | Invoice (Rechnung) or booking voucher (Beleg) | Model chosen per your bookkeeping; consistent across all orders |
| Order customer | Contact (Debitor) | Matched on email / customer number, deduplicated, never created twice |
| Line items | Document positions with per-item tax rate | Article mapping optional; revenue split by rate |
| Tax lines | sevDesk tax type + position rate | Domestic 19% / 7%, EU OSS, reverse-charge, third-country export, Kleinunternehmer |
| Shipping & discounts | Separate positions | Shipping is itself taxable; discounts reduce the correct base |
| Refund / partial refund | Credit note or reversing voucher | Same contact, accounts, and tax type as the original, dated to the refund |
| Provider payout | Clearing-account (CheckAccount) transaction | Shopify Payments / PayPal / Klarna each on their own clearing account |
| Provider fees | Expense voucher | Netted payout matched to gross sales plus fees |
| Payment match | Booking against the open invoice | Sets the invoice status to paid once the payout reconciles |

The tax types, clearing accounts, and the invoice-versus-voucher decision are agreed 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 app gets you most of the way and leaves the expensive part on your bookkeeper's desk:

- **Contact deduplication.** Shopify guest checkouts have no stable customer identity. Without a defined match key, every order spawns a fresh Debitor and sevDesk fills with duplicate contacts. The pipeline resolves each order to exactly one contact.
- **Tax type, not just tax rate.** sevDesk distinguishes a domestic sale, an EU distance sale under OSS, an EU reverse-charge B2B sale, and a third-country export at the document level, not only per position. The destination country and the customer's status decide it - and a wrong tax type quietly corrupts the VAT return.
- **The payout is not the revenue.** Shopify Payments settles net of fees, days later, in a batch spanning many orders. Booking the payout as revenue reconciles to nothing. The sale and the settlement have to be separate records joined through a sevDesk clearing account, with fees booked as their own expense.
- **Payment matching.** An invoice in sevDesk stays open until a transaction is booked against it. The integration has to link each payout back to the right orders so invoices actually close as paid, rather than showing a growing pile of open items no one collected.
- **Refunds and chargebacks.** A partial refund has to reverse the exact contact, accounts, and tax type of the original order, dated to the refund, not the sale.
- **Idempotency.** Re-run a naive import and you book the same day twice. The pipeline knows which Shopify events it has already posted and never creates a duplicate record.

## How we build and run it

We treat this as a pipeline, not a nightly script. Shopify order, refund, and payout events are pulled on a schedule or by webhook, validated, transformed into your agreed sevDesk model, and written through the sevDesk API - contacts matched, invoices or vouchers created with the right tax type, payouts posted to the clearing account and matched to their open items.

The pipeline is idempotent: every Shopify event carries a stable identifier, so a retry or a re-run never produces a duplicate contact, invoice, or booking. 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.

Then we keep it running. Monitoring, alerting, incident response, and - critically - watching for Shopify and sevDesk API changes are our responsibility under contract, with a named owner and an SLA. Shopify deprecates Admin API versions on a fixed schedule and sevDesk evolves its endpoints; when that happens it is our problem to fix, not a surprise your finance team discovers at month-end.

## When this integration is worth building

If you process a handful of orders a month at a single VAT rate, entering them in sevDesk by hand is genuinely fine and we will tell you so. The integration earns its place when order volume climbs, when you sell across EU borders under OSS, when refunds and multiple payment providers turn reconciliation into a monthly chore, or when duplicate contacts and unmatched payouts mean someone spends the first week of every month cleaning up sevDesk instead of closing the books.

## Frequently asked questions

### Should each Shopify order become a sevDesk invoice (Rechnung) or a booking voucher (Beleg)?

It depends on how you run your books and whether you issue customer-facing invoices from sevDesk. High-volume B2C shops usually post orders as booking vouchers (Belege) so the numbers reach accounting without generating thousands of formal Rechnungen. B2B or invoice-required flows create a proper sevDesk invoice per order with the correct customer number and tax treatment. We agree the model up front and the pipeline sticks to it consistently.

### How do you stop duplicate contacts (Debitoren) piling up in sevDesk?

Shopify has no single stable customer key across guest checkouts, so a naive import creates a new contact for every order. We match on a defined key - email, plus customer number where you use one - and only create a sevDesk contact when none exists, otherwise we reuse it. Guest and repeat orders resolve to one Debitor instead of a cluttered contact list your bookkeeper has to clean up.

### How are Shopify Payments, PayPal, and Klarna payouts reconciled in sevDesk?

The sale and the money arriving are separate events. We post revenue at the point of sale and route each provider payout into its own sevDesk clearing account (CheckAccount), then match the netted payout, the provider fees, and the underlying orders so the transaction reconciles and the invoices close as paid. This split is the part manual imports almost always get wrong, because a payout batch spans many orders and arrives net of fees days later.

### Does it handle OSS, mixed VAT rates, and Kleinunternehmer?

Yes. Domestic 19% and 7% sales, EU B2C distance sales under One-Stop-Shop, EU B2B reverse-charge, and third-country exports each map to the correct sevDesk tax type and per-position rate. If you file under the Kleinunternehmer rule the pipeline posts without VAT accordingly. The destination country and customer tax status drive the coding, so your books and your OSS figures come from the same source.

### Do we still need our tax advisor and DATEV if sevDesk is in the middle?

Yes, and that is the point. sevDesk stays your system of record and keeps doing its DATEV export to your Steuerberater. The integration's job is to get Shopify's sales, refunds, and payouts into sevDesk cleanly and correctly, so what your advisor pulls out of sevDesk is already right. We keep the Shopify side feeding it; your Kanzlei keeps working the way it does today.

## Common errors

- [Shopify: Exceeded 2 calls per second for api client](https://seamless.engineering/errors/shopify-exceeded-2-calls-per-second/)
- [Shopify: 429 Too Many Requests](https://seamless.engineering/errors/shopify-429-too-many-requests/)

## Related integrations

- [Shopify ↔ DATEV](https://seamless.engineering/integrations/shopify-datev/): Shopify DATEV integration
- [Shopify ↔ lexoffice](https://seamless.engineering/integrations/shopify-lexoffice/): Shopify lexoffice integration
- [Shopware ↔ sevDesk](https://seamless.engineering/integrations/shopware-sevdesk/): Shopware sevDesk integration
- [sevDesk ↔ DATEV](https://seamless.engineering/integrations/sevdesk-datev/): sevDesk DATEV integration
- [Shopify ↔ weclapp](https://seamless.engineering/integrations/shopify-weclapp/): Shopify weclapp integration
- [Stripe ↔ sevDesk](https://seamless.engineering/integrations/stripe-sevdesk/): Stripe sevDesk integration

## Browse by system

- [All Shopify integrations](https://seamless.engineering/integrations/shopify/)
- [All sevDesk integrations](https://seamless.engineering/integrations/sevdesk/)
- [Shopify API changelog](https://seamless.engineering/api-changelog/shopify/): 9 breaking changes and 2 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