DATEV and Looker integration

What moves between them

The flow runs from Looker into DATEV. ml-connector runs the Looker queries or saved Looks that model your general ledger and financial summaries, then maps each result row into a DATEV booking line: amount, debit or credit indicator, debit and credit accounts, document date, document number, tax code, and cost centers. Those lines are submitted to DATEV as an EXTF CSV booking batch for finalized postings, or as a DXSO XML job when you want a reviewable booking suggestion in DATEV Unternehmen Online. Supporting PDFs can be uploaded to DUO through the documents API alongside the bookings. Cadence is scheduled, typically aligned to your close calendar, since neither system emits real-time change events. DATEV cannot return posted journals, so nothing is written back into Looker.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Looker side it accepts the full instance URL per customer, exchanges the API3 key for a token at the login endpoint, sends it with the token scheme, and re-authenticates when a call returns 401 since Looker issues no refresh token. On the DATEV side it carries the user's OAuth session obtained through the PKCE login, attaches the Bearer access token and the X-DATEV-Client-Id header, and refreshes the 15-minute token using the client id alone. It first looks up the DATEV client id, then fetches the client-specific document types before any upload, because those values differ per client and cannot be hardcoded. Looker columns are mapped to DATEV accounts, cost centers, and tax codes up front, and because DATEV cannot return its chart of accounts, those account numbers are configured in advance. Each EXTF file uses a stable deterministic filename so a retry is not rejected as a duplicate, and the CSV is written as NFC-normalized UTF-8 to avoid silent rejection. After submission ml-connector polls the DATEV job with exponential backoff and jitter, and Looker query results are capped at 5000 rows per call, so large extracts are chunked by offset or run as async query tasks. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized professional services group of around 300 staff runs its operational and revenue data in BigQuery and reports on it in Looker, while its German entity keeps the statutory books in DATEV through an outside tax advisor. Each month an accountant exported revenue and cost summaries from Looker, reformatted them into a DATEV booking layout in a spreadsheet, and handed the file to the advisor, who then keyed the batch into DATEV. The hand-off was slow, the spreadsheet drifted from the LookML model, and close slipped when figures did not tie out. With DATEV and Looker connected, ml-connector runs the same Looker queries on a schedule, maps each line to the agreed DATEV accounts and cost centers, and submits the EXTF batch as an import job the advisor reviews. The manual reformatting step is gone and the books reflect the modeled numbers each period.

What you can do

• •Run modeled GL and financial summary queries in Looker and submit the results into DATEV as EXTF booking batches.
• •Post reviewable booking suggestions to DATEV Unternehmen Online as DXSO jobs when a finalized batch is not wanted.
• •Map Looker result columns to DATEV accounts, cost centers, document numbers, and tax codes on every booking line.
• •Bridge Looker's one-hour API3 token and DATEV's interactive OAuth PKCE login, refreshing each as it expires.
• •Poll DATEV import jobs to completion with backoff, deterministic filenames for safe retries, and a full audit trail.

Questions

Which direction does data move between DATEV and Looker?

Data moves from Looker into DATEV. ml-connector runs queries in Looker to pull modeled GL and financial summaries, then writes them into DATEV as EXTF booking batches or DXSO booking suggestions. Looker holds no native financial records to receive and DATEV cannot return posted journals, so nothing is written back into Looker.

Can ml-connector read finished bookings back from DATEV into Looker?

No. DATEV finalized bookings sent to DATEV Rechnungswesen are one-way and write-only, and the chart of accounts is not exposed through the API. For that reason the DATEV account numbers and cost centers are configured in advance and mapped to Looker columns, rather than read from DATEV at runtime.

How does the integration handle authentication on each side?

Looker exchanges an API3 client id and secret for a one-hour token sent with the token scheme, and ml-connector re-authenticates on a 401 since there is no refresh token. DATEV uses OAuth 2.0 Authorization Code with PKCE, so a tax advisor or client approves access once, after which ml-connector refreshes the 15-minute access token automatically using the client id.