# Spendesk DATEV integration

*Spendesk → DATEV*

**In short:** A Spendesk to DATEV integration turns settled card payments, approved supplier invoices, expense claims, and wallet top-ups into coded bookings your Steuerberater imports as a Buchungsstapel, with receipts attached. It resolves each supplier to a stable Kreditor, sets the right BU-Schlüssel for domestic VAT, reverse charge on foreign SaaS vendors, and non-deductible items, and books the wallet as its own account with top-ups as Geldtransit. Done properly it is a daily, idempotent pipeline, not a monthly CSV.

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

## Frequently asked questions

### Spendesk already has a DATEV export. Why would I build an integration?

The built-in export is a real product and for a small team on a single entity with clean receipts it is often enough. It starts costing money when you need supplier-specific Kreditor numbers rather than a collective account, reverse-charge coding for foreign SaaS vendors, cost-centre and cost-unit fields filled from your own analytical dimensions, or a correction path for payables that change after they were exported. At that point you are editing the export in Excel every month, which is the work the integration removes.

### How do you handle card payments where the receipt has not been uploaded yet?

A card payment settles whether or not the employee uploaded anything, and booking input tax without a receipt is not defensible in a Betriebsprüfung. We only export payables that Spendesk has marked as complete and ready, and everything still missing a receipt is either held back or booked to an agreed suspense account and re-posted once the document arrives. Either way your finance team gets a list of what is outstanding instead of discovering it at the close.

### How is the Spendesk wallet booked?

As its own financial account, not as your bank account. A top-up from the company account is a Geldtransit booking (1360 in SKR03, 1460 in SKR04, or whatever your Kanzlei uses), and every card payment reduces the wallet account rather than the bank. Book card spend straight against the bank and the wallet balance never reconciles, which is the single most common reason a spend-management export fails audit.

### What happens with foreign SaaS suppliers like AWS, Google, or LinkedIn?

Those are the classic reverse-charge cases under section 13b UStG, and they are extremely common on company cards. The pipeline coding is driven by the supplier country and VAT ID rather than by whatever number appears on the receipt, so an EU service invoice gets the reverse-charge key and lands in the ZM where required, and a third-country invoice gets its own treatment. We agree the supplier-to-treatment mapping with your tax advisor once and then it is applied consistently.

### Who operates the integration once it is live?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor, with alerting and incident response covered by contract. If Spendesk changes its API or DATEV changes an import format, that is our job to handle before your close is affected. You get a named owner and an SLA rather than a script that lives on someone's laptop.

## Related integrations

- [Moss ↔ DATEV](https://seamless.engineering/integrations/moss-datev/): Moss DATEV integration
- [Pleo ↔ DATEV](https://seamless.engineering/integrations/pleo-datev/): Pleo DATEV integration
- [SAP Concur ↔ DATEV](https://seamless.engineering/integrations/sap-concur-datev/): SAP Concur DATEV integration
- [Amazon ↔ DATEV](https://seamless.engineering/integrations/amazon-datev/): Amazon DATEV integration
- [Billbee ↔ DATEV](https://seamless.engineering/integrations/billbee-datev/): Billbee DATEV integration
- [eBay ↔ DATEV](https://seamless.engineering/integrations/ebay-datev/): eBay DATEV integration

## Browse by system

- [All DATEV integrations](https://seamless.engineering/integrations/datev/)
- [DATEV API changelog](https://seamless.engineering/api-changelog/datev/): 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