Stuart Totterdell
Technical Director
Ask most mid-market businesses whether their systems are integrated and they will say yes. Ask them what that means in practice and the answer reveals a different reality.
"We have an integration" usually means one of three things: a scheduled file export that runs overnight, a connector that was set up two years ago and has not been checked since, or a person who manually transfers data between systems at regular intervals. None of these is integration. All of them are commonly described as such.
The gap between what businesses believe data and systems integration means and what it actually requires is one of the most expensive misunderstandings in mid-market operations. This article is about closing that gap.
What integration is not
Integration is not a CSV file exported from one system and imported into another on a schedule. That is a data transfer. It happens at fixed intervals, it carries no context, and when it breaks - which it does, regularly - nobody finds out until the numbers stop matching.
Integration is not a Zapier connection or a lightweight connector that syncs one field between two platforms. That is a point connection. It moves a single piece of data in one direction. It does not handle exceptions, transformations, or business logic. And it creates a false sense of confidence - the belief that the systems are "talking to each other" when they are exchanging the bare minimum.
Integration is not a person who copies data between systems. That is a human middleware layer. It is flexible, adaptable, and - because it relies on one person's knowledge - completely unreliable as a long-term solution.
These are all common. They are all described as "integration" in boardrooms and vendor proposals. And they are all fundamentally different from what integration actually requires.
What integration actually is
Real integration means that when something happens in one system, every other system that needs to know about it finds out - automatically, immediately, with the right data in the right format, subject to the right business rules.
That definition has five components, and all five are necessary.
Automatic. No human intervention required. Not a scheduled batch. Not an email trigger. The event in the source system initiates the flow without anyone pressing a button or running an export.
Immediate. Or near-immediate. Not overnight. Not weekly. When a customer record is updated, the connected systems reflect that update within minutes, not days. Stale data is wrong data - it just has not been caught yet.
Right data. The fields that move between systems are mapped correctly. A "customer name" in the CRM corresponds to the correct field in the ERP and the finance platform. A "product code" means the same thing everywhere. This sounds obvious. In practice, it is where most integrations fail.
Right format. Data formats are normalised. Dates are consistent. Currency fields match. Units of measurement agree. Country codes align. The integration layer handles the transformation so the receiving system gets data it can process without manual cleanup.
Right business rules. Not every event should propagate everywhere. An updated contact email might need to sync to the CRM and the marketing platform but not to the finance system. A cancelled order should trigger different actions in the ERP, the warehouse, and the billing system. The business logic that governs what moves where, and under what conditions, is part of the integration - not an afterthought.
Why it is usually done badly
There are three consistent reasons.
The first is that integration is treated as a technical task rather than an IT and process strategy task. Someone in IT is asked to "connect the CRM to the ERP." They build an API connection that syncs certain fields. But nobody defined which fields, in which direction, under what business rules, with what exception handling. The result is a technical connection that does not reflect how the operation works.
The second is that integrations are built and then forgotten. The initial connection works. Data flows. Everyone moves on. Six months later, a field name changes in one system, or a new product category is added that the integration does not recognise, or the API version is deprecated. The integration silently breaks. Data stops flowing, or - worse - flows incorrectly. Nobody notices until someone asks why the numbers do not match.
The third is scope. Most integration projects connect two systems for one purpose. CRM to ERP for order data. ERP to finance for invoicing. But the operation does not work in pairs - it works as a network. The order that starts in the CRM affects the ERP, the warehouse, the finance system, the project management tool, and the reporting layer. Integrating in pairs creates a patchwork that has gaps between every connection.
What good integration looks like in practice
Good integration is invisible. That is the point - when it works, nobody thinks about it. Data appears where it needs to be, in the right format, at the right time. The team uses their systems and the systems agree with each other.
Behind the scenes, good integration involves several things that are rarely visible to the business:
An integration layer - typically built through proper development and build, not wired together in a SaaS connector - that sits between your systems and manages the data flows. This is not a single connector between two platforms. It is an orchestration layer that routes data based on business rules, handles exceptions, logs every transaction, and alerts when something fails.
Data transformation rules that normalise information as it moves. When the CRM sends "United Kingdom" and the ERP expects "UK," the integration layer handles the conversion. When finance uses two decimal places and the ERP uses four, the rounding is managed. These transformations are defined once and applied consistently.
Error handling and monitoring. When a data flow fails - and it will, periodically - the integration layer catches the failure, logs the specific error, and either retries or escalates. Nobody discovers the problem three weeks later during a reconciliation. It is caught in minutes.
Version management. When one of your systems is updated, the integration layer is reviewed and adjusted. Field mappings are verified. API endpoints are confirmed. The integration is maintained as a living system, not installed and abandoned.
The cost of getting it wrong
Every hour your team spends reconciling data that should agree is a cost of bad integration. Every error caused by stale or mismatched data is a cost of bad integration. Every decision delayed because leadership cannot trust the numbers is a cost of bad integration.
Most businesses do not quantify these costs because they have been absorbed into normal operations. The reconciliation is just what the finance team does. The data cleanup is just part of the monthly process. The discrepancy investigation is just how things work.
But these are not natural costs of running a business. They are the direct, measurable cost of systems that are connected on paper and disconnected in practice.
Where to start
If you recognise the patterns described in this article, the first step is an honest audit of your current integrations.
For each connection between your systems, ask: is it automatic, or does it rely on a person or a schedule? Is it real-time, or is there a delay? Does it handle exceptions, or does it fail silently? When was the last time someone verified it was working correctly? Does it reflect your current business rules, or the ones that existed when it was built?
The answers will tell you whether you have integration or an approximation of it. And the gap between the two is where your operational cost, risk, and frustration live.
