Klarna DATEV integration

What a Klarna to DATEV integration actually does

Klarna sits between your customer and your bank account. The customer checks out, Klarna assumes the payment risk, and some days or weeks later Klarna pays you - in a batch, net of its fees, covering many orders at once. In the meantime Klarna owes you money. DATEV, and the tax advisor working inside it, needs all of that expressed as bookings: revenue at the point of sale, a receivable against Klarna, the fee as an expense, and finally the payout cleared against the bank so nothing is left hanging.

The gap between Klarna’s payout logic and DATEV’s booking logic is where the work lives. A Klarna to DATEV integration closes it automatically: it reads each captured order, refund, fee, and settlement from Klarna, applies your accounting logic, and hands DATEV a clean booking batch your Kanzlei can import without opening a spreadsheet.

What data moves

Klarna object / event	Becomes in DATEV	Notes
Captured order	Revenue booking, split by VAT rate, against a Klarna receivable	Coded to the correct SKR03 / SKR04 revenue account per tax treatment
Order tax lines	Correct tax key (Steuerschlüssel / BU-Schlüssel)	Klarna carries a tax rate per line; country and B2B status may come from your shop
Refund / return	Reversing booking through the Klarna clearing account	Same accounts and tax keys as the original, dated to the refund
Klarna transaction fee	Expense booking (Nebenkosten des Geldverkehrs)	Netted out of the payout, so it must be posted separately
Chargeback / dispute fee	Separate expense and clearing line	Kept explicit so the settlement still reconciles
Settlement payout	Clearing-account settlement against the bank	Gross sales minus refunds minus fees matched to the netted payout

The exact account numbers, tax keys, and the Klarna clearing account 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 Merchant Portal 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. Klarna settles net of fees, days or weeks later, in a batch spanning many orders. Booking the payout as revenue reconciles to nothing and hides the fees. The sale and the settlement must be separate bookings joined by a Klarna clearing account.
• The receivable in between. Between capture and payout, Klarna owes you money. If that receivable is not booked, your books show revenue with no matching cash and no way to prove Klarna paid what it owed.
• Fees are netted, not invoiced. Klarna deducts its transaction fee before paying you. The gross sale, the fee, and the net payout all have to be reconstructed from the settlement so the expense lands on the right account.
• Multi-currency. Klarna operates across EU and Nordic markets, so a single merchant can receive payouts in EUR, SEK, DKK, or GBP. Each currency needs its own clearing treatment and exchange-rate handling, not one lumped figure.
• Refunds and chargebacks reverse the original. A refund has to reverse the exact accounts and tax keys of the original order, on the refund’s date, and flow back through the Klarna account - not vanish into a net settlement figure.
• Idempotency. Re-pull a settlement and a naive export books it twice. A pipeline has to know it already posted a given order and settlement and never post either again.

How we build and run it

We treat this as a pipeline, not a batch job. Captured orders, refunds, fees, and settlements are pulled from Klarna’s Settlements and Order Management APIs on a schedule, validated, transformed into your agreed DATEV coding, and written out as a DATEV-Format booking batch (Buchungsstapel) - or delivered through the DATEV Rechnungsdatenservice into DATEV Unternehmen online where that suits your Kanzlei’s workflow.

The pipeline is idempotent: every Klarna order and settlement carries a stable identifier, so a retry or a re-run never produces a duplicate booking. It runs on cloud-native, fully EU-hosted AWS infrastructure, so transaction 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 - watching for Klarna and DATEV API changes are our responsibility under contract. The month-end close stops depending on someone remembering to pull a report and reconcile it by hand.

When this integration is worth building

If you take a handful of Klarna orders a month at a single VAT rate, downloading the settlement report and posting it manually is genuinely fine, and we will tell you so. The integration earns its place when Klarna volume climbs, when payouts in more than one currency make reconciliation a monthly chore, when the receivable and fee split stops tying out on its own, or when your tax advisor is charging you to clean up settlements that a pipeline should have delivered correctly in the first place.