In short A sevDesk integration turns orders, refunds, and payouts into sevDesk contacts, invoices, or vouchers with the right tax treatment, and books payments so open items actually close. It usually also feeds DATEV for the tax advisor. It breaks on duplicate Debitoren, tax rules that depend on country and customer status, payouts booked as revenue, and invoice number ranges claimed by two systems at once.
What connects to sevDesk
sevDesk is cloud accounting for German small businesses and online sellers: invoices, vouchers, contacts, bank accounts, and the open items that tie them together. The Steuerberater usually takes the books over through a DATEV export.
The systems connected to it are mostly where the money is earned. Shops send orders and refunds, as in Shopify to sevDesk and Shopware to sevDesk. Payment providers send charges, fees, and net payouts, as in Stripe to sevDesk. On the other side, a managed sevDesk to DATEV pipeline hands the result to the Kanzlei when the built-in export is not enough.
Where sevDesk integrations break
- Guest checkouts create duplicate Debitoren. Shops rarely carry a stable customer identity, and sevDesk customer numbers are optional free text. Without a defined match key, every order spawns a new contact and the open-item list stops reconciling.
- Tax treatment is decided per document. sevDesk distinguishes a domestic sale, an OSS distance sale, EU reverse charge, and a third-country export at document level, driven by destination country and customer status. Since sevdesk Update 2.0, tax rules have replaced the old free taxType, and connectors still sending the legacy values depend on a transitional mapping.
- An invoice stays open until money is booked against it. Shopify Payments, Stripe, and PayPal settle net of fees in batches. Sale, fee, and payout have to be separate records joined through a clearing account and linked back, so invoices close as paid.
- Someone has to own the number range. Shops and sevDesk both want to assign invoice numbers. Decide the owner up front, or you get gaps and two documents for one sale.
- Edits are not creations. sevDesk documents can change after they are written. A sync keyed on creation date misses those edits and a full re-export duplicates everything, so change detection and a stable idempotency key per document are required.