DATEV and JAGGAER integration

What moves between them

The main flow runs from JAGGAER into DATEV. After an invoice is approved in JAGGAER, ml-connector reads the invoice header and line items from the J1P API, builds a DATEV EXTF CSV booking batch or a DXSO XML booking suggestion, and submits it as a DATEV job, while uploading the invoice PDF to Unternehmen Online as an incoming-invoice document (Rechnungseingang). Purchase order references travel with each booking so the entry ties back to its JAGGAER PO. Vendor and customer master data is carried inside the EXTF file as creditor and debtor rows rather than through a separate DATEV endpoint. Cadence is scheduled and polling-based, tied to a posting calendar, because neither side offers a usable push for this path. Posted DATEV journals are write-only, so ml-connector never reads financial entries back from DATEV into JAGGAER.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For JAGGAER it requests a client-credentials token from the J1p-integrations Keycloak realm on the customer's instance host and refreshes it about every hour. For DATEV it carries the user-consented OAuth tokens from Login mit DATEV, refreshes the 15-minute access token using the client_id alone (never the client_secret), and sends the X-DATEV-Client-Id header on every request. Each approved JAGGAER invoice is converted into DATEV's required shape: amounts split into the EXTF Umsatz and Soll/Haben debit-credit indicator, document number into Belegfeld 1, posting text, tax code, and cost center, with the EXTF CSV written as NFC-normalized UTF-8 because non-precomposed characters are silently rejected. Because DATEV cannot return its chart of accounts, each JAGGAER GL coding line is mapped to a DATEV GL account and cost center configured in advance, so every posting lands on a valid account. Submission is asynchronous: ml-connector sends the EXTF or DXSO job, then polls the job status endpoint with exponential backoff and jitter from about 5 seconds up to 60, since DATEV sends no webhooks. Duplicate EXTF files are rejected by filename and document type (error DCO01253), so ml-connector generates stable deterministic filenames that make a retry safe, and on the JAGGAER side it relies on deduplication by supplier invoice number. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A German wholesale distributor with around 300 staff runs procurement in JAGGAER ONE and has its books kept by an external tax advisor on DATEV. Before the integration, the accounts-payable team approved supplier invoices in JAGGAER, then exported them and emailed spreadsheets and PDFs to the tax advisor, who re-keyed each invoice into DATEV and filed the document by hand. Invoices arrived late in the ledger, GL coding drifted between the two systems, and every month-end close started with a backlog of unbooked payables. With DATEV and JAGGAER connected, each approved invoice becomes a DATEV booking batch and a filed Unternehmen Online document the same day, coded to the GL account and cost center set up in the mapping. The advisor reviews booking suggestions instead of typing them, and month-end starts with payables already in the ledger.

What you can do

• •Turn approved JAGGAER supplier invoices into DATEV EXTF CSV booking batches or DXSO XML booking suggestions automatically.
• •Upload each JAGGAER invoice PDF into DATEV Unternehmen Online as an incoming-invoice document tied to the booking.
• •Map every JAGGAER GL coding line to a DATEV GL account and cost center configured in advance, since DATEV cannot return its chart of accounts.
• •Bridge JAGGAER client-credentials tokens and the DATEV user-consent PKCE login, refreshing each on its own short lifetime.
• •Submit DATEV jobs and poll their status with backoff, using deterministic filenames so a retry never double-posts.

Questions

Which direction does data move between DATEV and JAGGAER?

The main flow is JAGGAER into DATEV. Approved supplier invoices and their purchase order references move from JAGGAER into DATEV as booking jobs, and the invoice PDF is filed in DATEV Unternehmen Online. Posted DATEV journals are write-only over the API, so ml-connector does not read financial entries back from DATEV into JAGGAER.

How does the integration post into DATEV when DATEV has no real-time booking API?

DATEV accepts finalized bookings only as asynchronous file jobs, so ml-connector builds an EXTF CSV batch for Rechnungswesen or a DXSO XML booking suggestion for Unternehmen Online and submits it as a job. DATEV returns a job id and sends no webhook, so ml-connector polls the job status endpoint with exponential backoff until it reports complete or failed. Stable, deterministic filenames make a re-submission safe, because DATEV rejects duplicate files by filename and document type.

How are GL accounts handled when DATEV will not return its chart of accounts?

DATEV does not expose its full chart of accounts over the API, so the GL accounts and cost centers cannot be discovered automatically. Instead, each JAGGAER GL coding line is matched to a DATEV account and cost center you configure once in the mapping. Every booking ml-connector submits then references an account that already exists in DATEV, which keeps the coding consistent across both systems.