# SAP Concur DATEV integration

*SAP Concur → DATEV*

**In short:** A SAP Concur to DATEV integration turns every approved expense report, card transaction, and supplier invoice into finished bookings in DATEV: each expense type on the right SKR03 or SKR04 account, deductible German input VAT separated from non-recoverable foreign VAT, allocations carried through as KOST1 and KOST2, and the employee reimbursement posted to a personal account that the payment confirmation later clears. Not a monthly extract cleaned up in Excel, but a scheduled, idempotent pipeline that posts once and correctly.

## What a SAP Concur to DATEV integration actually does

Concur is where spend is captured and approved. It knows the traveller, the expense type, the itemised hotel folio, the corporate card feed, the receipt image, the cost centre the manager picked, and the day the report was approved. DATEV is where that spend has to become accounting: an expense account, a tax key, a document reference, a cost centre, and a liability against the employee that a bank booking later clears.

Nothing in Concur is expressed in those terms. An expense type is a business category, not an account number. Concur's tax fields describe what was charged, not what is deductible in a German advance VAT return. An allocation is a percentage, not a KOST1 value. A SAP Concur to DATEV integration performs that translation the same way every time, so the close stops being a re-keying exercise.

## What data moves

| SAP Concur object or event | Becomes in DATEV | Notes |
| --- | --- | --- |
| Approved expense report (header) | One document with the employee's personal creditor account on the credit side | Report ID mapped to a short stable document reference; Belegfeld1 is length-limited |
| Expense entry, by expense type | Expense booking on the mapped SKR03 / SKR04 account | Expense type to account mapping agreed once, then applied automatically |
| Itemisation (hotel folio, for example) | Separate lines for accommodation, breakfast, parking | Different accounts, tax treatment, and deductibility per component |
| Allocation | KOST1 / KOST2 on each line | Percentage splits must resolve to the cent |
| Entertainment expense | Split into deductible and non-deductible portions | German rules treat 70% as deductible while input VAT stays fully recoverable |
| Per diem and mileage | Tax-free reimbursement plus any taxable excess | Meal reductions and the taxable remainder need a defined destination |
| VAT amount per entry | Input VAT via the correct tax key, or expense | Domestic VAT is deductible; foreign VAT is not, and is coded separately |
| Corporate card transaction | Settlement against the card clearing account | Company-paid and employee-paid transactions post differently |
| Cash advance | Advance account, cleared by the report | Prevents double reimbursement |
| Concur Invoice payment request | Creditor booking on the supplier account | Requires supplier numbers that match your DATEV creditor master data |
| Payment confirmation | Clearing of the personal or creditor account | Closes the loop between approval and money leaving the bank |
| Receipt image | Document in DATEV Unternehmen online | Keeps the booking auditable under GoBD |

Accounts, tax keys, cost-centre logic, and the employee-to-account mapping are agreed once with your accounting and your tax advisor and then encoded in the pipeline.

## The details that break naive extracts

A hand-built export from Concur gets the totals roughly right and leaves the expensive parts unsolved:

- **Reports do not stay still.** A report can be sent back, corrected, and re-approved after it appeared in an earlier extract. Keying only on the report identifier means the correction either never arrives or arrives as a duplicate. The pipeline tracks report and entry state, so a change produces a correction rather than a second booking.
- **Domestic and foreign VAT are not the same thing.** A hotel invoice from Munich yields deductible input VAT. The same stay in Vienna does not, at least not in your German return. Treating both as recoverable inflates the claim, treating both as cost quietly gives money away.
- **Allocations round badly.** A single entry split 33 / 33 / 34 across three cost centres produces line amounts that must still add up to the entry total. DATEV rejects the batch when they do not, and it rejects the whole batch, not the offending line.
- **Entertainment and per diems are tax logic, not categories.** The non-deductible share of entertainment, the reduction of per diems when meals were provided, and the taxable portion above the statutory rate all have to land in defined accounts, or payroll and the annual accounts disagree later.
- **Card transactions are settled twice if you are careless.** A company-paid card transaction is not a reimbursement. It clears against the card clearing account, and only the employee-paid portion creates a liability to the employee.
- **API access is not free-form.** Concur APIs are paginated, rate-limited, and authenticated with tokens that rotate. A one-off script works until the token refresh fails on a Friday evening and nobody notices until the close.
- **Booking batches are all or nothing.** A single invalid tax key or an out-of-period posting date fails an entire import. Validation therefore has to happen before the batch is written, not after DATEV rejects it.

## How we build and run it

We build this as a pipeline. Approved reports, card transactions, invoice payment requests, and payment confirmations are pulled from Concur on a schedule, validated against a strict schema, transformed into your agreed DATEV coding, and delivered as a DATEV-format booking batch or through the DATEV document and booking-proposal interfaces where that suits your workflow better. Receipt images travel with the booking, so the document reference in DATEV resolves to a real receipt.

Every report and entry carries a stable identifier, and the pipeline records what it has already posted. A retry or a replay after an outage never produces a second booking, and an amended report produces a correcting posting rather than a silent overwrite. It runs on cloud-native, fully EU-hosted infrastructure. Travel data is personal data, so keeping it inside the EU is what keeps the DPA and your GDPR documentation straightforward.

Then we keep it running. Monitoring, alerting, incident response, and watching for changes to the Concur and DATEV interfaces are our contractual responsibility, with a named owner and an SLA, scoped at a fixed price before anything is built.

## When this integration is worth building

If a handful of people travel occasionally, all spend is domestic, and one person posts the reports in an afternoon each month, you do not need this and we will say so. It earns its place when report volume makes manual posting a recurring multi-day job, when travel crosses borders and VAT treatment stops being uniform, when cost-centre reporting has to be right rather than approximately right, or when finance spends the first week of every month reconciling what Concur approved against what actually got booked.

## Frequently asked questions

### Concur already has a Standard Accounting Extract. Why is that not enough?

The extract is a raw file of report and entry rows, not a booking batch. It carries no chart of accounts, no DATEV tax keys, no KOST1 or KOST2 assignment, and no split between the expense, the recoverable input VAT, and the liability owed to the employee. Someone has to turn each extract into a Buchungsstapel by hand, every month, and repeat the same mapping decisions. The integration encodes those decisions once and applies them automatically.

### How do you handle foreign VAT on travel expenses?

German input VAT on a domestic receipt is booked with the correct tax key and deducted normally. VAT charged in another country cannot go into the German advance VAT return, so it is either booked as part of the expense or parked on a receivable account if you file for a refund under the input VAT refund procedure. Concur's tax configuration tells us the country and the reclaim status per entry, and the coding follows from that rather than from someone eyeballing a receipt.

### Do employees end up as creditors or does this run through payroll?

Both models work and we implement whichever your accounting uses. Most companies post the reimbursement to a personal creditor account per employee, which the payment confirmation from Concur then clears against the bank booking. Where reimbursement runs with the payroll run, the taxable portion of per diems and mileage has to be handed over as a wage type instead, and the tax-free portion still books as an expense. We agree the split with your accounting and your payroll before we build.

### Can the pipeline post cost centres and projects?

Yes. Concur allocations map to the KOST1 and KOST2 fields of the booking batch, including percentage splits across several cost centres on a single entry. Rounding is handled so the split lines always sum back to the entry total to the cent, which is where hand-built imports usually fail their first plausibility check in DATEV.

### Who operates it after go-live?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor, with alerting and incident response under contract. When SAP changes a Concur API version or DATEV changes an import format, that is our work to do, not something your finance team discovers on the day of the close. You get a named owner and an SLA, not a script that lives on somebody'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
- [Spendesk ↔ DATEV](https://seamless.engineering/integrations/spendesk-datev/): Spendesk DATEV integration
- [SAP Concur ↔ NetSuite](https://seamless.engineering/integrations/sap-concur-netsuite/): SAP Concur NetSuite integration
- [Amazon ↔ DATEV](https://seamless.engineering/integrations/amazon-datev/): Amazon DATEV integration
- [Billbee ↔ DATEV](https://seamless.engineering/integrations/billbee-datev/): Billbee DATEV integration

## Browse by system

- [All SAP integrations](https://seamless.engineering/integrations/sap/)
- [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