# lexoffice DATEV integration

*lexoffice → DATEV*

**In short:** A lexoffice to DATEV integration takes every sales invoice, credit note, purchase receipt, contact, and payment out of lexoffice (now branded Lexware Office) and delivers it to your tax advisor as a DATEV-Format booking batch: the correct SKR03 or SKR04 accounts, the right BU tax keys, stable debtor and creditor numbers, and the document image linked in DATEV Unternehmen online. Done properly it runs daily and idempotently instead of somebody downloading a ZIP file at month-end.

## 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.

## Frequently asked questions

### lexoffice already has a built-in DATEV export. Why would I build an integration?

For a single company with straightforward bookings, the built-in export is genuinely good enough and we will say so. It becomes a bottleneck when it stays manual - somebody has to remember to generate the ZIP, download it, and send it on every month. It also assumes lexoffice's standard account mapping, which is not always your Kanzlei's chart of accounts, and it has no answer for Kostenstellen, multiple lexoffice accounts, or a second target system. An integration turns a monthly task into a scheduled pipeline and puts your accounting logic under your control.

### Which DATEV format do you deliver into, and how does it reach my tax advisor?

Whichever route your Kanzlei prefers. Most commonly we produce a DATEV-Format booking batch (the EXTF/DTVF CSV structure DATEV Kanzlei-Rechnungswesen imports) together with debtor and creditor master records, and deliver the document PDFs alongside it. Where the Kanzlei works in DATEV Unternehmen online, we deliver documents and booking data through the DATEV Rechnungsdatenservice instead so the bookings and the scanned receipt arrive together. We agree the target, the Beraternummer and Mandantennummer, and the general ledger account length with your Kanzlei before we build anything.

### How are debtor and creditor numbers assigned?

That is the single most common failure point on this pair. lexoffice contacts carry a customer or vendor number that does not have to line up with the debtor and creditor ranges in your DATEV chart of accounts. We keep a persistent mapping between the lexoffice contact ID and the DATEV account number, so a contact gets exactly one number for its lifetime, numbers are never reused, and a renamed or merged contact does not silently create a second Debitor.

### Does it handle reverse charge, intra-EU supplies, and small-business invoicing?

Yes. lexoffice records a tax type and tax sub-type per voucher - net, gross, VAT-free, intra-community supply, construction services under Paragraph 13b, third-country services, and small-business status under Paragraph 19 UStG. Each of those maps to a specific BU tax key and revenue account in DATEV. We agree the mapping table with your tax advisor once, then the pipeline applies it consistently instead of a bookkeeper deciding case by case.

### Who operates the integration after go-live?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor. If lexoffice changes its API or DATEV changes an import format, that is our job to handle before it shows up as a failed import at your Kanzlei. You get a named owner, alerting, incident response, and an SLA - not a script that somebody has to remember to run and nobody wants to maintain.

## Related integrations

- [Billbee ↔ DATEV](https://seamless.engineering/integrations/billbee-datev/): Billbee DATEV integration
- [sevDesk ↔ DATEV](https://seamless.engineering/integrations/sevdesk-datev/): sevDesk DATEV integration
- [Amazon ↔ DATEV](https://seamless.engineering/integrations/amazon-datev/): Amazon DATEV integration
- [eBay ↔ DATEV](https://seamless.engineering/integrations/ebay-datev/): eBay DATEV integration
- [Factorial ↔ DATEV](https://seamless.engineering/integrations/factorial-datev/): Factorial DATEV integration
- [JTL ↔ DATEV](https://seamless.engineering/integrations/jtl-datev/): JTL DATEV integration

## Browse by system

- [All lexoffice integrations](https://seamless.engineering/integrations/lexoffice/)
- [All DATEV integrations](https://seamless.engineering/integrations/datev/)
- [lexoffice API changelog](https://seamless.engineering/api-changelog/lexoffice/): No breaking changes or deprecations in the last 90 days
- [DATEV API changelog](https://seamless.engineering/api-changelog/datev/): No breaking changes or deprecations in the last 90 days

## Request a scoping call

Need this integration built and permanently operated? Tell us which systems connect and what data has to move. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact