DATEV and Mailchimp integration

What moves between them

The flow runs from Mailchimp into DATEV. ml-connector reads Mailchimp e-commerce orders and the customers attached to them, then posts the order revenue, tax, and totals into DATEV as finalized bookings through EXTF CSV import jobs, mapped to the GL revenue and tax accounts you configure. Where an invoice PDF exists, it is uploaded to DATEV Unternehmen Online as an outgoing-invoice document against the same client. Customer records flow the same direction so debtor data in the booking file reflects storefront buyers. DATEV has no general ledger that can be read back and Mailchimp has no ledger at all, so ml-connector only writes into DATEV and never posts financial entries back into Mailchimp.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Mailchimp side it sends the API key over HTTP Basic auth or an OAuth 2 bearer token, resolves the data center prefix once at connection time, and pages through orders with offset and count until total_items is exhausted. Because Mailchimp e-commerce orders are best read in bulk rather than pushed, the order sync is poll-based on the cadence you set; the audience webhooks Mailchimp does offer carry no signature, so they are not trusted for financial work. On the DATEV side it runs the PKCE login with a state value of at least twenty characters, refreshes the 900-second access token using the client_id alone, and looks up the DATEV client id before any write. Mailchimp order data is mapped into EXTF CSV fields, with the order total and tax total split across the debit and credit accounts and the tax code you assign, since DATEV cannot return its own chart of accounts for lookup. Each EXTF file is submitted as an async job and polled with exponential backoff until it completes, because DATEV sends no callback. DATEV rejects duplicate EXTF files by filename and document type with error DCO01253, so ml-connector builds a stable, deterministic filename per order and pairs it with a BullMQ jobId, which keeps a re-read Mailchimp order from booking twice. Document uploads use the idempotent PUT with a supplied GUID, and the document type is fetched per client first because valid types differ by DATEV client. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A small German direct-to-consumer brand, roughly twenty staff, sells through an online store and runs its marketing, audience, and e-commerce order data in Mailchimp, while its tax advisor keeps the books in DATEV. Before the integration, a bookkeeper exported the month's orders from Mailchimp, retyped the sales and VAT totals into a DATEV booking batch by hand, and emailed invoice PDFs to the advisor separately, which left revenue posted late and VAT figures that did not always match the store. With DATEV and Mailchimp connected, each order's revenue and tax post into DATEV as a booking within the sync window, the invoice PDF is filed in DATEV Unternehmen Online against the same client, and the customer detail rides along. The advisor opens the period with sales already booked and the manual retyping gone.

What you can do

• •Post Mailchimp e-commerce order revenue and tax into DATEV as finalized bookings through EXTF CSV import jobs.
• •Upload the matching invoice PDFs into DATEV Unternehmen Online as outgoing-invoice documents per client.
• •Map Mailchimp order totals and tax to the DATEV GL and tax accounts you assign, since DATEV cannot return its chart of accounts.
• •Bridge Mailchimp OAuth 2 or API-key auth to DATEV's PKCE login and refresh the 900-second token automatically.
• •Poll DATEV async jobs to completion and dedupe on the order id and a stable EXTF filename to prevent double bookings.

Questions

Which direction does data move between DATEV and Mailchimp?

The flow is Mailchimp into DATEV. E-commerce order revenue, tax, and customer detail move from Mailchimp into DATEV as bookings, and invoice PDFs are uploaded to DATEV Unternehmen Online. Mailchimp has no general ledger and finalized DATEV bookings cannot be read back, so ml-connector only writes into DATEV and never posts entries back into Mailchimp.

How does the integration handle DATEV having no webhooks and a short token life?

DATEV sends no event notifications, so ml-connector submits each EXTF booking as an async job and polls the job status endpoint with exponential backoff until it completes or fails. The DATEV access token lasts only 900 seconds, so ml-connector refreshes it automatically using the client_id alone, as DATEV requires, and keeps the Mailchimp side on its non-expiring token.

What stops a Mailchimp order from being booked into DATEV twice?

DATEV detects duplicate EXTF files by filename and document type and returns error DCO01253 on a repeat. ml-connector builds a stable, deterministic filename for each Mailchimp order and pairs it with a BullMQ jobId, so re-reading the same order through Mailchimp's offset pagination never produces a second booking. Invoice document uploads also use the idempotent PUT with a supplied GUID.