DATEV and Deel integration

What moves between them

The flow runs from Deel into DATEV. Each pay cycle ml-connector reads Deel billing invoices, Deel-fee invoices, and contractor worker invoices, plus the cost figures inside payroll and contract payloads, and assembles them into a DATEV EXTF booking batch that posts into DATEV Rechnungswesen as expense and payable bookings against the matching GL accounts and cost centers. The source invoice and payslip PDFs are downloaded from their temporary Deel URLs and uploaded into DATEV Unternehmen Online as documents so each booking has a receipt attached. Worker and contract changes from Deel keep the creditor and employee references aligned. Because finalized DATEV bookings are write-only, ml-connector never reads posted journals back into Deel.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Deel side it sends the organization bearer token, or refreshes the 30-day OAuth2 token and adds the x-client-id header, and pages invoices with the limit and offset parameters. On the DATEV side it runs the OAuth 2.0 PKCE flow, where the tax advisor or client must consent interactively, sends the X-DATEV-Client-Id header on every call, and refreshes the 15-minute access token using only the client_id. It first fetches the DATEV client id and the client-specific document types, which are never hardcoded. Deel invoice and payroll lines are mapped to DATEV GL accounts and cost centers, since DATEV does not return its chart of accounts, so accounts are configured up front. The EXTF CSV is written in NFC-normalized UTF-8 with a deterministic filename, because DATEV rejects duplicates by filename and document-type and silently drops non-precomposed characters. Each import is submitted as a job and polled with exponential backoff, since DATEV sends no push. Deel webhooks, verified by HMAC-SHA256, trigger a sync as soon as an invoice or worker event lands, while a scheduled poll backfills anything missed. Deel POST and PATCH calls carry an Idempotency-Key and a BullMQ jobId dedupes work, so a re-read invoice is not booked twice.

A real-world example

A 200-person German software company hires engineers across several countries through Deel as employer of record and pays domestic contractors through Deel as well, while its tax advisor keeps the books in DATEV. Before the integration, a bookkeeper downloaded each Deel invoice and payslip every month, retyped the labor costs into a DATEV booking batch, and attached the PDFs by hand, which delayed the close and left the cost centers inconsistent between months. With DATEV and Deel connected, each cycle's Deel invoices and payroll costs post into DATEV Rechnungswesen as bookings on the right accounts and cost centers, and the receipts upload into DATEV Unternehmen Online automatically. The manual re-keying is gone and the labor accounts are ready when close begins.

What you can do

• •Post Deel billing, fee, and contractor invoices into DATEV Rechnungswesen as EXTF booking batches.
• •Upload Deel invoice and payslip PDFs into DATEV Unternehmen Online as documents tied to each booking.
• •Map Deel payroll and invoice lines to DATEV GL accounts and cost centers configured up front.
• •Bridge the Deel bearer token and the interactive DATEV OAuth 2.0 PKCE login with automatic token refresh.
• •Trigger on Deel HMAC-verified webhooks and poll each DATEV import job to completion with retries and a full audit trail.

Questions

Which direction does data move between DATEV and Deel?

The flow is Deel into DATEV. Deel invoices, payroll costs, and worker references move into DATEV as EXTF bookings and uploaded documents, and the creditor and employee records are kept aligned. Finalized DATEV bookings are write-only and DATEV does not return posted journals through its API, so ml-connector never writes financial entries back into Deel.

How does ml-connector handle DATEV having no webhooks and asynchronous bookings?

DATEV sends no push notifications, so every EXTF or DXSO import is submitted as a job and polled with exponential backoff until it completes or fails. Deel webhooks, verified by HMAC-SHA256, trigger a sync the moment an invoice or worker event arrives, and a scheduled poll backfills anything missed. The EXTF file uses a deterministic filename so a retry is safe, since DATEV rejects duplicates by filename and document type.

How are Deel costs mapped to DATEV accounts when DATEV does not expose its chart of accounts?

DATEV does not return its standard chart of accounts through the API, so the GL accounts and cost centers are configured in ml-connector up front. Deel invoice and payroll lines are then mapped to those accounts and written into the EXTF batch with debit and credit account numbers and cost centers. Document types are fetched per client before any PDF upload rather than hardcoded.