DATEV and Stampli integration

What moves between them

The main flow runs from Stampli into DATEV. After an invoice is approved in Stampli, the export file lands in the outbound SFTP folder, and ml-connector reads it, builds a DATEV EXTF booking batch, and submits it as an EXTF job to DATEV Rechnungswesen, uploading the matching invoice PDF to DATEV Unternehmen Online. Vendor master data flows the other way, from DATEV creditor records into Stampli as a CSV import, so coders pick from valid suppliers. Cadence is scheduled batch on both sides, since neither system pushes events. DATEV finalized bookings are write-only and Stampli vendors are read-only in most setups, so ml-connector never reads journals back from DATEV and never overwrites Stampli vendors from anywhere but DATEV.

How ml-connector handles it

ml-connector stores both credential sets encrypted, runs the DATEV PKCE OAuth login once to obtain the refresh token, and refreshes the 15-minute access token with the client_id only, while holding the Stampli SFTP password for the file transport. It polls the Stampli outbound directory on a schedule and treats each invoice line as an EXTF booking row, setting Konto and Gegenkonto, the Soll/Haben debit or credit flag, the tax code, the cost center, and the document fields. Because DATEV cannot return its chart of accounts, the GL account and tax code mapping is configured up front rather than discovered, and the same applies to cost centers. EXTF submission is asynchronous, so ml-connector polls the job endpoint with exponential backoff and jitter until the job completes or fails, never assuming success at upload. DATEV rejects duplicate files by filename and document type with error DCO01253, so filenames are deterministic and a retry re-sends the same name safely. EXTF CSV must be UTF-8 with precomposed (NFC) characters or DATEV silently rejects it, so text is normalized before upload, and every file and job carries a full audit trail with replay if a step fails.

A real-world example

A German manufacturing company with about 200 employees runs DATEV through its tax advisor for bookkeeping and uses Stampli to capture and approve supplier invoices. Before the integration, the AP team approved bills in Stampli and then a bookkeeper re-typed each one into DATEV, choosing the account, cost center, and tax code by hand, which was slow at month-end and produced posting errors the tax advisor had to correct. With DATEV and Stampli connected, each approved invoice exports to SFTP and posts into DATEV as an EXTF booking batch with the mapped accounts and cost centers, and the invoice PDF lands in DATEV Unternehmen Online alongside it. The bookkeeper reviews instead of re-keys, and the advisor sees clean batches with the source documents attached.

What you can do

• •Pick up approved invoice files from Stampli over SFTP and post them into DATEV as EXTF booking batches.
• •Map each invoice to DATEV debit and credit accounts, tax codes, and cost centers using a configured mapping, since DATEV cannot return its chart of accounts.
• •Upload the invoice PDF to DATEV Unternehmen Online so the booking carries its source document.
• •Sync DATEV creditor master into Stampli as a CSV import so invoices are coded to valid vendors.
• •Bridge DATEV PKCE OAuth login and Stampli SFTP credentials, poll each EXTF job to confirm posting, and keep a full audit trail with replay.

Questions

Which direction does data move between DATEV and Stampli?

The main flow is Stampli into DATEV. Approved invoices move from Stampli into DATEV as EXTF booking batches, with the invoice PDF uploaded to DATEV Unternehmen Online. Vendor master data moves the other way, from DATEV creditor records into Stampli as a CSV import, so the two stay aligned without ml-connector reading DATEV journals or overwriting Stampli vendors.

How does the integration work if Stampli has no public API?

Stampli is a closed platform with no public REST API, so ml-connector uses its file path. Stampli exports approved invoices and payment status as CSV or XML to an SFTP folder and imports master data as CSV, and ml-connector polls that folder on a schedule, picks up new files, and maps them into DATEV. There is no webhook on either side, so detection is by scheduled polling, not push.

How are DATEV bookings confirmed when there are no webhooks and no GL feed?

DATEV accepts finalized bookings only as asynchronous EXTF file jobs and never calls back, so ml-connector submits each batch and then polls the job endpoint with exponential backoff until it completes or fails. Because DATEV cannot return its chart of accounts or posted journals, GL accounts, tax codes, and cost centers are mapped up front rather than read back. Files use deterministic names and precomposed UTF-8 text so a retry re-sends safely and DATEV does not silently reject the upload.