DATEV and Adyen integration
DATEV is the accounting backend German tax advisors and their clients run. Adyen processes card and alternative payments. Connecting the two means each Adyen settlement is turned into a DATEV booking batch instead of being re-keyed from a downloaded report. ml-connector reads Adyen's reconciliation reports and payment events, then writes the gross receipts, refunds, and processor fees into DATEV as a finalized EXTF booking file against the accounts and cost centers you map. Because Adyen has no booking, vendor, or GL records of its own, the integration is built around what Adyen does expose: transactions, refunds, payouts, disputes, and settlement reports.
What moves between them
The flow runs one direction, from Adyen into DATEV. When Adyen fires a REPORT_AVAILABLE webhook, ml-connector downloads the settlement or reconciliation report from its signed URL, parses each line, and assembles the gross receipts, refunds, chargebacks, and processor fees into an EXTF CSV booking batch with debit and credit accounts, document numbers, tax keys, and cost centers. That file is submitted as an async EXTF job to the DATEV Rechnungswesen engine, then polled until it reports complete or failed. Capture, refund, and chargeback events feed the same direction so each clears into the ledger. Every booking line carries the Adyen pspReference as its document reference. DATEV bookings are write-only, so ml-connector never reads journals back and never writes payment instructions into Adyen, which has no such records to receive.
How ml-connector handles it
ml-connector stores both credential sets encrypted and sends the Adyen X-API-Key with the merchant's live URL prefix on every call, while holding the DATEV OAuth session that the tax advisor or client established through the PKCE login, refreshing the 15-minute access token from the refresh token and sending only the client_id, not the secret, on refresh. Incoming Adyen webhooks are verified by recomputing the HMAC-SHA256 signature before anything is queued, and because Adyen can deliver the same notification more than once, the pspReference is used to deduplicate so a transaction is never booked twice. Settlement lines are mapped to DATEV GL accounts by merchant account and fee type, amounts are converted from Adyen minor units, and EXTF text is written as precomposed UTF-8 so DATEV does not silently reject it. Because DATEV has no webhooks and processes imports asynchronously, each EXTF job is polled with exponential backoff and jitter until it finishes. EXTF filenames are generated deterministically so DATEV's duplicate-file check makes a retry safe, and every record carries a full audit trail and can be replayed if a submission fails.
A real-world example
A German online retailer with roughly eighty staff sells through its own web shop, takes card and wallet payments through Adyen, and has its books kept in DATEV by an external Steuerberater. Before the integration, a bookkeeper logged into the Adyen Customer Area each morning, downloaded the prior day's settlement report, and hand-keyed the gross sales, refunds, and processor fees into DATEV against the right SKR accounts, then spent month-end trying to tie the bank deposit back to thousands of individual transactions. With DATEV and Adyen connected, each settlement report becomes an EXTF booking batch automatically, split into receipts, refunds, and fees with the correct tax keys and cost centers, and the Adyen pspReference on every line. Bank reconciliation turns into a match against bookings that are already posted, and the daily download-and-key step is gone.
What you can do
- Turn Adyen settlement and reconciliation reports into DATEV EXTF booking batches, split into receipts, refunds, and processor fees.
- Record Adyen capture, refund, and chargeback events as DATEV bookings with debit and credit accounts, tax keys, and cost centers.
- Carry the Adyen pspReference into the DATEV document reference so each booking line traces back to the originating transaction.
- Verify the Adyen webhook HMAC-SHA256 signature and deduplicate on pspReference before any booking file is built.
- Bridge Adyen's API key and live URL prefix with DATEV's interactive OAuth PKCE login, then submit and poll each async EXTF job to completion.
Questions
- Which direction does data move between DATEV and Adyen?
- Data moves one way, from Adyen into DATEV. Settlement reports and capture, refund, and chargeback events flow from Adyen and are written into DATEV as EXTF booking batches. DATEV bookings are write-only and Adyen has no booking or vendor records, so ml-connector never reads journals back from DATEV and never pushes financial entries into Adyen.
- How does the integration get accounting data out of Adyen if it has no bookings or GL?
- Adyen exposes settlement and reconciliation reports, which are the canonical source for accounting. When Adyen fires a REPORT_AVAILABLE webhook, ml-connector downloads the report from its signed URL, parses each line, and maps the receipts, refunds, and fees to the DATEV GL accounts, tax keys, and cost centers you choose. The Adyen pspReference is carried onto each booking line as the document reference.
- How are Adyen webhooks and DATEV's asynchronous, pull-only design reconciled?
- Adyen pushes signed webhooks, but DATEV has no inbound webhooks and processes bookings as asynchronous file jobs. ml-connector verifies each Adyen HMAC signature, builds an EXTF booking file, submits it as a job, and then polls the DATEV job status with exponential backoff until it reports complete or failed. Deterministic filenames make DATEV's duplicate-file check safe so a failed submission can be retried without double-booking.
Related integrations
More DATEV integrations
Other systems that connect to Adyen
Connect DATEV and Adyen
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started