You can't see all your numbers in one place because each of your systems reports its own slice of the business, and the only thing joining them together is a person with a spreadsheet at month-end. The accounts know revenue and cash, the CRM knows the pipeline, the timesheet or stock system knows what operations did, and none of them knows the others exist. The fix is one reporting model that reads from each system on a schedule, with one written definition per number, built one source at a time and reconciled to the ledger before anyone relies on it. You don't need to replace your systems with a new all-in-one platform to get there.
Is it just us?
No. Sage published research on 23 September 2026, based on a survey of 1,500 owners and senior decision-makers at UK SMEs (Sage, "The £31bn tech tangle"). Its findings, as of September 2026:
- The average SME uses 52 digital tools and 27 separate logins.
- Nine in ten spend significant time manually moving and re-entering information between systems.
- That costs the average SME 19 working days a year, which Sage values at around £5,700 per business and an estimated £31 billion across the UK economy.
- Only one in ten can see their full financial picture in one place.
- 62% say having information spread across different systems makes it harder to understand the financial health of the business.
- 42% say their financial information is too spread out to make better use of AI.
None of that is a criticism of the tools. Each of those 52 tools was bought for a good reason, and most of them do their job well. Xero, Sage, QuickBooks and Business Central are very good at keeping a ledger. HubSpot, Salesforce and Dynamics 365 Sales are very good at running a sales team. A timesheet, job or stock system is very good at recording the work. The gap is between them, and no single vendor owns the gap.
Why don't our numbers match?
Because each system answers a slightly different question with the same word. "Revenue" in the CRM usually means deals marked as won. "Revenue" in the accounts means invoices raised, net of credit notes, excluding VAT. Both are correct by their own rules. They will never agree, and the meeting ends up debating whose number is right. I've written up the mechanics of this in how six reports end up with six different numbers; the table below applies it to the numbers leadership asks for.
| The number leadership asks for | Where it usually lives | Why the versions don't match | What one agreed definition looks like |
|---|---|---|---|
| Sales this month | Accounts (Xero, Sage, QuickBooks, Business Central) as invoices; CRM (HubSpot, Salesforce, Dynamics 365 Sales) as won deals; a sales spreadsheet as orders | Won date vs invoice date vs order date; VAT in or out; credit notes counted or not | Revenue = invoiced sales net of credit notes, excluding VAT, by invoice date, from the ledger. Won deals are reported separately and called bookings |
| Gross margin | Accounts P&L; job or project system; a margin spreadsheet | Which costs count as direct; stock and accrual journals only posted at month-end; the spreadsheet uses a standard cost | Revenue less the cost of sales nominal codes listed on the definitions page, month-end journals included. Job margins must add back to the ledger total |
| Cash and overdue debt | Accounts and bank feed; a credit control spreadsheet | The spreadsheet is updated weekly; disputed invoices quietly left out; aged by invoice date in one, due date in the other | Sales ledger balance past its due date as at the latest refresh, from the ledger, with the over-90 figure shown. Disputed invoices stay in, flagged |
| Pipeline and forecast | CRM; a forecast spreadsheet on top of it | Stale deals left open; each salesperson uses the stage probabilities differently; the spreadsheet overrides the CRM | Open deals with a close date in the next 90 days, weighted by one agreed probability per stage, excluding deals with no activity in 60 days |
| Utilisation or capacity | Timesheet system; HR or payroll; a resourcing spreadsheet | Different denominators (contracted hours, available hours, a flat 37.5); contractors in or out | Billable hours divided by available hours (contracted, less holiday and sickness), from the timesheet system, per person per week |
| Stock value | Stock or ERP system; the stock control account in the ledger | The stock system values continuously, the ledger at the month-end valuation journal | Stock at cost per the stock system, reconciled to the ledger's stock account every month-end, with any difference shown on the page |
Source: my working set from the leadership reporting I build for UK businesses. The definitions are starting points. Yours should be written, and signed off, by the person who owns each number.
What does a single source of truth actually mean?
In practice it's three modest things:
- One place the numbers are calculated. A reporting model that reads from each system, instead of a dozen spreadsheets each calculating their own.
- One written definition per number, with a named owner. The argument about what "gross margin" means happens once, at design time, and the answer is printed on a definitions page anyone can open.
- A reconciliation that proves it. Every refresh, the model's totals are checked against the ledger. If they don't tie, it's fixed before anyone reads the page.
The systems stay exactly where they are. The model sits alongside them, reads from each on a schedule, and does the join a person currently does by hand. That's what good management information looks like in a growing business: one version of the truth, arriving on its own, that nobody rebuilds at month-end.
Do we need a new ERP or a data warehouse first?
You don't need a new ERP or a data warehouse to start.
Replacing your systems with one all-in-one platform is sometimes the right call for operational reasons, such as an old system going out of support. For reporting alone it's the slowest and most expensive route, and budgets and targets usually stay in spreadsheets anyway, so the definitions problem moves house with you.
A data warehouse earns its place later, when there are several systems, large volumes of data, or other teams who need the same cleaned-up data. Until then, a reporting model reading straight from the accounts and then the CRM goes a long way.
Where do we start?
In this order. Each step produces something leadership can use before the next begins.
1. Agree the six to ten numbers and their definitions. The numbers the leadership team would act on. A useful test: if this number moved a lot, would someone do something this week? If not, it belongs on a detail page. Each number gets a definition, a source system and an owner. This is a meeting, not a project, and it's the most valuable hour in the whole exercise.
2. Start with the one system that holds most of them. Usually that's the accounts. Revenue, gross margin, cash and overdue debt all come from the ledger, which means the first version of the page is a single-source build and can exist within weeks.
3. Reconcile to the ledger to the penny. Revenue on the page must match the P&L. Overdue debt must match the aged debtors report. A director who finds one difference goes back to their spreadsheet, so the reconciliation goes on its own page where anyone can check it.
4. Add the next system with a shared key. Usually the CRM. The join needs something both systems hold: the customer account code from the accounts, stored on the CRM company record, or the job number used in both the timesheet system and the ledger. If the key doesn't exist yet, adding it is the first task: a data-entry habit more than a technology problem.
5. Schedule the refresh. Every morning, before people arrive, so nobody exports anything by hand again, with the as-at time printed on the page.
6. Build one page leadership actually opens. Six to ten numbers, each against target and last period, readable on a phone, with every breakdown one click below the number it explains. The monthly board pack draws on the same definitions and adds the commentary (there's a template for that in A Board Report Template That Gets Read).
The order to connect things in, for most businesses:
| Order | Source | Numbers it brings | Shared key to the rest | Checked against |
|---|---|---|---|---|
| First | Accounts (Xero, Sage, QuickBooks Online, Business Central) | Revenue, gross margin, cash, overdue debt, costs | Nominal code, customer account code | Trial balance and P&L, to the penny |
| With the first, or second | Budgets and targets (usually a spreadsheet) | Budget, variance, forecast | Nominal code and month | The approved budget file |
| Second | CRM (HubSpot, Salesforce, Dynamics 365 Sales) | Pipeline, bookings, win rate, customer count | Customer account code on the company record | The CRM's own pipeline report |
| Third | Operations (timesheets, jobs, stock) | Utilisation, job margin, stock, on-time delivery | Job number, product code, employee ID | Job totals back to the ledger; stock to the stock account |
What does it cost, and how long does it take?
Steps two and three are what the First Report is for: one source system (Xero, Sage 50, Sage 200, QuickBooks Online, Business Central, HubSpot, Salesforce, Dynamics 365 Sales, or a folder of spreadsheets), one report answering one question written down on the first call, and the headline figure reconciled back to source to the penny. It's £1,950 fixed, ten working days from the data arriving, published to your own workspace, and the second half is only invoiced once the number ties.
When a second system has to be joined, that's the Reporting Sprint: £9,500 fixed, three weeks, up to three source systems in one documented model, up to eight report pages, and a reconciliation pack proving the numbers match source. The £1,950 comes off a Sprint booked within 90 days, so starting small costs nothing extra if you carry on.
I build these in Power BI, because it can read from every system in the tables above (directly or through a connector) and your team signs in with their Microsoft work accounts. If you'd like to talk through which numbers belong on your page and which system to start with, book a free 20-minute intro call.
Common questions
Why can't we see all our numbers in one place?
Because each system reports only on the data it holds, and joining them has been left to a person with a spreadsheet. Sage's September 2026 survey of 1,500 UK SMEs found only one in ten can see their full financial picture in one place. The fix is a reporting model that reads from each system on a schedule and applies one agreed definition per number.
What does a single source of truth mean for a small business?
One place where the numbers are calculated, one written definition per number with an owner, and a reconciliation that proves the totals match the ledger every time the data refreshes. It doesn't mean one system for everything. Your accounts, CRM and operations systems stay as they are; the reporting model sits alongside them.
Why don't our sales and finance numbers match?
Usually because they're measuring different things with the same name. The CRM counts deals when they're won; the accounts count invoices when they're raised, net of credit notes and excluding VAT. Both are correct. Agree which one the business calls revenue, name the other something else (bookings, for example), and show both.
Do we need a new ERP to get one version of the truth?
No. A new ERP can be the right move for operational reasons, but for reporting alone it's the slowest and most expensive route, and the definitions problem comes with you. A business of 10 to 250 people can usually get one version of the truth from the systems they already run, connected one at a time.
Where should we start?
Agree the six to ten numbers leadership would act on, write down their definitions, and start with the system that holds most of them, which is usually the accounts. Reconcile that first page to the ledger to the penny before adding the CRM or operations data.
How long does it take to get all our numbers on one business dashboard?
A single-source first version, usually on the accounts, can be live in about two weeks; my First Report is ten working days from the data arriving. Joining a second or third system with proper reconciliation takes a few weeks more. Agreeing the definitions and shared keys usually sets the pace.
Is it safe to connect our systems to a reporting tool?
A reporting connection reads from your systems and doesn't write back, so the report can't change invoices, deals or timesheets. Access can be limited to named people, and when I build it everything lives in your own Microsoft tenant, not on my side.