ERP without reliable integrations becomes an island. Duplicate entry, media breaks, and delayed approvals follow, not as edge-case technical details. Before go-live, clarify which systems remain, which data flows in which direction, and who operates the connection through updates. Only then decide on connectors, APIs, and custom development.

Why do ERP projects fail on missing integrations?

Because integration is often treated as afterwork. The system goes live while spreadsheets and email stay the bridge to accounting, the shop, or document management. Every handoff costs time and creates drift between stock, documents, and reporting. Audits and month-end close show it first. Operations feel it every day.

An integration concept therefore belongs in the planning phase. It answers three questions: Which systems stay in parallel? Which objects are leading (order, document, article, partner)? Who owns operations, monitoring, and release tests? Without those answers, every demo integration is a promise without an operating model.

Implementation mistakes often start exactly here. More on that: common ERP implementation mistakes.

Which connections are typically mandatory in the mid-market?

Not every company needs the same list. These areas recur, however:

• DATEV and finance export: Accounting and tax advisors need structured handoffs, not PDF stacks without context.
• E-invoicing (XRechnung, ZUGFeRD): Receipt, validation, and posting belong in the ERP transaction. Details: XRechnung and ZUGFeRD.
• DMS and audit-proof archiving: Documents attached to the business transaction, not in a folder beside the system.
• REST APIs: Connect webshops, CRM, BI, or industry portals without bypassing the data model and permissions.
• Machines, MES, or shop floor: Often essential in manufacturing when feedback must drive stock and orders.

Priority follows the process, not the module catalog. Teams that first clarify the order-to-invoice flow see faster which integration has the greatest leverage.

When are standard connectors enough, and when do you need open APIs?

Standard connectors accelerate known cases: DATEV export, common shop connections, established e-invoicing paths. They are enough as long as data direction, mapping, and error handling are documented and updates do not break operations.

Individual processes need more. Custom fields, approval logic, batches, or project-specific documents rarely fit a finished box. Then open APIs, clear permissions (act-as logged-in user, audit), and the ability to run integrations without vendor approval matter. For sovereignty: interfaces documented, maintainable, and independent of any single provider.

Proprietary ERP systems often ship only selected connectors. Individual ERP on an open-source basis lets you build and test the connection on the real process instead of bending the process to the connector.

What do you check before contract signature and go-live?

1. Data direction and leading system: Who wins on conflicts (shop vs. ERP, DMS vs. document)?
2. Error and restart behavior: What happens on timeout, duplicate, or partial booking?
3. Test and release plan: Who validates the interface after every update?
4. Export and exit: Can you take data and mapping with you in documented form if hosting or partners change?
5. Compliance path: GoBD, approval history, and document access without media breaks.

These points belong in architecture and contract, not in a ticket after go-live.

Which decisions come next?

First inventory today’s breaks: where is data copied manually, where does fragile sync run, where are documents missing on the transaction? Then prioritize one connection with measurable benefit, such as DATEV or inbound e-invoicing, and take it live before you rebuild the entire landscape.

Deepen the basics in What is ERP? and e-invoicing processes in XRechnung and ZUGFeRD. When scope and effort are unclear, a focused subprocess in a prototype often clarifies more than another catalog comparison.