DATEV and SAP Ariba integration

What moves between them

The flow runs from SAP Ariba into DATEV. ml-connector reads approved supplier invoice headers and the related purchase order data from SAP Ariba reporting jobs, then posts the invoices into DATEV as a booking batch, either an EXTF CSV file to DATEV Rechnungswesen or a DXSO XML booking suggestion to DATEV Unternehmen Online, with each line mapped to the right DATEV GL account, cost center, and tax code. The invoice document itself is uploaded to DATEV Unternehmen Online under the incoming-invoice document type so the booking has its receipt attached. Supplier details from SAP Ariba inform the creditor master data carried in the EXTF file. Both systems are pull-only, so SAP Ariba is read on a schedule and DATEV job status is polled after each submission; nothing is written back into SAP Ariba.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the SAP Ariba side it requests an OAuth2 client-credentials token, caches it for its one hour life, sends the static apiKey header on every call, and appends the realm as a query parameter, submitting reporting jobs in windows no wider than the one-year limit Ariba enforces and paging results with the pageToken cursor. On the DATEV side it runs the interactive Authorization Code flow with PKCE once to obtain a refresh token, then renews the 15 minute access token automatically, sending client_id without the client_secret on each refresh. Because DATEV cannot read its chart of accounts, GL accounts and cost centers are mapped up front so each Ariba invoice line resolves to a valid DATEV account before posting. EXTF files are written as NFC-normalized UTF-8 with deterministic filenames, since DATEV rejects duplicates by filename and document type, which makes a re-submission safe. After submitting a file job, ml-connector polls the DATEV job endpoint with exponential backoff because there is no push confirmation, and it dedupes on the Ariba invoiceId and a BullMQ jobId so a re-read invoice is never booked twice. Document type names are fetched per client before upload rather than hardcoded. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized manufacturing group in Germany with around four hundred staff runs procurement in SAP Ariba and books its accounts in DATEV through its tax advisor. Before the integration, an accounts payable clerk opened each approved supplier invoice in SAP Ariba, typed the header and amounts into a DATEV booking batch by hand, and saved the PDF separately into DATEV Unternehmen Online, which left invoices waiting days at month-end and produced mismatches between procurement and the ledger. With DATEV and SAP Ariba connected, each approved invoice is read from the Ariba reporting job and posted into DATEV as a booking with its document attached, allocated to the correct GL account and cost center per plant. The clerk reviews exceptions instead of re-keying every invoice, and month-end close starts with payables already in the ledger.

What you can do

• •Read approved supplier invoice headers and purchase order data from SAP Ariba reporting jobs.
• •Post those invoices into DATEV as EXTF CSV booking batches or DXSO XML booking suggestions.
• •Upload the SAP Ariba invoice documents into DATEV Unternehmen Online under the incoming-invoice type.
• •Map SAP Ariba accounting codes to valid DATEV GL accounts and cost centers before posting.
• •Bridge Ariba client-credentials plus apiKey auth and DATEV's interactive PKCE login, with retries and a full audit trail.

Questions

Which direction does data move between DATEV and SAP Ariba?

The flow is SAP Ariba into DATEV. Approved supplier invoices and purchase order data are read from SAP Ariba and posted into DATEV as booking batches, with the invoice documents uploaded to DATEV Unternehmen Online. DATEV imports finalized bookings one way and cannot return posted journals, so ml-connector never writes anything back into SAP Ariba.

Can ml-connector write invoices back into SAP Ariba?

No. The SAP Ariba REST Open APIs this connector uses are read-oriented, and invoice and purchase order creation in Ariba go through cXML and SOAP rather than REST. ml-connector reads procurement documents from Ariba reporting jobs and treats it as the source, posting the accounting result into DATEV instead.

How does the integration handle two pull-only systems and DATEV's unreadable accounts?

Both systems are poll-based, so ml-connector reads SAP Ariba reporting jobs on a schedule and polls the DATEV job status endpoint with backoff after each file submission, since neither side pushes events. Because DATEV cannot return its chart of accounts over the API, GL accounts and cost centers are mapped in configuration up front so every Ariba invoice line lands on a valid DATEV account.