Single source of truth for SMEs: why leadership teams argue over numbers
Quick answer
A single source of truth is not one dashboard. It is a controlled way of agreeing which system owns each number, what the KPI definition means, who signs off changes, how Power BI and ERP reports reconcile, and what happens when finance, sales and operations all need a different valid view of the same business activity.
Most leadership teams do not argue because they lack dashboards. They argue because the dashboards, spreadsheets and ERP reports are answering slightly different questions.
Sales brings a pipeline number. Finance brings invoiced revenue. Operations brings fulfilled order value. Customer service talks about promised delivery dates. The warehouse talks about what has actually left the building. Power BI sits in the middle and looks guilty because it is the visible place where those differences show up.
That is why "single source of truth" is often misunderstood. It is not a magic database and it is not a single dashboard that replaces every other report. For most SMEs, it is a set of agreed reporting rules: what the number means, where it comes from, who owns it, how it is checked, and when a different version is allowed because the decision genuinely needs a different definition.
If those rules are missing, a new ERP, CRM, Power BI model or automation workflow will not solve the argument. It will make the argument faster, prettier and harder to ignore.
The goal is not one number for every purpose. The goal is one agreed definition for each decision.
Why SMEs end up with different versions of the truth
In a growing SME, reporting usually evolves around pressure. Someone needs a sales number for Monday morning, so a spreadsheet is created. Finance needs a different view for month end, so another workbook appears. Operations needs order status, so an ERP export becomes the local answer. A manager needs a board-pack number, so a manual adjustment is added before the meeting.
None of those steps are irrational. They are usually practical responses to real business needs. The problem is that each workaround creates a reporting definition that may never be written down.
Over time, the business ends up with several numbers that all sound like revenue, margin, stock, OTIF, backlog or sales. They are not necessarily wrong. They are often measuring different points in the process:
- Sales may use quoted, ordered or expected revenue.
- Finance may use invoiced revenue or recognised revenue.
- Operations may use despatched, picked or fulfilled order value.
- Customer service may use promised delivery date performance.
- Power BI may use whichever ERP field was easiest to model at the time.
Those differences are manageable when people understand them. They become expensive when everyone assumes their version is the official one.
Start with the decision, not the dashboard
A common mistake is to start a single source of truth project by choosing the reporting tool. That sounds efficient, but it usually skips the hard part.
Before designing a Power BI report, decide which business decision the number supports. A revenue number for cashflow is not the same as a revenue number for sales performance. A stock number for picking is not the same as a stock number for month-end valuation. A delivery performance number for customer communication is not the same as an operational SLA number for warehouse management.
The first question should be: what decision will this number change?
If the answer is board reporting, the definition may need to reconcile to finance. If the answer is daily operations, the number may need to refresh quickly and expose exceptions. If the answer is workflow automation, the data may need stricter validation because a Power Automate flow can move work, send approvals or trigger notifications without a human checking every row first.
That decision-first approach stops the business forcing every department into one blunt measure. It also makes it easier to explain why two valid numbers can exist without creating chaos.
Write down the definitions people argue about
The quickest way to improve reporting trust is to document the definitions that keep causing arguments. Do not start with every field in the ERP. Start with the numbers that appear in leadership meetings, customer conversations, operational reviews and project steering groups.
For each disputed number, record:
- The plain-English definition.
- The business decision it supports.
- The source system or table that owns it.
- The filters, date logic and exclusions used in the calculation.
- The business owner who can approve changes.
- The reconciliation check that proves the number is still trustworthy.
That is the control layer behind a useful single source of truth. Without it, the report builder becomes the accidental owner of business policy. A DAX measure, SQL query or spreadsheet formula quietly decides what counts as late, open, fulfilled, profitable or at risk.
Good reporting governance for an SME does not need to become bureaucracy. It needs to be enough that the next person can understand why the number is calculated that way and who agreed it.
Choose system ownership field by field
SMEs often say "the ERP is the source of truth" as if that settles the matter. It rarely does.
The ERP may own item master data, stock movements, purchase orders and invoices. The CRM may own active pipeline and prospect information. Finance may own statutory adjustments. The warehouse system may own scan events. A production planning tool may own capacity assumptions. Power BI may combine all of those, but it should not pretend to be the source just because people look at it most often.
Source of truth is not a system label. It is a field-level ownership decision.
For customer records, the billing address may be owned by finance while the delivery instructions are owned by customer service or operations. For product records, the category may be owned by commercial, the unit of measure by operations, the cost by finance, and the barcode by warehouse or master data. For sales, the pipeline stage may belong in CRM while actual revenue belongs in ERP or finance.
This is why a master data ownership matrix is so useful. It turns vague ownership into a practical list: domain, field, owner, source system, validation rule and escalation path.
Make Power BI the published view, not the hidden referee
Power BI is often where reporting disagreements become visible. That does not mean Power BI is the root cause.
A well-built model can give the business a controlled published view: one place where finance, operations and leadership can see the approved definitions, drill into exceptions and understand why a number has changed. But Power BI should not hide unresolved business logic inside measures nobody reviews.
For important KPIs, use visible definition pages, measure descriptions, source-system notes and reconciliation checks. If a report says sales are up 8%, the business should know whether that is ordered value, invoiced value, despatched value, recognised revenue, or something else.
A practical Power BI reporting trust checklist should test four things:
- Does the report have named business owners?
- Do the measures match written KPI definitions?
- Do totals reconcile to ERP, finance or operational control reports?
- Are exceptions visible rather than hidden behind a single summary number?
If those checks are missing, the dashboard may look professional but still fail in the meeting.
Reconcile the numbers before rebuilding the reports
When reporting trust is low, the instinct is often to rebuild the dashboard. Sometimes that is necessary, but it is not the first move.
Start by reconciling the numbers people already dispute. Take a small set of real examples: ten orders, ten customers, ten products, ten invoices, ten deliveries. Trace them from source system to report. Find where the definition changes, where a status is missing, where a spreadsheet override appears, or where the Power BI model uses a field that the business no longer trusts.
That exercise usually reveals whether the problem is:
- A data quality issue, such as duplicates, blanks or invalid categories.
- A definition issue, such as using order date instead of despatch date.
- A model issue, such as the wrong relationship or filter context.
- An ownership issue, where nobody is authorised to approve the rule.
- A process issue, where transactions are not being completed consistently.
This is the same discipline used in post ERP go-live reporting rescue. The report is only the end of the chain. The real work is tracing the number back through data structures, process behaviour and business definitions.
Do not automate unclear truth
A single source of truth matters even more when the business starts automating processes.
If a workflow is driven by unreliable status, owner, value or approval data, automation scales the problem. A purchase approval goes to the wrong person. A customer reminder is sent too early. An exception alert fires every day until people ignore it. A shared mailbox flow routes work based on a category nobody owns.
Before building workflows, check the fields that decide what the automation will do. Who owns the approval threshold? Which system owns the requester, approver, supplier and value? What happens when the field is blank? Where is the exception logged? How does the business prove the flow did what it was supposed to do?
That is why Power Automate, Power BI and data management should not be treated as separate conversations. The reporting definition often becomes the workflow rule. If the definition is weak, the automation inherits the weakness.
Build a small control model first
For most SMEs, the practical route is not a large data governance programme. It is a small control model around the numbers that matter most.
Start with five to ten KPIs that leadership actually uses. For each one, create a one-page definition: what it means, why it matters, source system, owner, calculation rule, exclusions, refresh timing and reconciliation method. Add a simple issue log for disputed numbers. When someone challenges a figure, capture the reason and decide whether the definition, data, process or report needs to change.
Then build the reporting model around those definitions. Power BI can show the published number, the drill-through detail, the exception list and the reconciliation status. ERP remains the transaction system. Finance retains the month-end truth. Operations gets the daily view it needs. Leadership gets clarity instead of a meeting full of competing spreadsheets.
This is also the right foundation for digital transformation consultancy. Digital transformation is not just moving from spreadsheets to apps. It is improving the way decisions, processes and data work together.
A practical checklist for creating one version people trust
If your business is arguing about numbers, use this first-pass checklist:
- List the KPIs that cause repeated disagreement.
- Write the business decision each KPI supports.
- Define the approved calculation in plain English.
- Name the source system and business owner.
- Document date logic, filters, exclusions and manual adjustments.
- Agree when alternative definitions are valid and label them clearly.
- Reconcile the published number to ERP, finance or operational control reports.
- Expose exceptions and disputed records, not only headline totals.
- Review the definition when process, ERP, CRM or reporting changes are made.
That checklist is not glamorous, but it is what makes a dashboard useful. It gives people confidence that the number has a purpose, an owner and a test behind it.
The takeaway
A single source of truth is not a technology purchase. It is a business agreement supported by data, systems and reporting discipline.
For SMEs, the win is practical: fewer leadership meetings wasted on whose spreadsheet is right, fewer Power BI rebuilds caused by unclear definitions, fewer automation mistakes caused by unreliable fields, and better ERP or reporting decisions because people know which number they are using and why.
Start with the decisions that matter. Agree the definitions. Name the owners. Reconcile the reports. Then publish the trusted view.
If the business cannot do that yet, the next step is not another dashboard. It is a focused ERP Data Readiness Review or reporting trust review that finds where the definitions, source systems and ownership are breaking down.
Do your leadership reports tell different stories?
Digital Adaption helps UK SMEs define KPI ownership, reconcile ERP and Power BI reporting, and build a controlled single source of truth before reporting or automation work gets expensive.
View reporting rescue support