Pleo DATEV integration

What a Pleo to DATEV integration actually does

Pleo sits at the front of the spend process. An employee taps a card, photographs the receipt, picks a category, maybe adds a team tag, and the transaction is done. Everything after that belongs to a different world: DATEV, and the Kanzlei working inside it, needs the same event as a Buchungssatz with a Sachkonto, a Gegenkonto, a BU-Schlüssel, a Belegfeld, a cost-centre dimension, and the receipt archived so it survives a Betriebsprüfung.

Pleo ships a native DATEV export, and for one German entity on a plain chart of accounts it is often enough. The work begins where that export stops: several entities, mandatory Kostenstelle and Kostenträger on every line, out-of-pocket reimbursements that need personal accounts, foreign suppliers that are reverse-charge rather than 19% input tax, wallet funding that has to reconcile against the bank statement, and receipts that turn up four days after the transaction. A real integration closes that gap continuously instead of once a month.

What data moves

Pleo object or event	Becomes in DATEV	Notes
Settled card expense	Expense booking against the Pleo wallet account	Only settled amounts, never the pending authorisation
Expense category / account code	Sachkonto in SKR03 or SKR04	Mapped once with your Kanzlei, including partially deductible accounts
Receipt image or PDF	Beleg in DATEV Unternehmen online	Delivered via the DATEV Rechnungsdatenservice, linked to the booking
Tags (team, project, entity)	KOST1 / KOST2	Cost centre and cost object per line, not per batch
Extracted VAT amount and rate	BU-Schlüssel	Reviewed against supplier country and service type, not taken on trust
Out-of-pocket reimbursement / mileage	Booking against the employee’s Kreditor account	Or handed to payroll where reimbursement runs through Lohn
Wallet top-up from the house bank	Geldtransit posting	Lets wallet and bank account reconcile independently
FX markup and card fees	Nebenkosten des Geldverkehrs	Booked separately from the expense they arose on
Pleo Invoices vendor bill	Kreditor invoice with open-item reference	Belegfeld 1 carries the invoice number for OPOS matching

The exact accounts, tax keys, clarification account, and cost-centre scheme are agreed once with your tax advisor and encoded in the pipeline. Nobody maps them again by hand.

The details that break naive exports

• Authorisation is not settlement. A card transaction first appears with an authorised amount. Hotel holds, tips, and foreign-currency purchases settle at a different figure days later. Booking the first number and never revisiting it leaves a wallet account that drifts by a few euros a week and nobody can explain by year end.
• Expenses keep changing. A receipt is uploaded on Thursday, the bookkeeper recategorises on Friday, an admin adds a project tag the week after. A delta sync keyed on creation date misses all of it. The pipeline has to track the last modification and re-emit a correction, and it has to know which accounting period is still open before it does.
• Receipt files are the slow part. Expense records are cheap to read; the attached documents are individual downloads, and a month-end backfill of several thousand has to be paced against Pleo’s rate limits rather than fired off in parallel.
• German deductibility rules do not live in Pleo. Bewirtungskosten split 70 / 30 between deductible and non-deductible, gifts above the statutory threshold move to a non-deductible account, and Kleinbetragsrechnungen up to 250 euro carry less mandatory data than a full invoice. These are DATEV-side account decisions that a generic category mapping cannot express.
• VAT on foreign receipts. A SaaS invoice from Ireland is reverse charge under section 13b UStG, an Italian restaurant receipt carries VAT you cannot reclaim in Germany, and an intra-community goods purchase needs its own key. Optical extraction from the receipt gets the number right and the treatment wrong.
• Idempotency and period locks. Re-running an export double-books the month. Every Pleo expense carries a stable identifier that the pipeline records, so a retry, a partial failure, or a re-run never produces a second booking, and corrections to a closed period are routed to the open one instead.
• Partial failures must not ship silently. If eleven expenses in a batch of four hundred hit an unmapped category, we do not deliver a quietly incomplete batch. Those lines are quarantined and flagged while the rest posts on time.

How we build and run it

We treat this as a pipeline, not a monthly chore. Expenses, receipts, reimbursements, and wallet movements are read from Pleo on a schedule, validated, enriched with your agreed coding, and delivered into DATEV as a booking batch and as documents in DATEV Unternehmen online, matching whichever route your Kanzlei actually works with.

The pipeline is idempotent by construction: each Pleo expense has a stable identifier and a version, so nothing is booked twice and later changes arrive as explicit corrections. It runs on cloud-native, fully EU-hosted AWS infrastructure, so receipts and employee data never leave the EU. That keeps the DPA / AVV with your tax advisor and your GDPR position straightforward rather than something you have to argue for.

Then we keep it running. Monitoring, alerting, incident response, and watching for Pleo and DATEV API changes are contractually ours. You get a named owner and an SLA, at a price agreed before the build starts.

When this integration is worth building

If ten cards produce a hundred domestic expenses a month, all with receipts, all in euro, one entity, one cost centre, then Pleo’s own export and a disciplined bookkeeper are the right answer and we will tell you that. The integration earns its place once headcount and card volume grow, once you run more than one entity or need cost-centre reporting that finance actually trusts, once a meaningful share of spend is foreign-currency or reverse-charge, or once your Kanzlei is billing you every month to repair an export that should have arrived correct.