# Mollie DATEV integration

*Mollie → DATEV*

**In short:** A Mollie to DATEV integration turns the money side of Mollie into a booking batch your Steuerberater can import. Each payment is booked to a PSP clearing account (Geldtransit), Mollie's per-transaction and monthly fees are booked as expense with a reverse-charge tax key because Mollie B.V. is a Dutch supplier, and refunds and chargebacks are reversed on their own dates. The Mollie settlement is the anchor: every payout nets many payments minus fees, refunds, and chargebacks, and the pipeline reconciles it to the cent against your bank booking so nothing is re-keyed at month-end.

## What a Mollie to DATEV integration actually does

Mollie is a payment service provider, not a shop. It knows how the money moved: a customer paid EUR 89 by iDEAL, another EUR 240 by credit card, one was refunded, one direct debit bounced back as a chargeback three weeks later, and on Thursday Mollie paid the net of all of it into your bank account minus its fees. DATEV, and the person doing your books inside it, needs that expressed as bookings: money to a clearing account, fees to an expense account with the right tax key, refunds and chargebacks reversed on the right dates, and the settlement payout reconciled against the bank.

The gap between "Mollie moved the money" and "the books are correct and reconcile" is the work. A Mollie to DATEV integration closes it automatically: it reads payments, settlements, refunds, chargebacks, and fees from the Mollie API, applies your accounting logic, and hands DATEV a clean booking batch your Kanzlei imports without opening a spreadsheet.

## What data moves

| Mollie object / event | Becomes in DATEV | Notes |
| --- | --- | --- |
| Payment (`tr_…`, paid) | Booking to PSP clearing account (Geldtransit), against the open item | Matched to the receivable via order ID / description in Mollie metadata, per payment method |
| Settlement (`stl_…`, paid out) | Bank booking clearing the Geldtransit account | The reconciliation anchor - one payout nets many payments minus fees, refunds, chargebacks |
| Transaction fees + monthly invoice | Expense booking (Nebenkosten des Geldverkehrs) | Reverse-charge tax key (§13b UStG) because Mollie B.V. is a Dutch supplier |
| Refund (`re_…`) | Reversing booking against clearing | Dated to the refund, reduces the settlement it falls into |
| Chargeback (`chb_…`) | Reversal + separate chargeback-fee expense | Card / SEPA Direct Debit; can arrive weeks after the payment |
| Settlement period breakdown | Per-method revenue and cost lines | Mollie splits each settlement by month and payment method |
| Foreign-currency payment | Booking plus FX difference (Kursdifferenz) | When the processing currency differs from the settlement currency |

The exact accounts, 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 CSV out of the Mollie dashboard, or a generic connector, gets you most of the way and leaves the expensive part on your desk:

- **The settlement is the unit, not the payment.** Mollie does not pay out each payment individually. It bundles payments, subtracts refunds, chargebacks, and fees, and sends one net amount days later under a settlement reference (like `1234567.1808.03`). Book the net payout as revenue and nothing reconciles. Gross payments go to a clearing account; fees, refunds, and chargebacks come off it; the net clears against the bank.
- **Reverse charge on Mollie fees.** Mollie is a Dutch company. Its fees are an intra-EU B2B service, so they carry a reverse-charge tax key under §13b UStG, not domestic input VAT. A plugin that books them like a German invoice quietly distorts your advance VAT return.
- **Matching payments to open items.** A Mollie payment only reconciles if it can be tied to the right receivable. That depends on a stable order ID or invoice number living in Mollie's `metadata` or description. When that reference is missing or inconsistent, matching is manual - so we lock the mapping down as part of scoping.
- **Late chargebacks and reversals.** A SEPA Direct Debit chargeback can arrive up to eight weeks after the payment; card disputes later still. A one-off export never sees them. A delta sync has to keep watching, reverse the original booking, and re-open the item without touching the already-closed period.
- **Rounding and multi-currency.** Per-transaction fees summed by hand rarely equal the settlement total to the cent, and a payment processed in one currency but settled in another needs an FX-difference booking. Both are silent sources of "off by a few cents" that block a clean close.
- **Idempotency.** Payment, refund, chargeback, and settlement IDs are all stable. The pipeline records what it has already booked, so a retry or a re-run never posts the same settlement twice.

## How we build and run it

We treat this as a pipeline, not a batch job. Mollie payments, settlements, refunds, chargebacks, and fees are pulled from the Mollie API on a schedule (or by webhook), 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.

The pipeline is idempotent: every Mollie object carries a stable identifier, so a retry or a late chargeback never produces a duplicate booking. 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 - watching for Mollie and DATEV API changes are our responsibility under contract. You get a named owner and an SLA, not a script somebody has to remember to run. The month-end close stops depending on anyone reconciling a settlement export by hand.

## When this integration is worth building

If you take a handful of Mollie payments a month through a single method and your advisor happily reconciles the dashboard export, a manual process is genuinely fine and we will tell you so. The integration earns its place when transaction volume climbs, when you run several payment methods, when SEPA Direct Debit chargebacks and refunds make settlement reconciliation a monthly chore, when you settle across currencies, or when your tax advisor is charging you to clean up Mollie imports that a pipeline should have delivered correctly in the first place.

## Frequently asked questions

### Is Mollie the source of my revenue bookings, or just the payments?

Mostly the payments. In most setups your shop or invoicing system defines the revenue and the tax treatment, and Mollie tells you when and how the money actually arrived. A Mollie to DATEV integration therefore focuses on the money side: matching incoming payments to open items (offene Posten), booking Mollie fees, and reconciling each settlement payout to the bank. If you use Mollie standalone for payment links or invoices, we can also derive the receivable from the payment itself.

### Why do you book to a clearing account instead of straight to the bank?

Because a Mollie payment and the money landing in your bank are two different events, often days apart. Mollie collects many payments, deducts fees, subtracts refunds and chargebacks, and pays out one net settlement later. We book each payment to a Geldtransit / Verrechnungskonto when it is paid, then clear that account when the settlement hits the bank. That is the only way the bank booking reconciles to the cent.

### How are Mollie's fees treated for VAT?

Mollie B.V. is based in the Netherlands, so its transaction and monthly fees to a German business are an intra-EU B2B service under the reverse-charge scheme (§13b UStG). We book them to a bank-charges expense account with the correct reverse-charge tax key, not as domestic input VAT. Getting this wrong is one of the most common findings when a tax advisor reviews a manual Mollie import.

### What about chargebacks and failed SEPA direct debits that arrive weeks later?

They are handled as their own events. A card or SEPA Direct Debit chargeback can land weeks after the original payment, so the pipeline runs a delta sync that catches late chargebacks and reversals, reverses the original clearing booking, re-opens the receivable, and books the chargeback fee separately. Because it is idempotent, a late event never disturbs a period that was already reconciled.

### Which DATEV target do you deliver into?

Whichever your Kanzlei works with. Usually we produce a booking batch in DATEV-Format (the EXTF/DTVF Buchungsstapel that DATEV Kanzlei-Rechnungswesen imports), coded to your SKR03 or SKR04 accounts, and where it suits the workflow we deliver documents via the DATEV Rechnungsdatenservice into DATEV Unternehmen online. We agree accounts, tax keys, and clearing accounts with your tax advisor up front.

## Related integrations

- [Klarna ↔ DATEV](https://seamless.engineering/integrations/klarna-datev/): Klarna 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