PayPal DATEV integration

What a PayPal to DATEV integration actually does

PayPal knows everything about the money moving through it: the gross payment from a customer, the fee it kept, the refund you issued three days later, the chargeback that appeared a month on, the conversion when a US buyer paid in dollars, and the batched withdrawal that lands in your bank account next week. DATEV, and the tax advisor working inside it, needs all of that as bookings - the right account, the right tax key, the right date, and above all the correct treatment of PayPal as a clearing account rather than a bank.

That last point is where most PayPal accounting goes wrong. A PayPal to DATEV integration closes the gap automatically: it reads each transaction from PayPal, applies your accounting logic, and hands DATEV a clean booking batch your Kanzlei can import without touching a spreadsheet.

What data moves

PayPal transaction	Becomes in DATEV	Notes
Payment received (gross)	Revenue booking against PayPal Verrechnungskonto	Cleared to the Debitor / correct SKR03 or SKR04 revenue account
Tax on the sale	Correct tax key (Steuerschlüssel / BU-Schlüssel)	Domestic 19% / 7%, EU OSS, reverse-charge, third-country
PayPal fee	Expense booking (Nebenkosten des Geldverkehrs)	Split per transaction, not netted into revenue
Refund / partial refund	Reversing booking	Same accounts and tax keys as the original, dated to the refund
Chargeback / dispute	Reversal plus dispute fee	Tracked separately so open cases stay visible
Currency conversion	Realised FX gain / loss	Booked to its own account at the agreed rate
Withdrawal to bank	Geldtransit (PayPal to bank)	Batched payout reconciled to one bank-statement line

The exact accounts, tax keys, and the PayPal 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

The PayPal activity CSV or a generic connector gets you most of the way and leaves the expensive part on your desk:

• PayPal is not a bank account. Booking the withdrawal as if it were revenue double-counts and reconciles to nothing. The gross payment, the fee, and the withdrawal are three separate events that must meet on a PayPal Verrechnungskonto, with the running balance always equal to your PayPal statement.
• Fees are per transaction. PayPal deducts a fee from every payment. Netting it into revenue understates turnover and misstates the fee expense. Each fee has to be split out to Nebenkosten des Geldverkehrs.
• Matching to receivables. PayPal carries only an email, a note, and any invoice_id you pushed through checkout. Clearing a payment against the right open item (OPOS) and Debitor needs that reference threaded through, with a defined fallback when it is missing.
• Multi-currency and FX. A dollar or franc payment sits in a currency balance until conversion. The conversion is its own transaction and produces a realised gain or loss that has to be booked, not ignored.
• Refunds, chargebacks, and reserves. A partial refund must reverse the exact accounts and tax keys of the original on the refund’s date. Chargebacks and dispute fees, and any rolling reserve PayPal holds, each need their own treatment.
• API limits and idempotency. PayPal’s Transaction Search API returns data in windows, with a settlement delay, and only for a limited history. A pipeline has to page through it reliably, and every transaction carries a stable transaction_id so a re-run never books the same payment twice.

How we build and run it

We treat this as a pipeline, not a batch job. PayPal transactions are pulled on a schedule through the Transaction Search / reporting API, validated, transformed into your agreed DATEV coding, and written out as a DATEV-Format booking batch (Buchungsstapel) - or delivered through the DATEV Rechnungsdatenservice where that suits your Kanzlei’s workflow.

The pipeline is idempotent: every PayPal transaction 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 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 changes to the PayPal API and DATEV import formats are our responsibility under contract. Your PayPal balance reconciles itself into DATEV instead of depending on someone remembering to pull an export.

When this integration is worth building

If you take a handful of PayPal payments a month at a single tax rate and rarely refund, a manual export is genuinely fine and we will tell you so. The integration earns its place when volume climbs, when fees and refunds make the PayPal balance a monthly reconciliation chore, when you sell across currencies or across EU borders under OSS, or when your tax advisor is charging you to clean up PayPal exports that a pipeline should have delivered correctly in the first place.