DATEV and Zendesk integration

What moves between them

The flow runs in two parts. Account data flows from Zendesk into DATEV: when a Zendesk organization is created or updated, ml-connector aligns it to the matching DATEV client and carries the company name, address, and tax details into the creditor and debtor master rows of the EXTF file. Billable support activity also flows from Zendesk into DATEV: a billable, solved Zendesk ticket becomes an invoice document uploaded to DATEV Unternehmen Online and a booking submitted as an EXTF CSV or DXSO XML job. Nothing financial flows back to Zendesk, because Zendesk has no invoice, purchase order, or general ledger object and DATEV will not return posted journal entries. The Zendesk organization external_id holds the DATEV client id so each record resolves to the correct company.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Zendesk side it runs the OAuth2 authorization code flow against the customer's subdomain and sends the bearer token on every call, scoping each request to that subdomain since Zendesk has no global endpoint. On the DATEV side it runs OAuth2 authorization code with PKCE, where code_challenge_method must be S256, the state value must be at least twenty characters, and a real DATEV user session is required because there is no machine-to-machine flow; it refreshes the fifteen-minute access token using client_id only, never the client_secret. Organizations are matched to DATEV clients first, with the DATEV client id stored in the Zendesk organization external_id, so every booking references a client that already exists. To capture tickets promptly, ml-connector takes the Zendesk webhook as a trigger, verifying the X-Zendesk-Webhook-Signature HMAC over timestamp plus body, and a scheduled incremental export backfills anything a webhook missed. Because DATEV is pull-only and asynchronous, each EXTF or DXSO submission returns a job id that ml-connector polls with exponential backoff and jitter until the job reports complete or failed. EXTF files are written as UTF-8 with precomposed (NFC) characters and deterministic filenames, since DATEV rejects duplicates on filename plus document type, which makes a re-submission retry-safe. Document types are fetched per DATEV client before upload rather than hardcoded, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A German managed IT services firm with about ninety staff runs Zendesk for its customer support desk and DATEV through its tax advisor for the books. Support engineers log billable hours and out-of-contract work as Zendesk tickets, and at month end an accounts clerk read each solved ticket, typed an invoice, and hand-keyed the booking into DATEV, which was slow and produced totals that did not always match the support records. With DATEV and Zendesk connected, each billable ticket marked solved uploads its invoice PDF to DATEV Unternehmen Online and submits the booking as an EXTF job against the right client, while organization changes keep the customer master aligned. The clerk reviews instead of re-types, the invoices tie back to the tickets that produced them, and month-end billing stops being a manual scramble.

What you can do

• •Align each Zendesk organization with its matching DATEV client and keep the customer master in step.
• •Turn a billable, solved Zendesk ticket into a DATEV Unternehmen Online invoice document and a booking job.
• •Submit bookings as EXTF CSV or DXSO XML jobs and poll each job id to completion, since DATEV has no webhooks.
• •Bridge Zendesk OAuth2 and DATEV OAuth2 with PKCE, refreshing the short DATEV token without the client secret.
• •Trigger on Zendesk webhooks with HMAC verification, backfill by incremental export, and keep a full audit trail with replay.

Questions

Which direction does data move between DATEV and Zendesk?

Data moves from Zendesk into DATEV. Organization records align to DATEV clients, and billable solved tickets become invoice documents and bookings submitted to DATEV. Nothing financial moves back to Zendesk, because Zendesk has no invoice, purchase order, or general ledger object and DATEV does not return posted journal entries through its API.

How can the integration sync invoices when Zendesk has no invoice object?

Zendesk holds support and account records, not financial ones, so ml-connector reads a billable, solved ticket and its organization, then builds the accounting side on DATEV. It uploads the invoice PDF to DATEV Unternehmen Online through the accounting:documents API and submits the matching booking as an EXTF CSV or DXSO XML job. The Zendesk organization external_id carries the DATEV client id so the booking lands against the correct company.

Does DATEV confirm a booking right away, or does ml-connector have to wait?

DATEV processing is asynchronous and pull-only, so there is no instant confirmation and no webhook. Each EXTF or DXSO submission returns a job id, and ml-connector polls the job status endpoint with exponential backoff and jitter until it reports complete or failed. Files use deterministic filenames and precomposed UTF-8 so a retry after a timeout does not create a duplicate.