ERP Integration for German SMEs: Patterns, Costs, Failure Modes and Practical Examples

Friday, 3:40 pm. Orders keep coming into the online shop, but none arrive in the ERP anymore. A certificate has expired, and the interface writes the error to a log file nobody reads. On Monday there is a backlog of 140 orders, three customers have bought goods that are no longer in stock, and sales spends the morning on the phone.

This is not a made-up case. Many of our conversations about ERP integration start this way, or very close to it. The ERP itself is rarely the problem. The problem is the connections in between: how data gets in and out, who notices when something goes wrong, and who puts it right again after the next update.

This guide is for managing directors, IT leads and business departments in mid-sized companies (the German Mittelstand) who are planning an integration, replacing an existing one or simply want to understand why their interfaces take so much effort. If you are more concerned with the architecture question, meaning what belongs in the ERP and what sits next to it, read ERP for SMEs: How Custom Software Extends Your ERP first. This post is about the layer underneath: the wiring.

Why integration is the real cost driver

A mid-sized company with 100 to 500 employees rarely runs just an ERP. Next to it there is an online shop or B2B portal, a CRM, a system for production or machine data, document management, accounting or the export to the tax advisor, EDI with a handful of large customers, a shipping provider, and since 2025 a channel for incoming e-invoices.

Each of these systems is manageable on its own. The exchange between them is what gets expensive, for three reasons:

• Every integration is a small software project, even if it shows up in the quote as a single line item called "interface". It needs requirements, tests, operations and maintenance.
• Interfaces age faster than systems. The ERP gets an update, the shop a new API version, the EDI partner a new format. Every change on one side hits the connection.
• Failures stay invisible until they are expensive. Everyone notices a crashed application. An interface that silently does nothing is first noticed by the customer.

That is why integration deserves a deliberate decision rather than being treated as a technical detail: which pattern, which costs, which safeguards.

The six integration patterns

There are many product names and buzzwords, but at their core only a handful of patterns for how two systems exchange data. Each has its place, and each has a price that isn't in the quote.

A side note on RPA, software robots that operate a user interface like a human: it is not an integration pattern but a stopgap for systems with no interface at all. As a bridge for a few months it can be justified. As a permanent solution it breaks with every change to a screen.

Which pattern when?

In practice, four questions narrow the choice:

1. How fast does it need to arrive? If overnight is fine, file exchange is often the most robust and cheapest option. If it has to be there in seconds, there is no way around APIs and events.
2. Which direction does it flow? Reading is cheap, writing is expensive. Whoever writes into the ERP has to respect its rules, and that only works through the approved interface.
3. How many systems are involved? One connection may run directly. From the third or fourth that all need the same customers, items and orders, a shared integration layer pays off, because it handles authentication, field mapping and error handling once instead of several times.
4. What happens if the connection fails? If the answer is "then shipping stops", you need buffering, restart and alerting. If it is "then the report is a day old tomorrow", you don't.

By the way, the most common wrong decision is not a pattern that is too simple but one that is too big: a middleware platform with licences, training and its own operations for two connections a clean API call would have handled.

What ERP integration realistically costs

The honest answer to "What does an interface cost?" is that it depends less on technology than on how clean the data is and how much the ERP partner cooperates. Still, you need orders of magnitude to plan a budget. The following figures are experience values from projects with mid-sized companies, not a price list. They cover implementation by a service provider, excluding licence costs for the ERP or middleware.

For ongoing operations, budget 15 to 25 percent of the build cost per year: monitoring, adjustments to ERP and partner updates, certificates, small functional changes. If you don't plan for this, you pay it anyway, just later and as an emergency.

The items missing from quotes

The gap between quote and actual cost almost always appears in the same places:

• Data cleansing. Duplicates in the customer master, items with three units of measure, free-text fields that have been carrying control information for years. In our projects this regularly eats 20 to 40 percent of the effort, and nobody quoted it.
• ERP partner hours. Interfaces have to be enabled, permissions set up, sometimes fields added. Your ERP partner does that, at their hourly rate and on their schedule.
• A test system. Many mid-sized companies have no ERP test system with realistic data. Without one, testing happens in production, and that is more expensive than any test system.
• Licences for indirect use. Some ERP vendors charge separately for access through third-party systems. SAP calls its model Digital Access and measures it by documents created through external systems. Clarify this in writing before implementation, not after the first audit.
• Business department time. Only someone who knows the process can sign off the field mapping. Those hours are spent in your company, not at the service provider.

A worked example

Three inside-sales staff spend about three hours a day between them typing orders from the shop and from emails into the ERP. Over 220 working days that is 660 hours a year. At a fully loaded rate of 45 euros per hour that comes to around 30,000 euros, not counting the cost of typos: wrong delivery addresses, wrong quantities, credit notes.

A clean two-way integration might cost 35,000 euros in this case, with 7,000 euros a year for operations. It pays for itself in a little over eighteen months, and the three staff look after customers instead of retyping. Calculate your own case the same way: working time for manual transfer plus error costs, against build plus operations. If the numbers don't work out after three years, the spreadsheet might be the right answer after all, for now.

Eight failure modes that sink integrations

We are often called in when an integration is already running and still causing trouble. The causes repeat themselves remarkably reliably.

1. Silent failures. The interface aborts and writes it to a log nobody reads. This is the most common and most expensive failure, because it goes unnoticed for days. Remedy: every connection needs monitoring that notifies a human, in the business department, not only in IT. Messages that could not be processed go to an error queue from which they can be resubmitted after the fix.

2. Unclear data ownership. Customer addresses are maintained in both the CRM and the ERP, both sides sync in both directions, and after six months nobody knows which address is correct. Remedy: exactly one leading system per data object, written down. What such a data ownership matrix looks like is in our ERP post.

3. Duplicate processing. A message is resent after a timeout, and suddenly there are two identical orders in the ERP, with two deliveries and two invoices. Remedy: every message carries a unique key, and the receiver checks whether it has already seen it. Engineers call this idempotency. In everyday terms: sending twice must not book twice.

4. The ERP update breaks the connection. After the release change a field has a different name, a mandatory field is new, an interface is deprecated. Remedy: every connection has a described contract of what it delivers and expects, plus automated tests that run against a test system before each update.

5. Writing directly to the database. It was quick to build and worked for a long time. But it bypasses the ERP's pricing, inventory, permissions and change log, and when something goes wrong the vendor declines support. Remedy: write only through approved interfaces, no exceptions.

6. Same fields, different meaning. "Quantity" is pieces in the shop and cartons of twelve in the ERP. The shop rounds prices to two decimals, the ERP calculates with four. One timestamp arrives in UTC, the other in German local time. Tax codes don't match. Remedy: have the business department sign off the field mapping, not just IT, and explicitly test edge cases such as partial deliveries, cancellations and credit notes.

7. Knowledge in one head. A working student built the interface in 2019, or a former employee of the ERP partner. There is no documentation, and the source code sits on a server nobody wants to touch. Remedy: source code in your version control, one page of documentation per connection, a named business and technical owner.

8. The licensing surprise. The integration runs, then the ERP vendor's licence audit arrives and bills for indirect use. Remedy: the question of licences for access through third-party systems belongs in the feasibility check, not in the post-mortem.

What's notable is what is missing from this list: the choice of programming language, framework or middleware. Integrations rarely fail because of technology. They fail because nobody decided who owns the data, who is responsible and who notices when something goes wrong.

Building the integration with AI: what gets cheaper, and the fallacy behind it

A coding agent now writes the mapping code for an interface in minutes. The obvious conclusion: the integration should now cost a fraction of what it used to. That is exactly the fallacy, and it is an expensive one, because it cuts budgets and expectations in the wrong place.

Where AI genuinely speeds up implementation

Used properly, AI takes a lot of legwork off an integration project:

• Reading interface documentation and field catalogues and producing a first draft of the field mapping, instead of typing it up.
• Writing mapping and connection code, the part that maps fields, converts formats and assembles calls.
• Generating test cases and test data, including edge cases such as partial deliveries, cancellations or special characters in addresses.
• Understanding old connections. Extracting the rules from a grown spreadsheet or an undocumented legacy interface and turning them into a list the business department can review.
• Documentation, written along the way instead of being cut at the end.

In these parts we work noticeably faster with AI support, roughly 30 to 50 percent depending on the connection.

Why the budget still doesn't shrink by the same amount

Code is only part of the effort. Take a typical integration apart and the numbers look like this:

All in all, an integration built with AI realistically ends up 10 to 20 percent cheaper, not half the price. The 35,000 euros from the worked example become something like 28,000 to 31,000 euros. Ongoing operations barely change, because monitoring, ERP updates and certificates don't go away just because the code was written faster.

The fallacy: faster code doesn't mean done faster

More dangerous than the overestimated savings are the defects AI-generated integrations typically bring along. They all look the same: the code runs, the tests are green, and the problem only shows up in operation.

Plausible but wrongly mapped. A model maps fields by name. "Menge" becomes "quantity", and the fact that one means pieces and the other cartons is not in any field name. That is failure mode number six, just produced faster.

Invented or outdated interfaces. The model doesn't know your ERP's API version exactly and fills in what sounds plausible: a field that doesn't exist, an endpoint that has been deprecated. This only surfaces against the real system. With AI, the feasibility check against the real system becomes more important, not redundant.

Tests that confirm the mistake. If the same AI writes code and tests from the same wrong assumption, the tests are green and prove nothing. Test cases have to come from real data and from the business department. Why agents shouldn't grade their own work is covered in Verification & Control: Agents Can't Grade Their Own Work.

Only the happy path is built. Generated code covers the normal case well. Duplicate messages, restart, error queues and alerting only appear if someone explicitly asks for them. Yet these are exactly the parts that determine the cost of operation, see failure modes one and three.

Lots of code, nobody behind it. Where one person used to build and understand the interface, an afternoon now produces more code than anyone has read. That makes failure mode seven worse. Every line needs a review and a named owner, no matter who wrote it.

Real data in the prompt. Copying real customer masters or ERP extracts into a cloud service during development hands over trade secrets and personal data. Work with anonymised test data or with models whose operation you control. When running them yourself pays off is calculated in Is a Local AI Setup Really Worth It for a Company?.

The rule of thumb

AI lowers the cost of typing, not the cost of decisions. Anyone offering you an AI-built integration at half the price has either left out data cleansing, coordination and operations, or is cutting corners on error handling and tests. Both come back later, as a silent failure on a Friday afternoon.

Used properly, AI is still a real gain: the time saved belongs in the parts that used to be squeezed for budget reasons, meaning edge-case tests, monitoring and documentation. Then the integration isn't just a bit cheaper, it is above all more robust.

Four practical cases

The following cases are typical constellations we see again and again in mid-sized companies. They show how patterns, costs and failure modes come together in a concrete project.

1. Online shop and ERP

Starting point: A wholesaler sells through a B2B shop. Stock and prices are transferred nightly as a file, orders are retyped into the ERP from email exports. As a result the shop sells goods during the day that are long gone, and customer-specific prices are wrong.

Solution: Orders go straight into the ERP via API, with the unique order number as the key so a resend does not book twice. The ERP publishes stock as an event on every change. The shop keeps a read-only copy with a defined maximum age so it can keep selling during an ERP maintenance window. Customer prices are queried live, because there are too many combinations for a copy. The ERP stays the leading system for customers, items, prices and orders, the shop for baskets and sessions.

What mattered: Half of the effort was not in the API but in items whose units of measure in the ERP didn't match the shop.

2. E-invoicing, incoming and outgoing

Starting point: Since 1 January 2025, companies in Germany must be able to receive e-invoices. From 1 January 2027, companies with more than 800,000 euros in prior-year revenue must also issue them, and from 2028 that applies to everyone. Many businesses initially solved receipt pragmatically: the XML file is turned into a PDF, printed and booked by hand. That meets the obligation on paper and gives away the benefit.

Solution: Incoming invoices land in a central mailbox, are automatically validated against the XRechnung and ZUGFeRD formats, matched against the purchase order and goods receipt in the ERP, and only shown to a human for approval when something deviates. The vendor invoice is then posted through the ERP's interface. For outgoing invoices, check whether your ERP generates the formats itself in its current version. An update is often enough, but sometimes mandatory details are missing from the structured data because they used to appear only as free text on the PDF.

What mattered: Automatic matching against purchase order and goods receipt is the real gain. Format validation is the obligation, matching is what saves work.

3. Manufacturing and ERP

Starting point: A supplier records machine times and quantities in a production data system. Confirmations of production orders back into the ERP are done by hand at the end of the shift, often the next morning. Post-calculation is inaccurate as a result, and sales doesn't know the real order status.

Solution: Production orders come from the ERP to the machine, confirmations go back as events. Aggregation is key: not every cycle signal belongs in the ERP, only reported quantities, scrap and times per operation. If the connection to the shop floor drops, the production side buffers the messages and forwards them later, in the right order.

What mattered: Agreeing which data belongs in the ERP and which stays in production. Writing every sensor signal into the ERP brings it to its knees.

4. EDI with a major customer

Starting point: An automotive customer requires delivery schedules and dispatch advice electronically, for example via EDIFACT messages such as DELFOR and DESADV, with deadlines and contractual penalties. Until now, schedules arrived as PDFs.

Solution: An EDI service provider handles transport and format translation, and the connection to the ERP runs as file exchange or via API. Schedules are created automatically as scheduling agreement lines, with deviations from the previous schedule highlighted. The dispatch advice is generated from the shipping posting in the ERP, not from a second manual entry.

What mattered: The test phase with the customer, which often takes longer than the implementation itself. Plan it into the timeline, not as a buffer.

How to proceed: five steps

1. Interface inventory. List every connection that exists today, including the manual ones. Who delivers what to whom, how often, by which route, and who notices when it doesn't arrive. This list alone surprises most companies.
2. Clarify data ownership. One leading system per data object, written down.
3. Feasibility against the real system. Before any business logic is built, prove that the ERP delivers and accepts the required data through approved interfaces, in sufficient volume and without a licensing surprise. Your ERP partner is at the table for this.
4. One process fully in production. Better one connection end to end with real data than three half-finished ones. How to cut that first slice is described in Requirements Engineering in the Iterative Cycle.
5. Monitoring before rollout. Alerting, error queue, restart and owners are in place before the connection is rolled out broadly. From then on, the regression test runs before every ERP update.

Nine questions for your service provider before you sign

• Which integration pattern do you propose, and why not a simpler one?
• Which system leads for which data object, and where is that written down?
• What happens if a message arrives twice?
• Who gets notified when the connection fails, and how quickly?
• How is the connection tested before an ERP update?
• What licence costs does the integration trigger with the ERP vendor?
• How much effort is planned for data cleansing?
• Where do you use AI, who reviews the results, and which data do you work with?
• Do we own the source code and documentation at the end?

A provider who can answer these questions clearly has operated integrations before, not just built them. That is the difference that matters.