Nobody plans siloed systems. They accumulate because each purchase made sense at the time: the accounting software in 2018, the webshop in 2021, the CRM in 2023 because sales needed one. Every tool is good at its job. But now each system knows the same customer in its own version, with its own address and its own status, and someone in the company reconciles it all by hand at the end of the month. The usual reflex at that point is to call for the one big system that does everything. There is a much smaller intervention: connect the systems you already have.

What double entry really costs

The visible part is the typing. A company where shop orders get transferred into the inventory system by hand loses a few minutes per order. At twenty orders a day, that is already a noticeable slot in the weekly schedule, and it grows with every increase in revenue.

The more expensive part is invisible: the systems contradict each other. The delivery address was changed in the shop but not in the ERP, and the parcel goes to the old address. Sales calls a customer without knowing about their open complaint, because it is only visible in accounting. Cases like these show up in no cost report, but every single one costs trust, internally and externally.

And the data as a whole loses value. According to a Bitkom survey of German companies (2024), only 6 percent believe they fully exploit the potential of their data; 42 percent use it rather little, 18 percent not at all. If the same customer lives in three systems in three versions, that quota is no surprise: such data can neither be analyzed reliably nor processed automatically.

The in-between state: a person as the interface

In most companies, the connection between the islands has existed for years; it is just called Ms. Berger or Mr. Novak. One person knows that new customers from the shop also belong in the CRM, that article numbers in the webshop use a different format than in the ERP, and that the export is best done on Tuesdays because the price list updates on Mondays.

That knowledge is valuable, and that is precisely why it belongs in an integration instead of in someone’s head. Not because the person works badly, but because they take vacations, get sick, and eventually leave, and because no human transfers an order at three in the morning. The good news: whoever builds the integration only has to transcribe this knowledge, not invent it. The conversation with this person is the most important part of any integration project.

Four patterns for connecting systems

Technically, almost every integration comes down to one of four patterns, often a combination. Which one fits depends on the systems and the data volume, not on the developer’s taste.

Two-way sync: changes on one side land on the other. Conflicts are resolved by fixed rules, not by chance. Typical for ERP and CRM.
Event-driven: an order or a status change immediately triggers the next steps. Typical for shop and inventory.
Scheduled runs: for large data volumes, nightly reconciliation with a report on what was transferred and what was not.
Bridge without an API: even systems without an interface can be connected, via files, email inboxes, or database access. Not elegant, but often the only option with older software.

The most important decision: which system leads?

Before data flows, every piece of information needs an owner. If the customer address differs between CRM and ERP, which one wins? The question sounds trivial, and it is where integration projects get stuck the longest in practice, because the answer is organizational: one system is declared the leading system for that type of data, and the others follow.

Our recommendation is to decide this per data type, not globally. Customer master data is often led by the ERP, contact history by the CRM, orders by the shop. Trying to resolve every conflict automatically in both directions produces a system nobody can reason about anymore.

What an integration costs

A single connection between two systems with usable APIs, say shop and inventory, typically costs between €4,000 and €12,000 to build. It gets more expensive when a system has no API and needs a bridge, or when data first has to be cleaned up because ten years of double entry have left their marks. The cleanup is regularly underestimated: if the same customer exists three times, someone has to decide which record survives before the first sync runs.

And what operations cost

Building an integration is the smaller part of the work. Keeping it running inconspicuously for years is the larger one. APIs change, systems get updates, and sooner or later one system is unreachable for a night. A proper integration buffers instead of losing data and catches up afterwards. Budget an ongoing line item for operations and care, not zero.

Where integrations fail

Rarely on the technology. More often on edge cases that only surface in production: the customer with two delivery addresses, the order changed after the fact, the special character in a company name that one system swallows. That is why every integration needs a log showing what was transferred and when, and an alert when something gets stuck. An integration that fails silently is more dangerous than none at all, because everyone relies on it.

And one last honest note: if it is already settled that one of the systems involved will be replaced within a year, do not connect it. In that case, double entry for one more year is the cheaper solution.