DATEV and Procurify integration

What moves between them

The main flow runs from Procurify into DATEV. ml-connector reads approved AP bills and their line items from Procurify, along with the linked vendor and account code, and writes each bill into DATEV: a routine finalized booking goes in as an EXTF CSV job to DATEV Rechnungswesen, while an invoice that still needs review goes in as a DXSO XML suggestion to DATEV Unternehmen Online. The invoice PDF is uploaded as a Rechnungseingang document to DATEV Unternehmen Online. Vendor master data from Procurify supplies the creditor rows on the booking. Cadence is scheduled polling against Procurify, since neither system pushes events, typically aligned to how often the AP team approves bills. DATEV bookings are write-only, so ml-connector never reads posted journals back into Procurify.

How ml-connector handles it

ml-connector stores both credential sets encrypted and bridges two unlike auth models: it requests a client-credentials token from the Procurify subdomain and reuses it for its 24-hour life, while it runs the interactive DATEV OAuth flow with PKCE, keeps the refresh token, and renews the 15-minute DATEV access token with client_id alone. Because both systems are poll-only, it runs on a schedule rather than waiting for a push. DATEV will not return its chart of accounts, so you map Procurify account codes to DATEV GL accounts and cost centers once, and every booking line references an account that already exists in DATEV. Document types in DATEV are client-specific, so the connector fetches the document-type list before uploading rather than hardcoding Rechnungseingang. EXTF files are written as UTF-8 with precomposed characters and a deterministic filename, so DATEV's filename-plus-type duplicate check makes a retry safe instead of double-posting; the DATEV duplicate error code DCO01253 is treated as already-posted. Every booking and document upload is an asynchronous DATEV job, so the connector polls the job endpoint with exponential backoff until it confirms complete or failed, and records that DATEV processes on its own schedule. Failed submissions are retried and can be replayed, and every record carries a full audit trail.

A real-world example

A 250-person engineering services firm in Germany runs all purchasing through Procurify and keeps its statutory books in DATEV through an outside Steuerberater. Before the integration, the AP clerk exported approved bills from Procurify each week, retyped the vendor, amount, tax code, and account into a DATEV booking batch by hand, and emailed the invoice PDFs to the tax office, where mismatched account assignments often bounced back for correction. With DATEV and Procurify connected, each approved bill in Procurify becomes a DATEV booking job with the invoice already uploaded to DATEV Unternehmen Online, posted against the mapped GL account and cost center. The clerk stops re-keying, the tax advisor receives clean booking batches, and month-end no longer waits on a backlog of manually entered invoices.

What you can do

• •Post approved Procurify AP bills into DATEV as EXTF CSV booking jobs or DXSO XML invoice suggestions.
• •Upload each Procurify invoice PDF to DATEV Unternehmen Online as a Rechnungseingang document, using the client-specific document type.
• •Map Procurify account codes and vendors to the DATEV GL accounts and cost centers you configure, since DATEV cannot return its own chart of accounts.
• •Bridge the Procurify 24-hour client-credentials token and the interactive DATEV OAuth login with PKCE and 15-minute token refresh.
• •Poll each asynchronous DATEV job to a confirmed result with backoff, deterministic filenames for safe retries, and a full audit trail on every record.

Questions

Which direction does data move between DATEV and Procurify?

The main flow is Procurify into DATEV. Approved AP bills, their line items, and vendor data move from Procurify into DATEV as booking jobs, and the invoice PDF is uploaded to DATEV Unternehmen Online. DATEV bookings are write-only, so ml-connector does not read posted journal entries back into Procurify.

How are accounts matched when DATEV will not share its chart of accounts?

DATEV does not expose the standard chart of accounts through its API, so the GL accounts and cost centers are configured once as a mapping. ml-connector reads the account code on each Procurify bill and translates it to the matching DATEV account, so every booking line references an account that already exists in DATEV. You set this mapping up front rather than discovering accounts at runtime.

Neither system has webhooks, so how does the sync stay current?

Both DATEV and Procurify are poll-only, so ml-connector runs on a schedule instead of waiting for push events. It queries Procurify list endpoints, filtering on fields like last_modified to pick up newly approved bills, and then polls each DATEV job until it confirms complete or failed. The cadence is usually tied to how often the AP team approves bills.