ERP vs a stack of separate tools: the real cost

2026-07-17 · 6 min read

Diagram contrasting several disconnected tools, where every join requires data to be copied or reconciled, with one connected system holding a single set of data.The cost is in the gapsA stack of toolsAccountsCRMStockExcel!!!every join = re-keying, reconciling, chasingHidden costerrors, stale numbers, fragile integrationsOne connected systemSingle set of datano joins, so nothing to reconcileVisible costone licence, one setupFeature comparisons hide the joins. Your team's week does not.

There's a genuine argument for building operations from specialist tools: each one is better at its job than a general system's equivalent module. So why do so many growing businesses eventually consolidate?

Because the comparison everyone runs — feature against feature — measures the wrong thing.

Diagram contrasting several disconnected tools, where every join requires data to be copied or reconciled, with one connected system holding a single set of data.The cost is in the gapsA stack of toolsAccountsCRMStockExcel!!!every join = re-keying, reconciling, chasingHidden costerrors, stale numbers, fragile integrationsOne connected systemSingle set of datano joins, so nothing to reconcileVisible costone licence, one setupFeature comparisons hide the joins. Your team's week does not.

The cost is in the gaps, not the tools

Every boundary between two systems is a place where data has to be copied, reconciled or chased. Those hand-offs are invisible on a feature comparison and very visible in your team's week.

Four tools have six possible connections between them. Six tools have fifteen. The tools grow linearly; the joins grow much faster.

Three costs that don't appear on any invoice

Re-keying and the errors it brings

Every manual transfer is time plus an error rate. The errors are the expensive part, because they surface later — usually at month-end, usually under time pressure.

No single source of truth

When two systems disagree, someone has to decide which is right. That decision is often made by whoever shouts loudest, and it erodes trust in every number.

Integrations that break quietly

The worst failure mode isn't an integration that stops — you notice that. It's one that half-works: syncing most records, silently dropping some. By the time anyone spots it, the data has been wrong for weeks.

If you can't answer "when did that last sync, and did it work?" for every connection you depend on, you have this problem — you just don't know its size yet.

When separate tools genuinely win

This isn't one-sided. A stack is the better shape when:

  • One function is so specialised that a general module genuinely can't do it
  • You're small enough that the joins are few and manageable
  • You need to move fast and can't wait for a consolidated build
  • The tools you rely on have mature, well-supported integrations — not one-off scripts

When consolidation pays off

The tipping point usually arrives with these together: you're re-keying data daily, you're arguing about which figure is right, and you're waiting on reports that span more than one system.

At that point one connected system usually wins — not because it's better at any single job, but because it removes the joins entirely. You stop paying the integration tax.

A fair way to compare

Don't compare features. Compare total time to a trustworthy number. Take one real question — this month's margin by product line — and count every system touched, every manual step and every reconciliation needed to answer it confidently. Then ask what that looks like in a connected system.

That comparison tends to settle the argument quickly, in whichever direction is right for you.

Frequently asked

Isn't an ERP just a stack of tools from one vendor?
Partly — the difference is that the modules share one data model, so there are no joins to reconcile. That's the whole point.
Can we keep our best tools and connect them to an ERP?
Often yes, and it's a common middle path. The discipline is choosing which system owns each piece of data and holding to it.
How do we cost the gaps?
Track re-keying time for a fortnight and add the reconciliation work at month-end. That number is usually enough to make the decision obvious.
What if we consolidate and lose functionality?
It happens, and it's worth mapping up front. The question is whether the lost feature costs more than the joins you remove.
Take the free Health Check

Take the free Health Check

← All insights