DATEV and Wise integration

What moves between them

The flow runs from Wise into DATEV. After each payout, ml-connector reads the executed Wise transfer and the matching balance statement lines and writes them into DATEV as an EXTF CSV booking batch, with each line carrying the amount, debit and credit accounts, document date, document number, posting text, currency, and any exchange rate. The payment-confirmation PDF is uploaded to DATEV Unternehmen Online through the documents API. Wise recipients are aligned to DATEV creditor accounts so each payout debits the right vendor, and balance top-ups and fees post to their own accounts. DATEV bookings are write-only and the chart of accounts is not readable, so ml-connector never reads ledger entries back into Wise.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Wise side it requests and refreshes the 12-hour OAuth partner token and sends the profile id on every call. On the DATEV side it carries the access token plus the X-DATEV-Client-Id header, refreshes the 15-minute token sending client_id only, and runs the Authorization Code flow with PKCE and a state value of at least 20 characters, which means the tax advisor consents to access once. A Wise transfer state-change webhook, verified against the RSA-SHA256 signature, is the trigger when a payout reaches outgoing_payment_sent, while the balance update event covers top-ups because the state-change event does not fire for those. ml-connector then builds the EXTF CSV in UTF-8 with precomposed characters, since non-precomposed text is silently rejected, and submits it as a job. Because DATEV has no webhooks, it polls the job endpoint with exponential backoff and jitter until the import clears or fails. Recipient-to-creditor mappings are resolved first so every line lands on a valid account, and deterministic filenames make a re-submission safe, since DATEV rejects a duplicate filename and document type with error DCO01253. The Wise customerTransactionId guards against double payouts on retry, and every record carries a full audit trail with replay if a DATEV job fails.

A real-world example

A mid-sized German software firm of around 150 staff pays overseas contractors and SaaS vendors in several currencies through Wise, and keeps its books in DATEV with its tax advisor. Before the integration, the finance team exported the Wise statement each week and typed every payout, fee, and currency conversion into DATEV by hand, then reconciled the Wise balance against the ledger at month-end and chased the lines that did not agree. With DATEV and Wise connected, each completed payout posts into DATEV automatically as a booking against the matching creditor and bank account, with the confirmation PDF attached in DATEV Unternehmen Online. Month-end starts with the bank movements already booked and the manual statement entry gone.

What you can do

• •Book completed Wise vendor payouts into DATEV as EXTF CSV booking batches against the correct accounts.
• •Post Wise balance top-ups, fees, and currency conversions to their own DATEV accounts from the balance statement.
• •Upload the Wise payment-confirmation PDF into DATEV Unternehmen Online through the documents API.
• •Map each Wise recipient to a DATEV creditor account so every payout debits the right vendor.
• •Trigger on signed Wise webhooks, poll the DATEV job until it clears, and keep a full audit trail with replay.

Questions

Which direction does data move between DATEV and Wise?

The flow is Wise into DATEV. Executed transfers, balance movements, and fees move from Wise into DATEV as booking batches, and the confirmation PDFs are uploaded to DATEV Unternehmen Online. DATEV bookings are write-only and its chart of accounts is not readable over the API, so ml-connector never writes ledger data back into Wise.

Can ml-connector read invoices or GL accounts from Wise?

No. Wise is a payments platform and has no invoices, purchase orders, GL accounts, or cost centers. What it provides is transfers, recipients, balances, and balance statements, and ml-connector maps that payment and statement activity into DATEV booking lines rather than pulling accounting documents that do not exist in Wise.

How does the integration handle DATEV having no webhooks?

Wise pushes a signed transfer state-change webhook when a payout completes, which is the trigger. ml-connector then submits the booking to DATEV as an asynchronous file job and, because DATEV sends no webhooks of its own, polls the job status endpoint with exponential backoff and jitter until the import clears or fails. Deterministic filenames make a retry safe against DATEV's duplicate-file rejection.