DATEV and Tradeshift integration

What moves between them

The main flow runs from Tradeshift into DATEV. ml-connector reads inbound supplier invoices and credit notes from the Tradeshift inbox, converts each UBL document into a DATEV DXSO XML booking suggestion, and uploads the matching invoice file to Unternehmen Online under the correct client-specific document type. Supplier and tax-code references are aligned so each booking suggestion lands on a valid creditor account and VAT key inside DATEV. Finalized bookings to the Rechnungswesen engine are write-only and the DATEV ledger cannot be read back, so ml-connector never pulls posted journal entries out of DATEV or writes accounting data back into Tradeshift.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Tradeshift side it signs each request with the OAuth 1.0a consumer and token secrets and sends the tenant UUID in the X-Tradeshift-TenantId header on every call. On the DATEV side it runs the OAuth 2.0 Authorization Code flow with PKCE, using an S256 code challenge and a state value of at least 20 characters, then refreshes the 15-minute access token with the client_id only and never the secret. Because both systems are pull-only, it polls the Tradeshift document list with a changedAfter timestamp for new invoices and credit notes, and polls each DATEV job until it reports complete or failed, backing off with jitter since DATEV publishes no processing times. Each UBL invoice is parsed and mapped to a DXSO booking suggestion and a document upload, with suppliers and tax codes resolved first, because DATEV document types are client-specific and the chart of accounts is not readable, so those must be configured up front. DATEV rejects EXTF files that are not NFC-normalized and detects duplicates by filename plus document type, so ml-connector generates stable filenames and dedupes on the Tradeshift document UUID and a BullMQ jobId to keep a re-read invoice from booking twice. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A German manufacturing firm with around 200 staff receives most of its supplier invoices electronically through a Tradeshift buyer account, and its external tax advisor keeps the books in DATEV. Before the integration, a clerk downloaded each invoice from Tradeshift and emailed batches to the advisor, who keyed the bookings into DATEV by hand, so invoices sat for days and the same document was occasionally booked twice. With DATEV and Tradeshift connected, each inbound invoice flows in as a DXSO booking suggestion with the PDF uploaded to Unternehmen Online, mapped to the right creditor and VAT code, ready for the advisor to confirm. The manual download-and-email step is gone, duplicates are caught on the document UUID, and the advisor reviews clean suggestions instead of typing them.

What you can do

• •Read inbound supplier invoices and credit notes from the Tradeshift inbox and submit them into DATEV as DXSO XML booking suggestions.
• •Upload each Tradeshift invoice file to DATEV Unternehmen Online under the correct client-specific document type.
• •Map Tradeshift suppliers and tax data to DATEV creditor accounts and VAT keys so each booking suggestion is valid.
• •Bridge Tradeshift OAuth 1.0a signing and the tenant header to DATEV OAuth 2.0 with PKCE and its 15-minute tokens.
• •Poll both pull-only systems on a schedule, dedupe on the document UUID and jobId, and keep a full audit trail on every record.

Questions

Which direction does data move between DATEV and Tradeshift?

The main flow is Tradeshift into DATEV. Inbound supplier invoices and credit notes move from the Tradeshift inbox into DATEV as DXSO XML booking suggestions plus uploaded documents in Unternehmen Online. DATEV finalized bookings are write-only and the ledger cannot be read back, so ml-connector does not pull posted entries from DATEV or write accounting data into Tradeshift.

How does the integration handle the different auth on each side?

ml-connector stores both credential sets encrypted and bridges them per request. Tradeshift uses OAuth 1.0a, so every call is signed and carries the X-Tradeshift-TenantId header for the company UUID. DATEV uses OAuth 2.0 Authorization Code with PKCE and short 900-second tokens, so ml-connector refreshes the access token with the client_id only and keeps a valid session for each submitted job.

Do DATEV or Tradeshift push events, or does ml-connector poll?

Both systems are pull-only, so ml-connector polls. It reads the Tradeshift document list with a changedAfter timestamp to pick up new invoices and credit notes, since Tradeshift has no traditional webhooks. On the DATEV side it polls each submitted booking or document job until it reports complete or failed, backing off with jitter because DATEV does not document processing times or send notifications.