DATEV and Airbase integration

What moves between them

The flow runs from Airbase into DATEV. ml-connector reads approved vendor bills, reimbursed employee expenses, and settled corporate card transactions from Airbase, maps each line to the matching DATEV GL account and tax code, and submits the results as EXTF CSV booking batches to DATEV Rechnungswesen or as DXSO XML jobs to DATEV Unternehmen Online. The original invoice PDFs are uploaded as documents into DUO so each booking has its receipt attached. Vendor master records ride along inside the EXTF creditor rows. Cadence is scheduled, typically per close period, because neither side is built for high-frequency polling. Finalized DATEV bookings are write-only, so nothing posts back into Airbase.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Airbase side it sends the portal bearer token against the tenant base URL captured per customer; on the DATEV side it runs the OAuth Authorization Code with PKCE login once, then refreshes the 15-minute access token automatically using only the client_id. Approved Airbase spend is read on a schedule, since the relevant DATEV calls are pull-only and the chart of accounts cannot be fetched back, so GL accounts and tax codes are mapped from a configured table rather than discovered. Each booking becomes an EXTF CSV batch or a DXSO XML job; document types are fetched per DATEV client before any PDF upload because they vary by client. EXTF files use NFC-normalized UTF-8 and deterministic filenames so DATEV's filename-plus-type duplicate check makes re-submission safe. After submission ml-connector polls the job status with exponential backoff until it reports complete or failed, and every record carries an audit trail that can be replayed if a job fails.

A real-world example

A 180-person software company with a German GmbH subsidiary runs its books in DATEV through an external Steuerberater and manages all company spend in Airbase. Before the integration, the finance lead exported approved bills, expense reports, and card statements from Airbase each month, hand-keyed the totals into a DATEV booking batch, and emailed the invoice PDFs to the tax advisor separately, where a wrong GL account or tax code meant a round of corrections at close. With DATEV and Airbase connected, approved spend flows automatically into DATEV as EXTF and DXSO jobs with the receipts already attached in DUO, mapped to the correct accounts. The monthly re-keying disappears and the advisor receives clean, source-linked bookings.

What you can do

• •Post approved Airbase bills, reimbursed expenses, and settled card spend into DATEV as EXTF CSV or DXSO XML booking jobs.
• •Upload the matching invoice PDFs into DATEV Unternehmen Online so every booking keeps its receipt.
• •Map Airbase GL coding to DATEV accounts and tax codes from a configured table, since DATEV cannot return its chart of accounts.
• •Authenticate Airbase with its tenant bearer token and DATEV with OAuth Authorization Code plus PKCE, refreshing the short-lived token automatically.
• •Poll each DATEV job to confirm it posted, with deduplicated re-submission and a full audit trail on every record.

Questions

Which direction does data move between DATEV and Airbase?

The flow is Airbase into DATEV. Approved bills, reimbursed expenses, settled card transactions, and their vendor records move from Airbase into DATEV as booking jobs, with invoice PDFs uploaded to DATEV Unternehmen Online. Finalized DATEV bookings are write-only, so ml-connector does not post accounting entries back into Airbase.

How does ml-connector handle DATEV's lack of webhooks and its async jobs?

DATEV sends no push notifications, so ml-connector submits each booking as an EXTF or DXSO job and then polls the job status endpoint with exponential backoff until it reports complete or failed. Approved Airbase spend is read on a schedule rather than waiting for a push. Deterministic filenames let a failed EXTF submission be retried safely under DATEV's filename-plus-type duplicate check.

Why are GL accounts and tax codes mapped from a table instead of read from DATEV?

DATEV does not expose its full chart of accounts through the API, so the connector cannot discover account numbers at runtime. GL accounts, tax codes, and cost centers are configured once in a mapping table, and ml-connector applies them as it builds each EXTF or DXSO booking. This keeps every posted line on a valid DATEV account without manual correction at close.