In short A sevDesk to DATEV integration turns outgoing invoices, incoming vouchers, contacts, and matched payments into a DATEV-Format booking batch (Buchungsstapel) your Kanzlei can import directly - with sevDesk booking accounts mapped to your SKR03 or SKR04 accounts, the correct BU tax keys, stable Debitor and Kreditor numbers, and receipt images linked to the bookings they belong to. Rather than a monthly ZIP download, it runs on a schedule, sends only what changed, and never books the same document twice.
What a sevDesk to DATEV integration actually does
sevDesk is where the business actually happens: invoices go out, supplier receipts get captured and categorised, bank transactions get matched. DATEV is where the Kanzlei does the accounting - the Buchhaltung, the advance VAT return, the annual close. Both systems hold the same transactions, but they describe them completely differently.
sevDesk thinks in documents: an invoice with positions, a voucher with a booking account, a contact with a customer number. DATEV thinks in bookings: account and contra account, BU key, Belegfeld, posting date, Debitor or Kreditor. sevDesk ships a DATEV export, but it is a manual download that produces a file somebody then has to send onwards.
A sevDesk to DATEV integration closes that gap continuously: it reads what changed, applies the coding rules you agreed with your tax advisor, and hands DATEV a clean booking batch plus the matching receipt images.
What data moves
| sevDesk object / event | Becomes in DATEV | Notes |
|---|
| Outgoing invoice (Rechnung) | Revenue booking against a Debitor | Split per position tax rate; invoice number goes into Belegfeld 1 |
| Cancellation invoice (Stornorechnung) | Reversing booking | Own entry with its own date, never a deletion of the original |
| Incoming voucher (Beleg) | Expense booking against a Kreditor | sevDesk booking account mapped to your SKR03 / SKR04 expense account |
| Contact (customer / supplier) | Debitoren- / Kreditorenstammsatz | Person account taken from the number range agreed with your Kanzlei |
| Payment / partial payment | Bank or Geldtransit booking | Skonto, fees, and rounding differences booked as separate lines |
| Receipt image (Belegbild) | Document in DATEV Unternehmen online | Linked to its booking so Beleg and Buchung stay together |
| Recurring invoice run | Ordinary revenue bookings | Only the generated documents are booked, never the template |
Account numbers, tax keys, and number ranges are agreed once with your tax advisor and encoded in the pipeline. After that nobody maps them again by hand.
The details that break naive exports
- sevDesk booking accounts are not DATEV accounts. The categories you pick in sevDesk are sevDesk’s own taxonomy. They have to be translated into the actual Sachkonten of your SKR03 or SKR04 - including the accounts your Kanzlei has customised. A default mapping quietly books half your expenses to the wrong place.
- Person accounts drift. sevDesk customer numbers are optional free text. If they drive the Debitorenkonto, one typo creates a second account for the same customer, and the open-item list stops reconciling. The mapping has to live in the pipeline, not in a spreadsheet.
- Belegfeld 1 is not a free text field. It is limited in length and accepts only a restricted set of characters. Invoice-number schemes with dots, hashes, or long prefixes need to be normalised on the way out, not passed through and truncated by the import.
- Dates and the Wirtschaftsjahr. A booking batch carries its period in the header, and the posting dates inside it are interpreted against that period. A batch must never span a financial year boundary, and back-dated documents that appear after the fact need their own batch rather than being folded into the current one.
- Festschreibung. Once your Kanzlei has locked a period, nothing in it may be re-imported. A correction posted in sevDesk after the fact has to arrive as a new, correctly dated booking - which means the pipeline needs to know what it already delivered and when the period closed.
- Edits are not creations. sevDesk documents can be changed after they are written. A delta sync keyed only on creation date silently misses those edits; a full re-export duplicates everything. You need change detection plus a stable idempotency key per document.
- Drafts, payments, and status. Draft invoices must never be booked, partially paid invoices must not be treated as settled, and the payment is a separate event from the invoice. Skonto in particular changes both the revenue and the VAT and needs its own booking line.
- Volume and API limits. Pulling a year of vouchers with their receipt images is a lot of API calls. The pipeline paginates, respects rate limits, and resumes where it stopped instead of restarting the whole period.
How we build and run it
We treat this as a pipeline, not a monthly chore. Invoices, vouchers, contacts, and payments are read from the sevDesk API on a schedule, validated against a schema, transformed into the DATEV coding you agreed with your tax advisor, and written out as a booking batch plus a Debitoren/Kreditoren master-data file - or delivered into DATEV Unternehmen online with the receipt images attached, where that suits your Kanzlei’s workflow.
The pipeline is idempotent. Every sevDesk document carries a stable identifier, and we track what has already been delivered, so a retry, a re-run, or a partially failed batch never produces a duplicate booking. Failed records land in a dead-letter queue and are visible, not silently dropped.
It runs on cloud-native, fully EU-hosted AWS infrastructure, so invoice, supplier, and customer data never leaves the EU. That keeps the DPA / AVV with your tax advisor and your GDPR position clean, and it keeps the GoBD audit trail intact because every delivery is logged.
And then we keep it running. Monitoring, alerting, incident response, and watching for sevDesk and DATEV API changes are our responsibility under contract, with fixed-price scoping up front and a named owner afterwards.
When this integration is worth building
If you write twenty invoices a month, book a handful of receipts, and your Kanzlei is happy with the export you send, build nothing. We will say so. The integration earns its place when document volume makes the manual export a recurring risk, when your tax advisor is billing you to clean up mappings, when receipts and bookings keep getting separated, or when the close depends on one person remembering to click export before they go on holiday.
Frequently asked questions
- sevDesk already has a DATEV export - why would I need an integration?
- Because the built-in export is a manual, period-based download. Somebody has to remember to run it, pick the right date range, and get the ZIP to the Kanzlei. It also gives you very little control over how sevDesk booking accounts, tax keys, and Personenkonten map into your tax advisor's chart of accounts, and nothing stops two overlapping exports from being imported twice. At low volume that is genuinely fine. Once you are past a few hundred documents a month, or your Kanzlei keeps sending corrections back, the manual step is the bottleneck.
- Which DATEV format do you deliver into?
- Whichever your Kanzlei works with. Most commonly a booking batch in DATEV format (the EXTF Buchungsstapel that DATEV Kanzlei-Rechnungswesen imports), plus a Debitoren/Kreditoren master-data file so person accounts arrive with the correct names and addresses. Where the workflow calls for it, we deliver documents and booking proposals into DATEV Unternehmen online instead. We agree the target, the Berater and Mandant numbers, and the account length with your tax advisor before we build anything.
- How do you keep Debitor and Kreditor numbers consistent?
- sevDesk customer numbers are free text and often incomplete, while DATEV expects person accounts inside defined ranges of your chart of accounts. We hold a mapping between the sevDesk contact ID and the DATEV Personenkonto, so a customer always books to the same account. New contacts get the next free number from the range your Kanzlei agreed, and the master-data record is created before the first booking that references it.
- What happens to the receipt images stored in sevDesk?
- They go with the booking. sevDesk holds the scanned or uploaded document on the invoice or voucher, and we deliver it into DATEV Unternehmen online linked to its booking record, so the Kanzlei sees the Beleg next to the Buchung instead of asking you for it by email. That linkage is also what keeps the audit trail intact for GoBD purposes.
- Who operates the integration after it goes live?
- We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor. If sevDesk changes its API or DATEV changes an import format, fixing it is our contractual obligation, not something your bookkeeper discovers on the tenth of the month. You get a named owner, alerting, incident response, and an SLA rather than a script somebody maintains in their spare time.