# Klarna DATEV integration

*Klarna → DATEV*

**In short:** A Klarna to DATEV integration turns each captured order, refund, and Klarna settlement into correctly coded bookings your tax advisor can import as a Buchungsstapel. Because Klarna pays out later and net of fees, each sale is booked against a Klarna receivable or clearing account and cleared only when the matching settlement lands - with transaction fees posted separately and the payout reconciled to the cent. Done properly it is not a CSV from the Merchant Portal but a daily, idempotent pipeline that keeps DATEV in sync with Klarna without anyone re-keying figures at month-end.

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

## Frequently asked questions

### Can I not just download the Klarna settlement report and import it into DATEV?

For a low volume of orders it works. It breaks down once you post regularly, because the Merchant Portal report is a payout view, not a bookkeeping view. It nets many orders, refunds, and fees into one figure, carries no chart-of-accounts logic or tax keys, and gives you no protection against importing the same settlement twice. Every download becomes manual work in Excel before your Kanzlei will touch it.

### How do you handle the gap between the sale and Klarna paying out?

The sale and the money arriving are two separate events, and with Klarna they can be days or weeks apart. We book the revenue when the order is captured and post it against a Klarna receivable or clearing account (Verrechnungskonto Klarna). When the settlement pays out, we clear that account against the bank, matching gross sales minus refunds minus Klarna fees to the netted payout so the bank booking reconciles exactly.

### Does Klarna carry the VAT detail you need, or do you need my shop system?

Klarna's order lines include a tax rate and tax amount per line, which is enough to code most domestic sales correctly. Where you need the customer's country or B2B tax status to drive OSS or reverse-charge treatment, we join the Klarna data to your shop or ERP as the source of truth. We agree that split with your Steuerberater up front so nothing is coded on a guess.

### What happens with refunds, chargebacks, and disputes?

Each is booked as its own event with its own date. A refund reverses the original revenue accounts and tax keys and flows back through the Klarna clearing account. Chargebacks and dispute fees are posted as separate expense and clearing lines so the settlement still reconciles. Nothing is silently netted away, which is what makes the Klarna account tie out at month-end.

### Who operates the integration after it goes live?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor. If Klarna changes its Settlements API or DATEV changes an import format, that is our problem to fix under contract, not a surprise your finance team finds at close. You get a named owner, alerting, and an SLA rather than a report someone has to remember to pull and clean up.

## Related integrations

- [Mollie ↔ DATEV](https://seamless.engineering/integrations/mollie-datev/): Mollie DATEV integration
- [PayPal ↔ DATEV](https://seamless.engineering/integrations/paypal-datev/): PayPal DATEV integration
- [Stripe ↔ DATEV](https://seamless.engineering/integrations/stripe-datev/): Stripe 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