DATEV Schnittstelle integration, built past the receiving mandate

Part of it is already law. Since 1 January 2025, every business established in Germany must be able to receive a structured e-invoice (XRechnung or ZUGFeRD conforming to EN 16931) for domestic B2B transactions — that obligation is active today. The issuing side is phased: businesses with turnover above €800,000 in the prior year must issue e-invoices from 1 January 2027, and all remaining businesses follow on 1 January 2028.

§ 14 UStG defines an e-invoice as one issued, transmitted and received in a structured electronic format that permits electronic processing, and that satisfies EN 16931. A PDF, even a nicely formatted one, is legally a 'sonstige Rechnung' (other invoice), not an e-invoice. XRechnung and ZUGFeRD 2.x — excluding the MINIMUM and BASIC-WL profiles — are the accepted formats; a hybrid PDF/XML file is treated as an e-invoice only because of its embedded structured XML, which remains the legally controlling component.

They're three separate interface families, and picking the wrong one for the job is a common integration mistake. DATEV format is a file-based export (ASCII/EXTF) your system drops for periodic import — simple, batch-oriented, and still widely used for monthly booking files. DATEV data services exchange booking data and documents in a more structured way. DATEVconnect online is the modern OAuth2-based REST API for real-time exchange of vouchers, postings, master data and reports. A new integration built today should default to DATEVconnect online unless a specific workflow needs the file-based path.

No — that gap is exactly where custom integration work is needed. An incoming XRechnung or ZUGFeRD file is a structured invoice document, not a chart-of-accounts-mapped booking record. Turning it into a usable DATEV Buchungsstapel (or a DATEVconnect online voucher/posting) requires extracting the mandatory fields, mapping VAT codes and accounts, and handling the format-error/business-rule-error distinction the BMF guidance draws — a missing buyer reference is fixable, a structurally invalid XML file is not.

DATEV dominates German tax-advisor and SME accounting workflows; Exact Online plays a comparable role for Dutch and Belgian businesses, with a modern OAuth2 REST API rather than DATEV's three-tier interface model. A company operating across Germany and the Benelux region often needs both connectors built to the same internal invoice/booking model, rather than two unrelated one-off integrations.

Usually yes. International cloud accounting platforms like Xero are common at the group level, but a German entity's statutory bookkeeping, VAT filings and tax-advisor workflows typically still run through DATEV, since that's what German Steuerberater use day to day. The practical pattern is a bridge: Xero (or another group platform) stays the group ledger, and a scheduled or event-driven sync pushes the German entity's transactions into DATEV in a format its instance actually accepts.

Under the BMF's format/business-rule distinction, an invoice that fails structural validation against EN 16931 isn't a valid e-invoice under § 14 UStG at all — treat it as a rejection requiring a corrected resend, not something to force through the pipeline. An invoice that validates structurally but is missing a fixable business field, such as a buyer reference, is generally still effective and should be flagged for correction rather than blocked outright.