Does this integration copy accounting data into Jira?

No. Jira has no GL accounts, invoices, or vendor records, so no financial ledger data is written into it. ml-connector copies only the workflow context, such as the DATEV job id, client, and error code, that an accountant needs to act on a failed booking. The actual bookings stay in DATEV.

How are DATEV job failures detected without webhooks?

DATEV does not send outbound events, so ml-connector polls the EXTF and DXSO job status endpoints after each submission using exponential backoff with jitter. When a job returns a failed status, a Jira issue is created and deduplicated by an external id custom field. Repeated polls of the same job never open a second ticket.

What happens when a Jira issue is marked done?

When an issue transitions to the configured done status, the inbound Jira webhook triggers ml-connector to resubmit the corrected DATEV booking file and poll the new job to completion. Because DATEV rejects duplicate files by filename plus document type, resubmissions use stable deterministic filenames so the retry is safe. The result is recorded in the audit trail.

DATEVJira

DATEV and Jira integration

DATEV runs German accounting and tax bookkeeping. Jira tracks the work that people do about it. This connection uses Jira as the exception and approval layer around DATEV's asynchronous booking jobs. When a DATEV EXTF or DXSO file import comes back failed, ml-connector raises a Jira issue carrying the job id, DATEV client, and error code so an accountant can act on it. When that issue reaches a configured done status, the corrected booking file is resubmitted to DATEV and polled to completion. Jira holds no financial records, so no GL data is copied into it; only the status and context needed to run the workflow moves.

How DATEV works

DATEV is on-premise accounting (Rechnungswesen) plus a cloud document layer (Unternehmen Online). It is not a conventional REST API: finalized bookings are submitted as EXTF CSV jobs and booking suggestions as DXSO XML jobs, each accepted asynchronously and then polled at a job status endpoint until complete or failed. A small REST surface lists clients and uploads documents. Auth is OAuth 2.0 authorization code with PKCE against login.datev.de, with 15 minute access tokens and refresh using client_id only. DATEV has no outbound webhooks, and posted journal entries and the full chart of accounts cannot be read back.

How Jira works

Jira Cloud is a project and issue tracker reached through the REST API v3, using JSON over standard HTTP methods. It authenticates with OAuth 2.0 3LO or with basic auth using an email and API token, and OAuth calls first resolve a cloudId from the accessible-resources endpoint. Issues, projects, comments, and transitions are the core objects; the description field uses Atlassian Document Format rather than plain text. Jira does push events: webhooks for issue created, updated, and similar events are signed with HMAC-SHA256 in the X-Hub-Signature header, and REST-registered webhooks expire after 30 days and must be refreshed.

What moves between them

Records move in both directions but only workflow context crosses, never financial ledger data. From DATEV to Jira: when polling a submitted EXTF or DXSO job returns a failed status, ml-connector creates a Jira issue with the job id, client id, error code, and file reference, and adds comments as later polls report progress. From Jira to DATEV: when that issue transitions to a configured done status, ml-connector resubmits the corrected booking file to DATEV and polls the new job to completion. Cadence on the DATEV side is poll based, since DATEV pushes nothing; the Jira side reacts to issue webhooks in near real time, with polling as a fallback when a webhook expires.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For DATEV it runs the PKCE authorization code flow, sends the Authorization bearer plus the X-DATEV-Client-Id header on every call, and refreshes the 15 minute access token with client_id only. For Jira it runs 3LO OAuth, resolves the cloudId once at connect time, and writes descriptions in Atlassian Document Format. DATEV job failures are discovered by polling with exponential backoff and jitter, since there are no DATEV webhooks; each failed job id maps to one Jira issue, deduplicated by an external id custom field so a repeated poll never opens a second ticket. Inbound Jira webhooks are verified by recomputing the HMAC-SHA256 digest over the raw body and comparing it constant-time, and a refresh job extends the 30 day webhook TTL before it lapses. A Jira transition to the configured done status drives a fresh DATEV file submission. Gotchas handled: DATEV EXTF files must be UTF-8 NFC with whitelisted filename characters and are rejected as duplicates by filename plus document type, so resubmissions use stable deterministic filenames; Jira custom field ids differ per instance and are mapped at connect time; failed submissions are retried with backoff and every step is recorded for replay.

A real-world example

A regional accounting firm in Bavaria handles monthly bookkeeping for about 120 SMB clients in DATEV and runs its internal work in Jira. Before the integration, when a batch booking import failed in DATEV, no one saw it until someone happened to check the job list, and corrections were tracked in spreadsheets and email. With DATEV and Jira connected, every failed EXTF or DXSO job opens a Jira issue tagged with the client and error code the moment polling detects it, so a bookkeeper picks it up the same day. After the file is corrected, moving the issue to Done resubmits it to DATEV and confirms the booking posted, and the audit trail shows who fixed what and when.

What you can do

Open a Jira issue automatically when a DATEV EXTF or DXSO booking job comes back failed on polling.
Attach the DATEV job id, client id, and error code to each issue so the failure is actionable without leaving Jira.
Resubmit a corrected DATEV booking file when its Jira issue reaches a configured done status, then poll it to completion.
Bridge DATEV PKCE login and Jira 3LO OAuth, refreshing the short-lived DATEV token and resolving the Jira cloudId.
Verify Jira webhook signatures, dedupe issues by an external id custom field, and replay any failed submission.

Questions

Does this integration copy accounting data into Jira?: No. Jira has no GL accounts, invoices, or vendor records, so no financial ledger data is written into it. ml-connector copies only the workflow context, such as the DATEV job id, client, and error code, that an accountant needs to act on a failed booking. The actual bookings stay in DATEV.
How are DATEV job failures detected without webhooks?: DATEV does not send outbound events, so ml-connector polls the EXTF and DXSO job status endpoints after each submission using exponential backoff with jitter. When a job returns a failed status, a Jira issue is created and deduplicated by an external id custom field. Repeated polls of the same job never open a second ticket.
What happens when a Jira issue is marked done?: When an issue transitions to the configured done status, the inbound Jira webhook triggers ml-connector to resubmit the corrected DATEV booking file and poll the new job to completion. Because DATEV rejects duplicate files by filename plus document type, resubmissions use stable deterministic filenames so the retry is safe. The result is recorded in the audit trail.

Connect DATEV and Jira

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started