Every business that runs on six separate tools is paying for a seventh one that nobody chose, nobody budgeted for, and nobody can cancel. It is the work of keeping the six agreeing with each other, and it is usually the most expensive software in the building.
The stack arrives honestly. A CRM because the sales follow-ups were being lost. Accounting software because the CA needed it. A spreadsheet for stock because the accounting package was awkward about batches. A separate payroll service because statutory calculations are frightening. A POS because the shop needed a till. Each decision was right on the day it was made. Nobody ever decided to run a business on six disconnected databases, and yet here we are.
This is an attempt to price that honestly — because “best of breed versus all in one” is usually argued on features, and features are not where the money goes.
Where the cost actually lands
Four places, in increasing order of how much they hurt and decreasing order of how visible they are.
Re-entry
The cheapest and most obvious. A customer exists in the CRM, again in the accounting software, again in the POS, and in slightly different form in each. A sale is entered where it happens and again where it is counted. This is boring, measurable, and it is the part people assume is the whole problem.
Reconciliation
Someone has to make the six agree, usually monthly, usually one person, usually without a job title that mentions it. When they are on leave, the business discovers how much of its reporting was actually them. This is the cost that survives every attempt to automate it, because the sources genuinely disagree and resolving a disagreement needs judgement.
Latency
The gap between a thing happening and the rest of the business knowing. Sales commits stock that was promised that morning. Collections chase an invoice paid last week. Purchasing reorders a part that arrived yesterday. None of these is a mistake by the person who made it; each is a correct decision on stale information. The cost shows up as credit notes, dead stock and customers told two different things.
Unanswerable questions
The expensive one, and the one that never appears on an invoice. “What did this job cost us against what we quoted?” needs timesheets, purchases, stock issues and the quotation — four systems. So the question stops being asked, and the business runs on instinct in exactly the places where it could have run on arithmetic. Nobody notices a decision they did not get to make well.
A rough way to price it for your own business
You do not need a consulting engagement for this. An afternoon gets you close enough to decide.
- Count the systems that hold a customer, a product, or a money amount. Include spreadsheets. Include the WhatsApp group if dispatch is coordinated there, because that is a system.
- For one week, have people note each time they type something that already exists somewhere else. Not a time study — a tally mark is enough.
- Ask whoever does month-end how many hours it takes, and how much of that is making systems agree rather than producing numbers.
- List the last five questions someone asked that took more than a day to answer. Price the delay, not the labour: what did the business do in the meantime?
- Price the time at fully loaded cost, which is usually 1.3 to 1.5 times base salary — not the salary.
Two things typically come out of this. The re-entry number is smaller than people expect, and the reconciliation and latency numbers are larger. And somewhere in the list of five questions there is one that, answered reliably, would be worth more than the entire software budget.
Integrations help, and they do not solve it
The obvious answer is to connect what you have, and sometimes that is right. A well-built integration between two systems that each own distinct data is genuinely good engineering.
What it does not do is make one record out of two. After the integration there are still two databases, two schemas, two ideas of what a customer is, and now a sync in between that can fail, lag, or succeed while writing something subtly wrong. You have added a component to maintain, and the failure mode is worse than before: previously the two disagreed visibly; now they disagree quietly because everyone believes the sync.
Three questions decide whether an integration is the right call:
- Do the two systems genuinely own different things, or are they both trying to own the customer? Two owners of one record is not an integration problem, it is a design problem, and a sync will not fix it.
- Is the data flow one-way? One-way is tractable. Two-way means conflict resolution, and conflict resolution means somebody has to decide which side wins when both changed — a decision that is almost never written down.
- Who owns the sync at 9pm when it breaks? If the answer is “we would raise a ticket with both vendors”, you do not own it, and neither of them does either.
What “all in one” has to mean to be worth it
Plenty of software is sold as all-in-one and is really a suite of separate products behind one login, acquired over time and stitched together — which means you have bought the integration problem again, at a higher price, with less ability to see it.
The distinction that matters is whether there is one record engine underneath. The test takes one question: what happens to the stock figure at the moment you raise an invoice? A sync, a nightly job, or a person means separate products. One movement ledger, with the invoice having written a line in it, means it is real.
Orbis is built that way deliberately — every module shares the same forms, permissions, audit trail, import, reporting, numbering and API — and the consequence is worth stating plainly, because it is the actual benefit: a module you switch on next month inherits all of it. No new login, no new permissions model to configure, no new export format, no sync. Adding one is a setting, not a project. It is also why modules are sold individually rather than as a bundle: there is no technical reason to make a workshop pay for a kitchen display.
Where best-of-breed genuinely wins
This is not an argument that one system should do everything, and a vendor who tells you otherwise is selling rather than advising. Keep a specialist tool when:
- The function is deep and self-contained. Tax filing, payroll for a complex multi-state workforce, or design and engineering tools are not better for living inside your ERP.
- The specialist is the system of record for data your business does not otherwise own — a bank, a payment gateway, a logistics provider, a marketplace.
- Switching cost is high and the pain is low. A tool nobody complains about and which nobody else needs to read from can be left alone indefinitely.
- Regulation or a customer requires that specific system. That decision has already been made for you.
The rule of thumb we use: consolidate where the same record is touched by more than one team, keep specialists where one team owns the whole thing. Sales, purchase, stock, accounts and payroll fail that test almost every time — they are all reading and writing the same handful of records, which is exactly why they drift apart.
A sequence that works
Replacing six systems at once is how these projects fail. The order that works is dull:
- Consolidate the two that argue most. Usually billing and stock, because the argument between them is visible in your credit notes.
- Run that for a quarter. Confirm the month-end hours actually fell. If they did not, stop and find out why before spending more.
- Add the modules that read from what you have just consolidated — receivables and ageing, then purchase.
- Leave the genuine specialists alone until there is a specific reason to move them, and integrate one-way where you need their data.
Measure the thing you set out to change. Month-end hours, credit notes per month, days from delivery to invoice, how long a question takes to answer. Those four move within a quarter if the consolidation was real, and they do not move at all if you have simply bought six tools with one login.
The summary
Separate tools are not a mistake; they are what growth looks like. But at some point the work of keeping them agreeing becomes the largest line in your software budget, and it is invisible because it is paid in your own people's time rather than on an invoice.
If you want that priced for your own business rather than in the abstract, book a walkthrough — tell us the six systems and the last five questions that took a week, and we will tell you which two to consolidate first and which ones to leave alone.
Frequently asked questions
Is an all-in-one ERP always cheaper than several separate tools?
On licence cost, often not — a good single-purpose tool can be very cheap. The saving is in reconciliation, latency and the questions you can finally answer, and those are paid in your own people's time rather than on an invoice. Price both sides before deciding: count month-end hours spent making systems agree, and count the decisions made on stale data. If those numbers are small, your current stack is fine.
How do I tell a real all-in-one platform from a suite of separate products behind one login?
Ask what happens to the stock figure the moment you raise an invoice. If the answer involves a sync, a nightly job, or a person, they are separate products and you will own the integration problem again. If the answer is that there is one movement ledger and the invoice wrote a line in it, the integration is real. A second good question: when you switch on a new module, does it already have your permissions, numbering, audit trail and export formats, or does it need configuring from scratch?
We already have integrations between our tools. Is that not the same thing?
It is better than nothing and it is not the same. After an integration there are still two databases and two ideas of what a customer is, plus a sync in between that can fail, lag, or quietly write something wrong. The failure mode gets worse, not better: before, the two disagreed visibly; afterwards they disagree while everybody trusts the sync. Integrations work well for one-way flows between systems that genuinely own different data, and badly when both sides think they own the customer.
Which systems should we consolidate first?
The two that argue with each other most, which in most businesses is billing and stock — the argument shows up in your credit notes and in stock promised twice. Consolidate those, run a quarter, and check whether month-end hours actually fell before spending anything more. Then add the modules that read from what you just consolidated, usually receivables and purchase.
Do we have to replace everything we use?
No, and you should not want to. Keep specialist tools where one team owns the whole thing end to end and nobody else needs to read from it — tax filing, engineering tools, a payment gateway, a logistics provider. Consolidate where the same record is touched by more than one team, because that is where the drift happens. With Orbis the modules are sold individually, so this is a real choice rather than an all-or-nothing one.
