ERP Interfaces: EDI, APIs, iPaaS and DATEV

Every ERP in the German Mid-Market sits at the centre of a web of interfaces. Orders arrive from web shops and marketplaces, stock flows to a warehouse-management system, balances are pushed to the tax adviser's DATEV environment, trading partners exchange EDI, and cloud services consume ERP data via REST or GraphQL. The way an ERP exposes interfaces is the silent determinant of whether the implementation feels modern in daily operation. This page describes the landscape of ERP interfaces relevant to organisations operating in DACH, with a focus on regulatory anchors such as the DATEV format, GoBD-compliant archiving, KassenSichV for point-of-sale and OSS/IOSS for cross-border VAT.

EDI: EDIFACT, OFTP2 and AS2

Electronic data interchange remains the dominant integration protocol for B2B trading-partner flows in DACH retail, automotive and industrial procurement. EDIFACT is the predominant message standard, with VDA subsets in automotive. The transport layer is typically OFTP2 in automotive and AS2 or AS4 in retail. German trading partners such as Edeka, Rewe, Metro and the automotive OEMs maintain detailed implementation guidelines, and onboarding new partners typically requires per-partner mapping. The B2G mandate for XRechnung and the hybrid ZUGFeRD format add a German-specific layer: federal authorities require structured XML invoices. EDI is rarely built in-house in the Mid-Market; specialist providers such as Lobster, SEEBURGER and the Austrian ecosio operate cloud-hosted EDI platforms with pre-mapped templates for major DACH partners.

API-first: REST and GraphQL

Modern cloud ERPs expose REST APIs as the primary integration surface, with a smaller but growing share of vendors offering GraphQL. Quality varies sharply: SAP S/4HANA Cloud, Microsoft Dynamics 365 Business Central, NetSuite, weclapp and Xentral publish comprehensive, versioned APIs with developer portals, while some on-premise vendors retain older SOAP or file-based interfaces alongside a partial REST surface. Buyers should evaluate not only whether an API exists but also its object coverage, authentication model, rate limits, sandbox availability and versioning discipline. APIs alone do not constitute an integration; they are the substrate on which middleware, iPaaS flows or custom connectors are built.

iPaaS middleware platforms

Integration platform-as-a-service shifts the integration model from custom point-to-point interfaces to declarative flows operated as a managed service. Established global platforms include Boomi, MuleSoft (Salesforce-owned) and Workato; mid-market alternatives such as Celigo, elastic.io and n8n (open source with a hosted offering) cover similar territory at lower entry pricing. For organisations operating more than a handful of integration points, iPaaS reduces the long-term maintenance burden through centralised monitoring, version control, error replay and a library of pre-built connectors. The trade-offs are platform lock-in and an ongoing subscription cost typically scaled by connection or transaction volume. An iPaaS is not a substitute for integration design: an organisation that does not know which records are authoritative in which system will simply make that confusion more expensive.

The DATEV interface: a German requirement

DATEV is the dominant software cooperative for German tax advisers, and most Mid-Market finance teams exchange data with their Steuerberater using DATEV-format files or direct DATEV-API connections. The DATEV interface is therefore a near-mandatory feature for any ERP sold in Germany. Native DATEV interfaces are common in German-localised products such as Sage 100, myfactory, weclapp, Lexware, SelectLine and microtech. International ERPs (SAP, Microsoft Dynamics 365, NetSuite, Oracle) typically rely on a partner-built DATEV connector. Buyers should verify that the interface supports the current DATEV format version, handles bidirectional flow, covers the relevant document types and is documented in a GoBD-compliant Verfahrensdokumentation. Decision framework for build versus buy versus iPaaS: build only when the integration encodes a genuine competitive process, buy a packaged connector for commodity flows such as DATEV, and reach for iPaaS once the integration count makes per-flow maintenance the dominant cost.

Frequently Asked Questions

What is the difference between EDI and a REST API?

EDI is a structured message standard (EDIFACT, ANSI X12, VDA) used between trading partners over transports such as AS2, AS4 or OFTP2; it is optimised for B2B document flow with established conventions per industry. REST is an architectural style for application APIs over HTTP, typically used for real-time application integration. The two coexist: a modern integration platform exposes REST internally and translates to EDI at the trading-partner boundary.

Is a native DATEV interface mandatory?

Not in a strict legal sense, but practically yes for any organisation whose tax adviser uses DATEV. The Verfahrensdokumentation required under GoBD must describe how accounting-relevant data leaves the ERP, and a documented DATEV interface is by far the simplest way to satisfy that requirement. ERPs without a DATEV interface either implement one via a partner connector or restrict themselves to organisations whose tax adviser uses a different platform.

When does iPaaS pay off?

As a rough heuristic, an organisation with fewer than five integration points and stable, slow-changing systems will find point-to-point integration cheaper. Above that threshold the maintenance cost of point-to-point grows non-linearly, and an iPaaS platform begins to pay off through centralised monitoring, version control and faster onboarding of new endpoints. The break-even point is sensitive to the rate of change rather than the absolute count.

How do KassenSichV and OSS/IOSS affect interface design?

The German KassenSichV requires a certified technical security element (TSE) for point-of-sale systems, which means retail and e-commerce-with-physical-stores ERPs must integrate either a hardware or cloud TSE into the receipt-generation flow. OSS and IOSS introduce a single-window VAT regime for intra-EU distance sales and low-value imports; ERP interfaces must therefore tag transactions by country-of-consumption and produce the consolidated returns expected by the German Federal Central Tax Office (BZSt).