DATEV and PayPal integration

What moves between them

The main flow runs from PayPal into DATEV. As PayPal captures complete and refunds settle, ml-connector builds EXTF CSV booking batches and submits them to DATEV Rechnungswesen, with the PayPal fee posted as its own line so the net and the gross both reconcile. PayPal invoice PDFs move the same direction, uploaded into DATEV Unternehmen Online as client-specific documents such as Rechnungsausgang. A periodic PayPal Transaction Search backfill catches anything a webhook missed and lets month-end totals be checked against the PayPal account. Nothing flows back from DATEV into PayPal: DATEV bookings are write-only and posted journal entries cannot be read, so PayPal is never updated from the ledger.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the PayPal side it exchanges the client ID and secret for a bearer token, caches it for its full lifetime, and verifies every inbound webhook by checking the RSA-SHA256 signature against the certificate URL after confirming that URL is a paypal.com host. On the DATEV side it runs the OAuth Authorization Code flow with PKCE, keeps the state value at least twenty characters, and refreshes the 900-second token using the client ID only. PayPal captures and refunds are mapped into EXTF rows: amount, debit and credit accounts, document date, invoice reference, tax code, and the fee as a separate posting. Because DATEV has no webhooks, each EXTF or DXSO submission returns a job ID that ml-connector polls with exponential backoff until the job completes or fails. DATEV detects duplicate EXTF files by filename plus document type, so ml-connector generates stable deterministic filenames to make a retry safe rather than a double-post, and uses PayPal-Request-Id on any PayPal write. Two real edge cases are handled: DATEV document types are client-specific, so the document type list is fetched per client before any upload, and the standard GL account numbers cannot be read from DATEV, so the GL and tax-code mapping is configured up front. Every record carries a full audit trail and can be replayed if a call fails.

A real-world example

A mid-sized German online retailer with about eighty staff sells through its own webshop and takes a large share of orders through PayPal, while its tax advisor keeps the books in DATEV. Before the integration, a bookkeeper exported PayPal activity each week and hand-entered the sales, the refunds, and the per-transaction PayPal fees into DATEV, and the fee lines in particular were easy to miss, which left the PayPal clearing account out of balance at month-end. With DATEV and PayPal connected, every settled capture and refund posts into DATEV as an EXTF booking batch with the fee on its own line, and a weekly Transaction Search backfill confirms the totals. The PayPal clearing account reconciles on its own, and the manual weekly export and re-keying step is gone.

What you can do

• •Post settled PayPal captures and refunds into DATEV as EXTF booking batches against the correct GL accounts and tax codes.
• •Book each PayPal transaction fee as its own line so the gross, fee, and net all reconcile in DATEV.
• •Upload PayPal invoice PDFs into DATEV Unternehmen Online as client-specific documents fetched per client.
• •Bridge PayPal client-credentials tokens and DATEV's OAuth Authorization Code flow with PKCE and 900-second refresh.
• •Confirm every async DATEV import job by polling its status, with deterministic filenames, retries, and a full audit trail.

Questions

Which direction does data move between DATEV and PayPal?

Data moves from PayPal into DATEV. Settled captures, refunds, and fees become EXTF booking batches and PayPal invoice PDFs become DATEV documents. Nothing is written back to PayPal, because DATEV bookings are write-only and posted journal entries cannot be read back through the API.

How does the integration handle DATEV having no webhooks while PayPal pushes events?

ml-connector listens for PayPal webhooks such as PAYMENT.CAPTURE.COMPLETED and INVOICING.INVOICE.PAID and verifies their RSA-SHA256 signatures. DATEV cannot push anything, so each EXTF or DXSO submission returns a job ID that ml-connector polls with exponential backoff until it completes. A periodic PayPal Transaction Search backfill catches any event that was missed.

How are PayPal payments mapped to DATEV GL accounts when DATEV will not return its chart of accounts?

DATEV does not expose its standard chart of accounts through the API, so the GL accounts and tax codes are configured up front in the mapping. Each PayPal capture, refund, and fee is then written to the matching debit and credit account in the EXTF file. Document types for invoice uploads are client-specific and are fetched per DATEV client before any upload.