DATEV and Twilio integration

What moves between them

Most data moves from DATEV into Twilio as outbound notifications. After ml-connector submits an EXTF or DXSO job and polls it to a result, it creates a Twilio Message or Call that reports the client, the document or batch, and whether the job completed or failed, addressed to the finance contacts in E.164 form. A smaller flow moves from Twilio into DATEV: for a high-risk batch ml-connector starts a Twilio Verify check and waits for the approver's one-time code before it submits the job, and an inbound SMS reply or a delivered status callback can release a held booking. Cadence is poll-driven on the DATEV side and event-driven on the Twilio side, where status and inbound-message callbacks arrive as they happen. Posted journals and the chart of accounts are not readable from DATEV, so ml-connector never tries to mirror the ledger into Twilio.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the DATEV side it runs the OAuth2 PKCE flow, sends the bearer token plus the X-DATEV-Client-Id header on every call, and refreshes the 900-second access token with the client_id alone before it expires. On the Twilio side it calls the REST API with HTTP Basic Auth using the API Key SID and Secret, form-encodes every POST body since Twilio rejects JSON there, and keeps the Auth Token on hand because that token, not the API Key, is the HMAC-SHA1 key used to validate inbound callbacks. Every status and inbound-message webhook is verified by recomputing the signature over the exact URL and the alphabetically sorted POST parameters and comparing it to the X-Twilio-Signature header, and callbacks are accepted only over HTTPS. All destination numbers are normalized to E.164 so a missing plus prefix does not cause a silent failure. Outbound EXTF files are written in NFC-normalized UTF-8 with whitelisted filenames, because non-precomposed characters or stray special characters cause silent rejection, and ml-connector polls the async DATEV job with exponential backoff and jitter rather than waiting for a push DATEV never sends. Twilio rate limiting is concurrency-based and returns HTTP 429, so sends are paced and retried with backoff, and each outbound message is enqueued under a jobId of sms plus the DATEV job id so a retry never sends the same alert twice. Because Twilio does not guarantee exactly-once webhook delivery and status callbacks do not fire under test credentials, inbound events are processed idempotently on a queue, and every action carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A regional logistics firm with about 90 employees keeps its books in DATEV through its tax advisor and has no finance staff sitting at a desk all day. Before the integration, a rejected EXTF booking batch could sit unnoticed for days because the only signal was an email nobody on the road was watching, and large payment runs were submitted with no second check. With DATEV and Twilio connected, every EXTF and DXSO job result is sent as an SMS, a failed booking triggers a voice call to the controller, and a high-risk payment batch is held until the approver enters a Twilio Verify code. The team learns about a failed posting in seconds instead of days, and no large batch reaches DATEV Rechnungswesen without an explicit confirmation from a real person.

What you can do

• •Send a Twilio SMS or place a voice call when a DATEV EXTF or DXSO booking job completes or fails.
• •Require a Twilio Verify one-time code from an approver before a high-risk DATEV batch is submitted.
• •Release a held DATEV booking when the approver replies by SMS or a delivery status callback confirms it.
• •Bridge DATEV OAuth2 PKCE with its 15-minute refresh and Twilio HTTP Basic Auth, validating every callback with the Auth Token.
• •Poll DATEV jobs with backoff while pacing Twilio sends against 429 limits, with jobId dedup and a full audit trail on every action.

Questions

Which direction does data move between DATEV and Twilio?

Most of it moves from DATEV into Twilio as outbound alerts: ml-connector sends an SMS or places a call when an EXTF or DXSO booking job completes or fails. A smaller flow moves the other way, where a Twilio Verify code or an inbound SMS reply confirms or releases a held DATEV booking. DATEV will not return posted journals or its chart of accounts, so ml-connector never mirrors the ledger into Twilio.

Can Twilio store invoices or general ledger postings from DATEV?

No. Twilio is a communications platform with no native invoice, ledger, vendor, or account objects, so it cannot hold accounting records. What it does well is carry SMS, voice, and identity verification, so ml-connector uses it as the alert and approval layer: booking results go out as messages or calls and approvals come back as Verify codes or SMS replies, while DATEV remains the system of record.

How does the integration handle DATEV polling and Twilio's signed callbacks?

DATEV publishes no webhooks, so after submitting an EXTF or DXSO job ml-connector polls the job endpoint with exponential backoff and jitter until it reports complete or failed. Twilio instead pushes status and inbound-message callbacks, so each request is verified by recomputing the HMAC-SHA1 signature over the URL and sorted parameters with the Auth Token and is accepted only over HTTPS. Outbound sends are deduplicated by a jobId built from the DATEV job id, and DATEV access tokens are refreshed before their 15-minute expiry.