Spendesk DATEV integration

What a Spendesk to DATEV integration actually does

Spendesk sits in front of the money. Virtual and subscription cards for SaaS, physical cards for the team, supplier invoices in the invoice inbox, employee expense claims and mileage, all running through approval and budget rules. It knows who spent what, on which team, and whether a receipt is attached.

DATEV needs the same facts as Buchungssätze: a Sachkonto and, for a supplier, a Kreditor; a BU-Schlüssel; a Belegdatum and a Belegfeld; a Kostenstelle; and a Belegbild that survives a Betriebsprüfung. Between the two views sits the real work. The Spendesk wallet is not your bank account. A card authorisation is not a settled payment. A payment without a receipt is a payment without input-tax deduction. And a subscription to a US vendor is not a 19% domestic expense.

A Spendesk to DATEV integration closes that gap on a schedule. It reads completed payables out of Spendesk, applies your chart of accounts and tax logic, and hands your Kanzlei a booking batch with the matching documents. Nobody re-keys a card statement at month-end and nobody chases receipts in a spreadsheet.

What data moves

Spendesk object or event	Becomes in DATEV	Notes
Settled card payment	Expense booking against the wallet account	Booked on settlement, never on authorisation
Approved supplier invoice (payable)	Kreditor booking with expense account	Kreditorennummer resolved from a stable supplier mapping
Employee expense claim	Booking against the employee’s creditor or a reimbursement clearing account	Paid out by SEPA transfer or via payroll, agreed once
Mileage and per-diem claims	Expense booking, often with restricted or no input tax	Statutory rates, no supplier VAT to recover
Wallet top-up from the company account	Geldtransit booking	1360 in SKR03 / 1460 in SKR04, matched to the bank statement
Spendesk fees and card FX fees	Expense booking, separate from the purchase	Kept out of the underlying cost account
VAT lines on a payable	BU-Schlüssel	19% / 7%, reverse charge under 13b, zero-rated, non-deductible
Team, cost centre, analytical fields	KOST1 / KOST2	Only as far as your DATEV cost accounting is actually set up
Receipt image	Belegbild in DATEV Unternehmen online	Linked to the booking so the document and the entry stay together

The accounts, tax keys, creditor number range, and cost-centre mapping 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

• The wallet is a separate pot of money. Card spend leaves the Spendesk wallet, not the bank account. Top-ups are the only movement the bank sees. Book the two together and the wallet balance drifts every month until somebody spends a day reconstructing it.
• Authorisation is not settlement. The amount held on a card and the amount finally cleared differ, especially with foreign-currency purchases where the FX rate and the card fee land later. The booking has to follow the settled amount and the settlement date, with the FX difference and fee posted separately.
• Receipts arrive late, or never. Input tax without a document is a finding waiting to happen. The pipeline needs an explicit rule: hold the payable, or post it to a suspense account and correct it when the receipt lands. Silently booking gross is not an option.
• Suppliers need stable creditor numbers. Spendesk supplier names drift - the same vendor appears as three variants across three cards. DATEV wants one Kreditor inside your agreed number range. That mapping has to be deterministic and auditable, not a fuzzy match that quietly creates duplicates.
• Foreign vendors mean reverse charge. Cloud, ads, and software subscriptions on company cards are overwhelmingly cross-border. The tax key follows the supplier’s country and VAT ID, not the number printed on the receipt.
• Not everything is deductible. Entertainment splits, gifts over the threshold, and private-share items each need their own account and key. A flat export treats them as ordinary expense and hands your advisor a correction job.
• Field limits and formats. Belegfeld and Buchungstext have length and character restrictions, and the batch header carries the consultant, client, fiscal-year start, and account length. Get the account length wrong and DATEV rejects the whole file.
• Re-export means double booking. A payable that gets corrected after export must produce a correction, not a second identical entry. The pipeline has to know exactly what it has already delivered.

How we build and run it

We treat this as a pipeline, not a monthly chore. Payables are pulled from Spendesk on a schedule, validated against your agreed coding rules, transformed into DATEV bookings, and delivered either as a Buchungsstapel in DATEV format or through DATEV Unternehmen online where the receipt images should travel with the entries. We confirm the target with your Kanzlei before we build, so the import is clean on their side.

The pipeline is idempotent. Every payable carries a stable identifier and its export state is tracked, so a re-run never creates a duplicate booking, and a payable that changes after export produces a correction with a clear audit trail. Anything that fails validation is quarantined and reported rather than silently dropped, because a DATEV import that half succeeds is worse than one that does not run.

It runs on cloud-native, fully EU-hosted infrastructure, so spend and employee data never leaves the EU. That keeps the DPA and AVV with your tax advisor and your GDPR obligations straightforward.

Then we keep it running. Monitoring, alerting, incident response, and watching for Spendesk and DATEV API changes are our contractual responsibility, with a named owner and an SLA. Scoping is fixed-price up front, so you know what the integration costs before it exists.

When this integration is worth building

If you run one entity, a handful of cards, clean receipts, and a domestic supplier base, the standard export plus a little manual tidying is genuinely fine and we will say so. The integration earns its place when card volume grows, when cross-border SaaS spend makes reverse charge a monthly hazard, when you need real cost-centre reporting rather than a single collective account, when multiple entities or subsidiaries are in play, or when your tax advisor is billing you every month to fix an export that should have arrived correct.