DATEV and Stedi integration

What moves between them

The flow runs one way, into DATEV. Stedi pushes a transaction.processed.v2 webhook for each inbound EDI document a partner sends, and ml-connector fetches the translated JSON, then submits it to DATEV. Inbound X12 810 invoices become EXTF CSV booking lines against the correct debit and credit accounts, with the invoice document uploaded into Unternehmen Online as a Rechnungseingang. Inbound X12 850 purchase orders are carried as the document reference and posting text so each booking ties back to its order. Trading-partner detail rides along inside the EXTF file as creditor rows, since DATEV exposes no supplier endpoint. Nothing flows back: DATEV cannot return its chart of accounts or posted journals, and Stedi keeps no records, so DATEV is treated as a write-only accounting destination.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Stedi side it sends the API key on every request and answers each inbound webhook within Stedi's five-second timeout by returning 2xx immediately, then fetches the translated JSON from the documentDownloadUrl using the API key and processes it asynchronously. Inbound events are deduplicated on the Stedi event id so a redelivered webhook does not book the same invoice twice. On the DATEV side it runs the Authorization Code flow with PKCE, where the code challenge must use S256 and the state value is at least 20 characters, then holds the resulting access token, which expires in 900 seconds, and refreshes it by sending only the client_id. Each inbound 810 becomes EXTF CSV rows with Konto, Gegenkonto, Belegfeld 1, Buchungstext, and a tax code, written in UTF-8 with precomposed characters because non-normalized text is silently rejected; filenames are kept deterministic so DATEV's filename-and-document-type duplicate check makes a retry safe. The invoice document is pushed to Unternehmen Online with PUT and a stable GUID, after the client-specific document types are fetched first. Because DATEV processes asynchronously and sends no webhook, ml-connector polls each EXTF or DXSO job with exponential backoff and jitter until it reports complete or failed. The big gotcha is account mapping: DATEV will not hand over its chart of accounts, so each trading partner and the X12 item and charge codes are mapped to known DATEV SKR account and Kostenstelle numbers in advance, and every job is replayable if a submission fails.

A real-world example

A mid-sized German distributor with around 250 staff buys from suppliers that send invoices and order documents as X12 EDI and keeps its statutory books in DATEV through its Steuerberater. Before the integration, an accounts payable clerk pulled each inbound EDI invoice out of a separate translation tool, typed the booking lines into DATEV by hand, and re-attached the invoice in Unternehmen Online, which left invoices waiting days and produced posting and tax-code mistakes the tax advisor had to correct at month-end. With DATEV and Stedi connected, each inbound 810 invoice Stedi parses is submitted to DATEV as an EXTF booking and its document uploaded to Unternehmen Online within the polling window, coded to the right SKR account and cost center. The manual re-keying is gone and the tax advisor receives clean, complete bookings.

What you can do

• •Post Stedi inbound X12 810 invoices into DATEV as EXTF CSV bookings against the correct accounts and tax codes.
• •Upload the inbound invoice document into DATEV Unternehmen Online as a Rechnungseingang using a stable GUID.
• •Carry Stedi 850 purchase order references into DATEV so each booking ties back to its order.
• •Bridge the Stedi Bearer API key to DATEV Authorization Code login with PKCE and 15-minute token refresh.
• •Answer Stedi webhooks within the five-second limit, dedupe on the event id, and poll each DATEV job to completion with retries and a full audit trail.

Questions

Which direction does data move between DATEV and Stedi?

The flow is one way, into DATEV. Inbound EDI invoices and purchase orders that partners send through Stedi move into DATEV as EXTF bookings and uploaded documents. Stedi holds no business records of its own and DATEV cannot return its chart of accounts or posted journals through the API, so DATEV is treated as a write-only accounting destination and nothing is pulled back out.

Does Stedi store the invoices, or just translate them?

Stedi only translates and routes. It parses inbound X12 into JSON and delivers outbound files over SFTP or AS2, but it does not persist vendors, invoices, or accounts. The canonical record lands in DATEV, and ml-connector fetches the translated JSON from the documentDownloadUrl on each Stedi event, since that URL is not public and needs the API key, then writes the booking into DATEV.

How are bookings confirmed if DATEV sends no webhooks?

DATEV processes EXTF and DXSO submissions asynchronously and never calls back. ml-connector submits each file as a job, receives a job id, and polls the job status endpoint with exponential backoff and jitter until it reports complete or failed. Deterministic filenames make a resubmission safe, because DATEV rejects duplicates by filename and document type, and every job can be replayed if a submission fails.