DATEV, GoBD & industry interfaces: what off-the-shelf SaaS often can't do.

The bad news first: many international SaaS vendors do not understand the German rules for proper bookkeeping. They ship clean software, beautiful UIs and impressive features – but they fail on topics like GoBD, DATEV export, POS-TSE or electronic invoicing. In the SME world this leads to two problems: duplicate work at the tax advisor and risk during tax audits.

This article explains what is behind the German requirements, why off-the-shelf SaaS often fails them, and how custom-built software maps these topics cleanly.

GoBD: the rules of German bookkeeping

GoBD stands for “principles for the proper management and storage of books, records and documents in electronic form, as well as for data access”. Bulky, but central. Important requirements at a glance:

• Immutability: once posted, vouchers cannot be changed
• Completeness: all tax-relevant transactions must be recorded
• Traceability: every change must be logged (audit trail)
• Retention: audit-proof – books and records for 10 years, accounting vouchers for 8 years since 2025
• Timeliness: business transactions must be booked promptly
• Data access: tax audits must be able to use Z1, Z2 or Z3 access

Many international SaaS vendors don't meet GoBD or only partially. This usually only becomes visible during the first tax audit – and then it gets expensive.

DATEV export: more than a CSV file

DATEV is widely used by German tax advisors. A real DATEV interface means much more than “CSV export”:

DATEV format DTVF

A specific format for booking entries with accounts, cost centres, debit/credit, voucher numbers and posting texts. Column order is precisely defined. Wrong formatting causes import errors at the tax advisor.

SKR03 / SKR04 charts of accounts

Standard charts for German bookkeeping. Vouchers must be assigned to the right accounts automatically or manually – which presupposes that the software knows the chart and not just English categories like “Office Supplies”.

VAT-ID check and reverse charge

For intra-EU deliveries the recipient's VAT ID must be checked. Reverse-charge cases must be booked correctly. Internationally designed software often doesn't know these specifics.

POS-TSE: mandatory since 2020

Anyone running an electronic POS system in Germany has to use a technical security device (TSE) since 2020. Without a TSE there are fines of up to €25,000, and the tax office can reject the cash records and estimate revenue.

International SaaS POS systems often do not offer a TSE certified in Germany – some only as an expensive add-on. In a custom build the TSE integration is planned in from the start.

E-invoicing: receiving mandatory since 2025, sending from 2027/2028

Since 1 January 2025 all businesses in Germany must be able to receive electronic invoices in domestic B2B transactions. Sending is subject to transition periods: paper and PDF invoices are still allowed until 31 December 2026 (PDF only with the recipient's consent), and until 31 December 2027 for businesses with a prior-year turnover of up to €800,000. Invoices via EDI also remain permitted with the recipient's consent until the end of 2027. From 1 January 2028 e-invoices are mandatory for all businesses in domestic B2B – with a few exceptions, for example for small businesses under the Kleinunternehmer rule and small-amount invoices. An e-invoice is an invoice in a structured format that follows the European standard EN 16931, for example XRechnung or ZUGFeRD from version 2.0.1 (not the MINIMUM and BASIC-WL profiles).

Many international SaaS tools still send only PDFs – from 2027 or 2028 that will no longer meet the rule. Then structured data following EN 16931 is mandatory. Anyone buying a SaaS tool today must check whether e-invoicing is properly supported.

Industry-specific interfaces

Beyond the general obligations there are industry standards that off-the-shelf SaaS often doesn't cover:

Trades and construction

• GAEB format for bills of quantities and measurements
• BAU-Steine: standardised text blocks from the ZDB
• Payroll with SOKA-Bau and minimum-wage obligations

Healthcare

• KIM (communication in medicine) for secure messaging
• Telematics infrastructure (TI) connection
• Special billing per EBM, GOÄ, BG

Legal

• beA (special electronic lawyer mailbox)
• Court-file-number logic
• RVG-compliant fee billing

Logistics and forwarding

• EDIFACT messages (IFTSTA, INVOIC, etc.)
• Connections to MES and ERP systems of large shippers
• Customs and ATLAS interfaces

How custom SaaS solves these topics

In a custom build, interfaces are not a sales pitch but part of the requirements analysis. I typically proceed like this (I describe the process from workshop to go-live in detail in a separate article):

1. In the workshop we clarify together which external systems must be connected – and how deeply
2. In the concept each interface is described individually: format, frequency, data flow, error handling
3. In development the interfaces are built modularly so that they can be swapped or extended later
4. In operations I actively monitor the interfaces – when the tax advisor reports a DATEV import error, I often see it before they call

Example: GAEB measurement in construction

An example from civil engineering: a mid-sized firm wants to digitalise its measurement capture. Standard construction software exists, but none offers a really clean GAEB connection to the architect software of the main client. The result: measurements are captured twice – once in the construction software, once converted manually into GAEB format.

Custom software can capture measurements directly in GAEB format, send them automatically to the architect and hand them to the internal order management. Depending on the volume of measurements, this can save, for example, around 6 hours of duplicate work per week. It also reduces the risk of transcription errors and takes load off the site managers.

What to look for when buying off-the-shelf SaaS

Even if you go off-the-shelf, clarify these questions before signing:

• Is the software GoBD certified? Is there a German auditor's testimonial?
• Which DATEV interfaces are included? In which formats?
• Are SKR03 and SKR04 supported?
• Is VAT-ID checking integrated? Reverse charge?
• Is e-invoicing supported in XRechnung and/or ZUGFeRD – receiving AND sending?
• Where is data stored? Is there a DPA?
• Is a POS-TSE integrated (if relevant)?

Conclusion

The German obligations on bookkeeping, data retention and interfaces are not a detail – they are the point at which many off-the-shelf SaaS products either fail or require workarounds so complex that the efficiency gains are lost again. A custom build can map these topics cleanly from day one because it is designed from a German perspective.