Stripe DATEV integration

What a Stripe to DATEV integration actually does

Stripe knows everything about the money: the charge in euros or dollars, the per-transaction fee, the refund two days later, the dispute that pulled funds back with a 15 EUR dispute fee, the payout that lands in your bank account on Thursday bundling four hundred charges into one net figure. DATEV, and the tax advisor working inside it, needs all of that expressed as bookings - the right account, the right tax key, the right posting date, and a clean split between the revenue and the money that actually reached the bank.

The gap between those two worlds is where the work lives. A Stripe to DATEV integration closes it automatically: it reads each relevant event from Stripe, treats the balance transaction as the ledger of record, applies your accounting logic, and hands DATEV a clean booking batch your Kanzlei can import without touching a spreadsheet.

What data moves

Stripe object / event	Becomes in DATEV	Notes
Successful charge / PaymentIntent	Revenue booking, split by VAT rate	Coded to the correct SKR03 / SKR04 revenue account per tax treatment
Stripe Tax lines	Correct tax key (Steuerschlüssel / BU-Schlüssel)	Domestic 19% / 7%, EU OSS, reverse-charge, third-country export
Stripe / application fee	Expense booking (payment fees)	Per-transaction; netted inside the payout, booked gross
Refund / partial refund	Reversing booking	Same accounts and tax keys as the original charge, dated to the refund
Dispute / chargeback + dispute fee	Reversal plus separate fee expense	Funds withdrawn and the fixed dispute fee are two distinct lines
Payout	Clearing-account settlement (Geldtransit)	One net payout reconciled against its underlying balance transactions
Currency conversion	FX difference booking	Presentment vs settlement amount posted separately
Stripe Billing invoice / subscription	Revenue with debtor reference	Recurring charges carry the invoice and customer as the booking reference

The exact account numbers, tax keys, and clearing accounts 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

A Dashboard CSV or a generic connector app gets you 80% of the way and leaves the expensive 20% on your desk:

• The payout is not the revenue. A Stripe payout is a net figure that spans many charges, minus fees, minus refunds and dispute deductions, settled days later. Book the payout as revenue and nothing reconciles. The sale, the fee, and the settlement must be separate bookings joined by a clearing account, driven off Stripe’s balance-transaction ledger rather than the charge list.
• Fees are per transaction, not per payout. Stripe deducts its fee on each charge, but you only see the aggregate in the payout. To reconcile to the cent you have to book each fee against its charge and prove that gross sales minus fees minus refunds equals the payout.
• Currency. Stripe can present a charge in one currency and settle it in another. The presentment amount, the settlement amount, and the conversion spread are three different numbers, and only the settlement figures belong in a euro-denominated DATEV batch. The FX difference needs its own booking.
• Tax keys. A 19% domestic sale, a 7% reduced-rate item, an EU B2C sale under OSS, and an export to Switzerland are four different tax keys. Get one wrong and the advance VAT return (Umsatzsteuervoranmeldung) is wrong. Where Stripe Tax is off, the tax treatment has to be derived from the customer’s country and status instead.
• Disputes and reserves. A chargeback withdraws funds and adds a fixed dispute fee, sometimes reversed weeks later if you win. Stripe reserves and negative balances move money without a matching sale. Each needs its own posting logic, not a lump in “other”.
• Idempotency. Re-run a naive export and you book the period twice. A pipeline has to know it already posted a given balance transaction and never emit it again.

How we build and run it

We treat this as a pipeline, not a batch job. Stripe charges, refunds, disputes, fees, and payouts are pulled on a schedule (or by webhook), reconciled against the balance-transaction ledger, validated, transformed into your agreed DATEV coding, and written out as a DATEV-Format booking batch - or delivered through the DATEV Rechnungsdatenservice into DATEV Unternehmen online where that suits your Kanzlei’s workflow.

The pipeline is idempotent: every Stripe object carries a stable identifier, so a retry or a re-run never produces a duplicate booking, and a payout only closes once its underlying transactions all balance. It runs on cloud-native, fully EU-hosted AWS infrastructure, so payment and customer data never leaves the EU - which keeps the DPA / AVV with your tax advisor and your GDPR obligations clean.

And then we keep it running. Monitoring, alerting, incident response, and - critically - tracking Stripe API versions and DATEV format changes are our responsibility under contract. Stripe pins your account to an API version and ships breaking changes behind new ones; keeping the pipeline current with that is our job. You get a named owner and an SLA rather than a script somebody has to remember to run.

When this integration is worth building

If you take a handful of euro charges a month at a single VAT rate with no refunds, exporting the Stripe balance report and booking it by hand is genuinely fine, and we will tell you so. The integration earns its place when volume climbs, when you charge across currencies, when refunds and disputes make each payout a reconciliation puzzle, when Stripe Billing subscriptions need debtor-level bookings, or when your tax advisor is charging you to untangle payouts that a pipeline should have delivered correctly in the first place.