Every tool in your operation was bought to solve a specific problem. The finance system tracks money. The CRM tracks customers. The operations platform tracks jobs. Each one does its job.
But between systems - that is where the data breaks down. A payment confirmed in the finance tool gets retyped into the operations system. A customer captured in the CRM does not exist in the billing platform until someone adds them. A job status updated in the field is still showing this morning's snapshot in the office view.
None of these are technology failures. They are processes that depend on a person remembering to move information by hand. Integration debt is the accumulated cost of all of those manual transfers - and unlike most debt, it grows faster as the business grows, because more volume means more transfers.
How integration debt accumulates unnoticed.
The first manual transfer between two systems is usually introduced because connecting them properly would have taken time the project did not have. The workaround is acceptable. Someone adds it to their daily checklist. The system is delivered.
Six months later, the volume has doubled. The checklist takes twice as long. A second person starts helping. The error rate goes up because two people are now making the same transfer with slightly different interpretations of what should move.
A year later, the manual transfer is in the onboarding documentation. It is no longer a workaround - it is the process. The original system decision that made it necessary is long forgotten. The cost of the transfer is spread across multiple people's time, and no single line item in any budget captures what it is actually costing.
This is how integration debt accumulates. Not in a single moment, but in a series of decisions that were individually defensible and collectively expensive.
The three most common integration debt patterns.
Across the SA businesses we work with, integration debt tends to concentrate in three areas.
Finance to operations
A payment is confirmed or an invoice is raised in the finance system. Someone then manually updates the operations system to reflect the change in status. The two systems are permanently at risk of disagreeing, and every decision that depends on both being current is exposed to that risk.
CRM to billing
A new customer is captured in the CRM. They are not in the billing system until someone adds them - which may happen the same day, or a week later, or when an invoice fails to generate and someone investigates. In the gap between those events, other processes that need the customer to exist in both systems are broken.
Field to office
Work is completed or a status is updated in the field - on a mobile device, via WhatsApp, or verbally. The office view does not reflect this until someone inputs it. Decisions made by management or dispatchers between the field event and the input are made on stale data.
How to measure your integration debt.
The quickest way to audit integration debt is one question: how many times per week does someone in your business manually move information from one system to another?
Count the transfers. Estimate the time. Multiply by the cost of the people doing it - including the cost of errors, reconciliation time, and the decisions that were made on data that turned out to be wrong. That is the annual cost of your integration debt.
Most businesses that do this for the first time find a number that is significantly larger than they expected. The reason is that the cost was always there - it was just distributed across too many job descriptions to be visible as a single line.
The second part of the audit is risk: what is the worst case if one of these manual transfers is missed or done incorrectly? For some transfers, the answer is a minor inconvenience. For others, it is an invoice that does not get raised, a job that does not get dispatched, or a management decision made on the wrong version of the data.
What fixing it actually looks like.
Integration debt is fixed by connecting systems properly - so the data moves when something happens, not when someone remembers. The technical mechanisms for this are APIs, webhooks, sync engines, and event-driven middleware. The choice between them depends on the systems involved and the timing requirements.
APIs are appropriate when one system needs to request information from another on demand. Webhooks are appropriate when one system needs to notify another immediately when something changes. Sync engines are appropriate when two systems need to stay continuously aligned. Event-driven middleware is appropriate when multiple systems need to respond to the same event.
In practice, most integration projects combine several of these. A payment confirmed in the finance system triggers a webhook, which calls the operations system API to update the job status, which triggers a notification to the field. The human transfer is replaced by a sequence of automatic events that complete in under a second.
The business case for integration work is usually clear once the debt is measured. The cost of building the integration is a one-time investment. The cost of the manual transfer recurs indefinitely - and grows as the business grows.
If two of your systems do not talk to each other, and part of someone's job is keeping them in sync, that is worth fixing properly. We can talk through what the integration would involve.
Start a conversation →