Mollie DATEV integration

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.