DATEV and ServiceNow integration

What moves between them

The flow runs from ServiceNow into DATEV. ml-connector reads approved supplier invoices and their line items from the ServiceNow Source-to-Pay tables and submits them into DATEV: the booking lines go in as an EXTF CSV batch to Rechnungswesen or a DXSO XML job to Unternehmen Online, and the invoice PDF is uploaded as a document against the matching DATEV document type. Vendor master records move the same direction so each booking references a valid DATEV creditor account. DATEV finalized bookings are write-only and the chart of accounts cannot be read back, so ml-connector never pulls journal entries out of DATEV into ServiceNow; the cadence follows your posting schedule, typically daily or per close.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the ServiceNow side it requests an OAuth client-credentials token and refreshes it before the 1800-second expiry, then pages the Table API with sysparm_query on sys_updated_on so each cycle reads only invoices changed since the last run. On the DATEV side it must hold a real user session, so the tax advisor or client completes the PKCE consent once with a state value of at least 20 characters, after which ml-connector refreshes the 900-second token using the client_id alone. Each ServiceNow invoice is mapped to a DATEV client id, a debit and credit GL account, a tax code, and a cost center, because DATEV cannot return its chart of accounts, the account map is configured up front rather than discovered. Booking files are written as UTF-8 with precomposed characters and deterministic filenames so DATEV's duplicate check on filename plus document type makes a re-submission safe. Document types are fetched per client before any PDF upload rather than hardcoded. Since neither system pushes events, ml-connector polls the DATEV job endpoint with exponential backoff after each submission and confirms completion before marking the invoice booked. ServiceNow has no idempotency header, so reads are deduplicated on the invoice sys_id and a BullMQ jobId. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A German precision-engineering company with around 250 employees runs its procurement and accounts-payable approvals in ServiceNow Source-to-Pay, while its external Steuerberater keeps the books in DATEV. Before the integration, an accountant exported approved vendor invoices from ServiceNow each week, retyped the booking lines into a DATEV EXTF file by hand, and emailed the PDFs separately for the tax advisor to file. With DATEV and ServiceNow connected, each approved invoice is submitted to DATEV as a booking and its PDF lands in Unternehmen Online against the correct document type, allocated to the right account, tax code, and cost center. The weekly re-keying is gone, and the tax advisor receives clean booking data without chasing missing documents.

What you can do

• •Submit approved ServiceNow Source-to-Pay supplier invoices into DATEV as EXTF booking batches or DXSO suggestion jobs.
• •Upload the original invoice PDF into DATEV Unternehmen Online against the correct per-client document type.
• •Keep DATEV creditor accounts aligned with the vendor master held in ServiceNow core_company.
• •Bridge ServiceNow OAuth client credentials with DATEV's user-session OAuth and PKCE, refreshing both token types before expiry.
• •Poll each DATEV job to completion with backoff and dedup, with a full audit trail and replay on every record.

Questions

Which direction does data move between DATEV and ServiceNow?

The flow is ServiceNow into DATEV. Approved supplier invoices, their line items, and vendor records move from the ServiceNow Source-to-Pay tables into DATEV as bookings and uploaded documents. DATEV finalized bookings are write-only and its chart of accounts cannot be read through the API, so ml-connector does not pull journal entries back into ServiceNow.

How does the integration deal with DATEV requiring a real user login?

DATEV has no machine-to-machine flow, so the tax advisor or client signs in once through login.datev.de using OAuth Authorization Code with PKCE and grants the application access. ml-connector then holds the resulting refresh token and renews the 900-second access token automatically, sending only the client_id on refresh. The consent screen is shown to whoever manages the DATEV account.

Since neither system has webhooks, how does the sync stay current?

Both sides are polled. ml-connector reads ServiceNow on a schedule using a Table API query filtered on sys_updated_on so each cycle picks up only newly approved invoices, and after submitting a booking it polls the DATEV job status endpoint with exponential backoff until the job completes or fails. A ServiceNow admin can optionally add a Business Rule that pushes a trigger, but polling is the default.