Ask a business owner what their software costs and you'll get a figure from the accounting system: the sum of the monthly subscriptions. It is a real number, it is easy to find, and it is almost never the actual cost.
The expensive part of a fragmented stack is not the licences. It is the labour that exists only because the tools don't talk to each other — and that labour is invisible in the accounts, because it is buried inside salaries you would be paying anyway.
Here is a way to make it visible.
Line 1: the licences (the easy one)
Export twelve months of card and bank transactions, filter for software vendors, and total it. Two things usually surface immediately.
Tools nobody uses. Almost every company finds at least one subscription still billing for a project that ended, a person who left, or a trial that quietly converted. This is the cheapest saving you will ever make and it takes an afternoon.
Seat counts that grew silently. Per-user pricing means your software bill scales with hiring. Check whether you are licensing people who log in monthly — or never.
Add it up. Call this L.
Line 2: the re-keying tax
This is the one that matters, and the only way to get it is to ask.
Pick the three roles that touch the most systems — usually operations, finance and whoever owns customer delivery. Ask each person one question: how much of your week is spent moving information from one system into another? Copy-pasting, re-typing, exporting to a spreadsheet to combine two reports, checking whether two systems agree.
Don't ask them to estimate a percentage in the abstract; ask them to walk through last Tuesday. The answers are consistently higher than management expects and consistently lower than the person feared to say out loud.
Then: hours per week × loaded hourly cost × 52 × number of people doing it. Call this R.
For a twenty-person services business, R is routinely several times L. This is the number that changes the decision, and it is the number nobody has.
Line 3: the integration you maintain
Count the connections between your tools — Zapier scenarios, native integrations you configured, the sync somebody's cousin built in 2023, the scheduled export that lands in a shared drive.
Two costs here. The subscription cost of the automation platform, which is small. And the cost of maintenance: every time a vendor changes an API or a field name, something breaks, and someone spends a day working out why the numbers stopped matching.
The uncomfortable part is that this cost grows faster than the tool count. Five tools have ten possible connections; ten tools have forty-five. You never build all of them, but the ones you do build get harder to reason about as the web thickens.
Estimate the days per year spent fixing broken syncs. Call this I.
Line 4: decisions made on stale data
This is the hardest to quantify and often the largest.
You cannot put a clean number on it, so don't try to fake precision. Instead, count incidents over the last year:
- Times you discovered a project was over budget only after it closed
- Orders lost or duplicated because two systems disagreed
- Stock written off that a live view would have caught
- A renewal conversation that started late because the expiry sat in a spreadsheet
- Reports rebuilt by hand because nobody trusted the automated one
Put a conservative figure on each. Even at conservative values, the total usually startles people. Call this D.
Putting it together
Your real annual software cost is L + R + I + D, not L.
Now compare that against the alternative honestly. A consolidated system has its own costs: a build, hosting, and ongoing maintenance. What it does not have is per-seat pricing that scales with hiring, or an integration burden between modules that share a database.
The break-even is genuinely business-specific. A twelve-person company with three tools should almost certainly keep buying products — we say so plainly in custom software vs off-the-shelf SaaS. A sixty-person operation where one workflow crosses five systems is usually already paying more in R than a build would cost, without anyone having noticed.
The licences are what you see. The labour is what you pay.
Two traps when running this
Don't count time you'd spend anyway. The question is not "how long does invoicing take" but "how much of invoicing exists only because the data starts somewhere else". Be strict; an inflated number helps nobody, least of all when you present it internally.
Also worth saying: not every re-keying task disappears with consolidation. Some of it is genuine work. Aim to identify the portion that is pure translation between systems — that is the part that goes away.
Don't ignore the switching cost. Consolidation is a project with real risk. It is fair to weigh that against the annual bleed, and we've written about how to sequence it so the business doesn't stop in replacing ten tools without downtime.
What to do with the number
Even if you change nothing structural, the exercise pays for itself. Most companies find enough in line 1 alone to cover the afternoon it took. And if lines 2 to 4 come back large, you now have the thing that was previously missing from the conversation: a figure to compare against, instead of an instinct that the current setup is "probably fine".
If you want a second pair of eyes on the result, that is roughly what our first call is — mapping where the process bleeds, and giving you a straight answer on whether consolidating is worth it for your size. Sometimes the answer is no. Book a call if that's useful.
