The report is due. The manager is waiting. In the corner of the office, someone is four hours into a VLOOKUP, trying to reconcile two versions of the same data that have never quite agreed with each other.
This scene is not a one-off. It repeats itself, in the same organisation, on the same schedule, performed by the same person or their replacement. It has been happening for years. It will keep happening until someone fixes the thing the VLOOKUP is compensating for.
That thing is not a spreadsheet problem. It is not a skills problem. It is a structural condition: two systems holding the same entity, defined differently, owned by different teams, updated independently, with no rule for which one is correct.
Free · 4 minutes
When two of your systems disagree, do you know which one to believe?
Fourteen questions on ownership, lineage, and quality — the difference between a number on a dashboard and a number you could defend. Banded finding on screen, full sheet by email.
How it happens
Two sources of truth rarely arrive by design. They arrive by addition.
A system exists. It holds product data, or customer records, or contract information. A second system is introduced — a new ecommerce platform, a CRM migration, an ERP upgrade. The second system needs the same data. Someone exports it, imports it, maps it as closely as time allows, and moves on.
The mapping is never perfect. The second system uses different field names, different category structures, different conventions for the same values. Nobody has time to resolve this at implementation. The project is already running late. The data is close enough.
Then both systems are live. Both are updated by different teams with different processes. The product that is a SKU in the warehouse becomes a listing in the ecommerce platform and a line item in the ERP. Each record is slightly different — described differently, categorised differently, updated on different schedules by people who do not know what the other system holds.
The gap widens one field at a time. Quietly. Until the report is due.
What divergence actually costs
The VLOOKUP is the visible cost. The structural costs are larger and less visible.
Reporting becomes a data science problem. A question that should return a query becomes an investigation. Which system holds the correct number? Which was updated most recently? Which reflects the actual state of the business? The answer requires assembling data from two sources and making judgement calls that cannot be automated or audited.
Wrong decisions get made. A manager requests a report. It is built from whichever system the analyst had access to, or trusted more, or reached first. Another manager builds the same report from the other system. The numbers differ. Both believe theirs. Decisions are made on data that does not agree with itself, and nobody in the room knows which version is right.
Synchronisation creates error states. Processes built to keep two systems aligned are among the most fragile in any organisation. A sync runs in one direction, then the other. A record is updated in system A before the sync runs and overwritten by the stale value from system B. A conflict is logged, resolved by the wrong rule, and propagates downstream. The error state is often invisible until it surfaces as a customer complaint or a picking error.
Everything operational becomes harder. Warehousing runs on one definition of a product. Buying runs on another. The ecommerce platform shows a third. Sorting, bundling, kitting, pricing — every operation that touches a product category is working from a slightly different picture. The friction is distributed across the organisation and absorbed as normal.
The root cause is ownership, not data
The data is not the problem. The absence of a canonical owner is the problem.
When two systems hold the same entity, and neither is designated the source of truth, both will diverge. This is not a failure of discipline or diligence. It is the predictable outcome of a structure with no authority. Each team updates the record as they understand it, for their own purposes, without a mechanism to enforce consistency with the other.
The question that was never asked — which system owns this entity, and which references it — is the question whose absence created the problem. Asking it late is harder than asking it early, because by the time it surfaces, the divergence has become load-bearing. Teams have built processes around their version of the data. Reports have been built from it. Decisions have been made using it.
Resolving two sources of truth is not a data migration exercise. It is an ownership conversation followed by a migration exercise. Skipping the first part guarantees the second part fails.
A few rules
Every entity has one canonical owner. Product, customer, order, contract — one system holds the authoritative record. Every other system references it. This is not a technical constraint. It is an organisational decision that must be made explicitly.
A sync process is not a source of truth. Synchronisation between two systems does not resolve ownership. It distributes divergence more efficiently. The ownership question must be answered before the sync is designed.
The VLOOKUP is a diagnostic. When someone is manually reconciling data from two systems on a recurring basis, the effort is not the problem — it is the symptom. The problem is upstream.
Divergent taxonomy compounds over time. Two systems that agree today will disagree tomorrow. Category structures drift. Field conventions diverge. The cost of reconciliation grows with every passing quarter. Fix the ownership structure before the gap becomes too wide to close without a project.
Reporting that requires assembly is not reporting. If producing a standard business report requires combining data from multiple systems and making judgement calls about which values to trust, the data architecture is not fit for the decisions it is being asked to support.
Richard King is CTO at Sixteen Pillars — technical leadership, architecture, and governance for organisations that need it without the overhead of a full-time hire.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.