DATEV and Adobe Commerce integration

What moves between them

The flow runs one way, from Adobe Commerce into DATEV. ml-connector reads sales orders, the invoices captured against them, and credit memos from Adobe Commerce, then writes them into DATEV as booking entries. Captured invoices and refunds become EXTF CSV booking batches posted to DATEV Rechnungswesen, or DXSO XML booking suggestions sent to DATEV Unternehmen Online, with revenue and receivable accounts, tax codes, and cost centers filled in. The invoice PDF for each order uploads to DATEV Unternehmen Online as an outgoing-invoice document. Cadence follows your booking schedule, typically daily or per close, since DATEV is built for periodic batch submission, not high-frequency polling. Nothing flows back from DATEV, because finalized bookings and the chart of accounts cannot be read through the API.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Adobe Commerce side it signs each PaaS request with the OAuth 1.0a tokens or requests and refreshes an IMS OAuth 2.0 bearer token for the Cloud Service before it expires, and it scopes every call to the right store view. The DATEV side is the harder bridge: its OAuth requires an interactive login with a code_challenge using S256, a state value of at least 20 characters, and a nonce, and the 15-minute access token is refreshed by sending the client_id only, never the client_secret. Each call carries the Bearer token plus the X-DATEV-Client-Id header, and the DATEV client id comes from the clients API and becomes the path parameter for every booking job. Sales records are read from Adobe Commerce by paging through searchCriteria with total_count, then transformed into DATEV's exact formats: EXTF CSV must be UTF-8 with precomposed (NFC) characters or DATEV rejects it silently, and DXSO XML must validate against DATEV's XSD. GL accounts and document types matter here. DATEV does not return its chart of accounts, so the revenue, receivable, and tax accounts are mapped during setup, and document types are client-specific, so ml-connector fetches the allowed types before any PDF upload rather than hardcoding them. Submission is asynchronous: ml-connector submits a job, receives a job id, and polls with exponential backoff and jitter starting near 5 seconds and capped near 60, because DATEV does not publish processing times. Idempotency is handled per channel. EXTF files dedupe on a stable filename plus document type, so ml-connector generates deterministic filenames to make retries safe and to avoid DATEV duplicate error DCO01253, document uploads use the idempotent PUT with a supplied GUID, and a BullMQ jobId built from the Adobe Commerce increment_id guards against re-reading the same order, since Adobe Commerce has no idempotency header. Every record carries a full audit trail and can be replayed if a downstream job fails.

A real-world example

A mid-sized German consumer-goods seller, roughly eighty staff, sells through an Adobe Commerce storefront and has its books kept by an outside tax advisor on DATEV. Before the integration, a bookkeeper exported the month's orders and invoices to CSV, reworked them by hand into DATEV's booking layout, and emailed PDFs of the invoices to the advisor, who chased mismatched tax codes and missing receipts before every VAT filing. With DATEV and Adobe Commerce connected, each captured invoice and refund posts into DATEV as a booking on the correct revenue and tax accounts, the invoice PDF lands in DATEV Unternehmen Online against the same client, and the advisor opens a period that already balances. The manual re-keying and the receipt chase are gone.

What you can do

• •Post Adobe Commerce captured invoices and credit memos into DATEV as EXTF CSV or DXSO XML bookings.
• •Upload each order's invoice PDF into DATEV Unternehmen Online against the matching DATEV client and document type.
• •Map Adobe Commerce totals and tax to DATEV revenue, receivable, and tax accounts, since DATEV does not expose its chart of accounts.
• •Bridge Adobe Commerce OAuth to DATEV's interactive OAuth login with PKCE and a 15-minute, auto-refreshed token.
• •Submit booking jobs and poll them to completion, with deterministic filenames, increment_id dedup, retries, and a full audit trail.

Questions

Which direction does data move between DATEV and Adobe Commerce?

Data moves one way, from Adobe Commerce into DATEV. Captured invoices and credit memos become DATEV bookings, and the invoice PDFs upload to DATEV Unternehmen Online. DATEV's finalized bookings and chart of accounts cannot be read through the API, so nothing flows back to the storefront.

How are DATEV bookings submitted, given there are no webhooks?

Bookings are submitted as asynchronous file jobs, EXTF CSV to DATEV Rechnungswesen or DXSO XML to DATEV Unternehmen Online. DATEV does not push status, so ml-connector submits a job, gets a job id, and polls with exponential backoff and jitter until the job reports complete or failed. EXTF files dedupe on filename plus document type, so ml-connector uses stable filenames to keep retries safe.

How does the integration handle DATEV's login and GL accounts?

DATEV uses OAuth 2.0 Authorization Code with PKCE and an interactive user login, so the tax advisor or client consents once, and ml-connector then refreshes the 15-minute token using the client_id only. DATEV does not return its chart of accounts, so the revenue, receivable, and tax accounts are mapped during setup and applied to every booking. Document types are also client-specific and are fetched before any PDF upload.