lexoffice DATEV integration

What a lexoffice to DATEV integration actually does

lexoffice is where the invoice is written, the receipt is photographed, and the bank transaction is matched. DATEV is where the accountant works. Between them sits a translation job that looks trivial and is not: lexoffice thinks in vouchers, contacts, and booking categories, while DATEV thinks in booking records with a general ledger account, a contra account, a BU tax key, a debtor or creditor number, and a document reference.

lexoffice ships its own DATEV export, and for a small company on a standard chart of accounts it does the job. What it does not do is run by itself, follow your Kanzlei’s account numbering, carry cost centres, or cover more than one lexoffice account. A lexoffice to DATEV integration replaces the monthly download with a scheduled pipeline that reads vouchers, contacts, and payments through the lexoffice public API, applies your agreed accounting logic, and hands DATEV a batch that imports cleanly the first time.

A note on naming: Haufe rebranded lexoffice to Lexware Office. Same product, same API surface, and most finance teams still call it lexoffice.

What data moves

lexoffice object / event	Becomes in DATEV	Notes
Sales invoice (salesinvoice voucher)	Revenue booking against the debtor account	Split per line item where the VAT rate or revenue account differs
Sales credit note	Reversing booking	Same accounts and BU key as the original, dated to the credit note
Purchase invoice / receipt	Expense booking against the creditor account	Input tax recoverable, coded per expense category
Contact with customer or vendor role	Debitor / Kreditor master record	Stable number from a persistent mapping, never reused
Booking category (Buchungskategorie)	SKR03 / SKR04 general ledger account	Your Kanzlei’s chart of accounts, not the lexoffice default
Tax type and tax sub-type	BU tax key (Steuerschlüssel)	19% / 7%, VAT-free, intra-community, Paragraph 13b, Paragraph 19
Payment / matched bank transaction	Bank or Geldtransit booking, OPOS settlement	Clears the open item rather than restating revenue
Voucher file (Belegbild PDF)	Document in DATEV Unternehmen online	Linked to the booking so the Kanzlei sees the receipt next to it
Cost centre or project tag	KOST1 / KOST2 fields	Only where lexoffice carries the information in a structured field

The account numbers, tax keys, debtor ranges, and cost centre logic are agreed once with your tax advisor and encoded in the pipeline. After that, nobody maps them again by hand.

The details that break naive exports

• Debtor and creditor numbering. lexoffice contact IDs are UUIDs. DATEV needs numeric accounts inside the ranges your chart of accounts reserves for debtors and creditors. Without a persistent mapping, every export invents numbers again, and the same customer ends up as three Debitoren.
• Categories are not accounts. A lexoffice booking category is a business concept. SKR03 and SKR04 number the same concept differently, and most Kanzleien have added their own accounts on top. The mapping has to be explicit and versioned, not inferred.
• Delta, not full re-export. The pipeline pulls the voucher list filtered by change date and only moves what actually changed. Re-exporting a whole month on top of a batch that is already posted is how you get duplicated revenue.
• Vouchers change after the fact. An invoice gets voided, a receipt is recategorised, a payment is re-matched - often after the period has been handed over. Once a batch is festgeschrieben in DATEV, a correction is a new booking, not a re-import. The pipeline has to detect the change, decide whether the period is still open, and either update or emit a correcting record.
• Rate limits. The lexoffice API allows roughly two requests per second per key and answers with HTTP 429 when you exceed it. A month of vouchers plus their line items and contacts is thousands of calls, so the pipeline paces itself, honours Retry-After, and resumes where it stopped instead of failing the whole run.
• Webhooks only carry an ID. lexoffice event subscriptions deliver the resource type and ID, not the object. Every event needs a follow-up fetch, which has to be ordered and deduplicated so a voucher updated three times in an hour is fetched once at its final state.
• The batch header decides whether the import works at all. Beraternummer, Mandantennummer, fiscal year start, general ledger account length, and the posting date range live in the DATEV batch header. A wrong account length makes DATEV reject the file with an error that tells nobody anything useful.
• Foreign currency. lexoffice can issue invoices in another currency; DATEV wants the base amount, the foreign amount, and the rate on the correct fields. Rounding here surfaces later as a cent-level difference nobody can trace.

How we build and run it

We treat this as a pipeline, not a monthly chore. Vouchers, contacts, and payments are pulled from the lexoffice API on a schedule or triggered by event subscriptions, validated against a schema, transformed into your agreed DATEV coding, and written out as a DATEV-Format booking batch with matching master data and documents - or delivered through the DATEV Rechnungsdatenservice into DATEV Unternehmen online where that fits your Kanzlei’s workflow.

Every lexoffice object carries a stable ID and a version, so the pipeline is idempotent: a retry, a replayed webhook, or a re-run never produces a second booking for the same voucher. Unmappable records are quarantined with a readable reason instead of silently dropped, so a missing category mapping surfaces as an alert on our side rather than a gap your accountant finds in December.

It runs on cloud-native, fully EU-hosted AWS infrastructure. Invoice, contact, and payment data never leaves the EU, which keeps the AVV with us and the DPA with your tax advisor straightforward under GDPR.

Then we keep it running. Monitoring, alerting, incident response, and watching lexoffice and DATEV for API and format changes are our contractual responsibility. You get a named owner and an SLA.

When this integration is worth building

If you run one company, use a standard chart of accounts, and your bookkeeper is happy generating the built-in DATEV export once a month, do that. It works, it costs nothing, and we will tell you to keep it.

The integration earns its place somewhere else: when you run several companies or lexoffice accounts and want one consistent delivery to the Kanzlei, when your chart of accounts has diverged from the lexoffice defaults, when cost centres or project coding matter for reporting, when invoice volume makes the manual step a real monthly risk, or when lexoffice data has to reach more than just DATEV - a warehouse, an ERP, a controlling tool. At that point the question stops being whether a monthly export is possible and becomes who is accountable when it does not happen.