DATEV and TrueCommerce integration

What moves between them

The main flow runs from TrueCommerce into DATEV. ml-connector polls the TrueCommerce SFTP drop for inbound documents, then maps incoming supplier invoices and remittance advices into DATEV as EXTF CSV booking batches against the right GL accounts, and uploads the matching invoice PDFs or e-invoices into DATEV Unternehmen Online. Outbound sales invoices flow the other direction: ml-connector writes them as flat files to the TrueCommerce SFTP drop so TrueCommerce can translate them into X12 810s and deliver them to the trading partner. Cadence is scheduled on both ends, typically hourly or daily, since neither DATEV nor TrueCommerce pushes events. Posted DATEV journal entries cannot be read back, so DATEV is treated as a write target for bookings.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For DATEV it runs the OAuth2 PKCE flow with an S256 code challenge, a state value of at least twenty characters, and a nonce, sends the Authorization bearer token and the X-DATEV-Client-Id header on every call, and refreshes the token with the client_id only before the 900-second window closes. For TrueCommerce it connects to the hosted SFTP server with the provisioned username and password and reads the inbound and outbound directories agreed during onboarding. Inbound X12 documents are translated by TrueCommerce into flat files, which ml-connector maps into EXTF CSV rows, taking care to write UTF-8 with precomposed (NFC) characters because non-normalized text is silently rejected, and to fetch each client's document types before uploading since they vary per client. EXTF jobs are submitted asynchronously and polled with exponential backoff and jitter from about five seconds up to about sixty. The DATEV chart of accounts cannot be read through the API, so GL accounts and document types are mapped during setup. Duplicate EXTF files are detected by filename and document type, so ml-connector uses stable deterministic filenames to make retries safe, and every record carries a full audit trail and can be replayed if a job fails.

A real-world example

A mid-sized German consumer goods supplier sells to several large grocery retailers that mandate EDI, and runs its books in DATEV through its tax advisor. Before the integration, a clerk logged into the TrueCommerce portal each morning, printed the incoming retailer purchase orders and supplier invoices, and typed the totals into DATEV by hand, then exported finished sales invoices and re-uploaded them for EDI delivery. With DATEV and TrueCommerce connected, inbound invoices arrive as DATEV booking batches with the PDFs filed in Unternehmen Online, and outbound invoices are dropped to TrueCommerce as flat files that become X12 810s for each retailer. The daily re-keying is gone, and the monthly handoff to the tax advisor starts from data that is already posted and filed.

What you can do

• •Turn inbound TrueCommerce supplier invoices and remittance advices into DATEV EXTF booking batches against the correct GL accounts.
• •Upload the matching invoice PDFs and e-invoices into DATEV Unternehmen Online, fetching each client's document types first.
• •Write outbound DATEV sales invoices as flat files to the TrueCommerce SFTP drop for translation into X12 810s.
• •Bridge DATEV OAuth2 PKCE login and 15-minute tokens to the TrueCommerce SFTP credentials provisioned at account setup.
• •Poll both systems on the schedule you set, with deterministic filenames, retries, and a full audit trail on every record.

Questions

Which direction does data move between DATEV and TrueCommerce?

The main flow is TrueCommerce into DATEV, where inbound supplier invoices and remittance advices become DATEV booking batches and document uploads. Outbound sales invoices travel the other way as flat files that TrueCommerce translates into X12 810s for the trading partner. Posted DATEV journal entries cannot be read back through the API, so DATEV is treated as a write target for bookings rather than a read source for the ledger.

Does TrueCommerce connect directly to the retailer, or only to DATEV?

TrueCommerce is middleware that sits between your ERP and the trading partner, so ml-connector connects to the TrueCommerce network rather than to each retailer. ml-connector exchanges flat files with the TrueCommerce SFTP drop, and TrueCommerce handles the X12 translation and delivery to the trading partner. The customer provides their EDI ISA ID and the trading partner's ISA ID during onboarding so TrueCommerce can route documents correctly.

How does the integration cope with DATEV having no webhooks and no readable chart of accounts?

Because DATEV sends no events, ml-connector submits EXTF and DXSO file jobs and then polls the job status endpoint with exponential backoff until it completes or fails. The standard DATEV chart of accounts cannot be retrieved through the API, so GL accounts and the client-specific document types are mapped once during setup and reused on every booking. TrueCommerce is also pull-based over SFTP, so both sides are driven by a schedule you control rather than by push notifications.