Fix disagreeing data by naming one system of record for each type of data.
Data disagrees across systems when the same fact is entered or edited in more than one place. The fix is to name one system of record for each type of data, give records shared identifiers and agreed definitions, clean existing duplicates, and then sync changes outward from that source with monitoring that catches new disagreements early.
A system of record is the place where a piece of information is created and corrected. Customer billing details might live in accounting, contacts and opportunities in the CRM, items and stock in the ERP, and employees in the HR system. Other systems can display and use that data, but they should not quietly maintain a separate version of it.
This sounds obvious, but most companies grow into the opposite. Each department picked a tool that solved its problem, and each tool gained its own version of customers, products, or jobs. Nobody decided that the CRM and accounting should both hold addresses; it simply happened. Naming a system of record for each type of data reverses that drift deliberately.
Find where and why the numbers disagree before changing anything.
Start with the disagreements people actually notice: revenue that differs between the sales dashboard and the finance report, stock counts that disagree between the warehouse and the online store, or customer addresses that differ on quotes and invoices. For each one, trace the number back through every system and spreadsheet it passes through until you find where the paths split.
The causes usually fall into a few groups. The same record is typed into two systems. A sync runs in both directions and overwrites changes. Two reports use different definitions, such as booked versus invoiced revenue or on hand versus available stock. Timing differs, with one system updated live and another overnight. Each cause needs a different fix.
Record what you find in a simple inventory: each important data type, the systems that hold it, where it is created, where it is edited, and how it moves. This inventory often shows that a small number of data types, typically customers, products, and orders, cause most of the reported problems. Those are where to start.
Shared identifiers and definitions keep records matched across systems.
Systems need a reliable way to know that two records describe the same thing. Matching by name or email breaks as soon as a name is spelled differently or a contact leaves. Store the system of record’s ID on the matching record in every other system, and use it for every sync, lookup, and report that joins the data together.
Definitions matter as much as identifiers. Agree in writing on what counts as an active customer, a booked order, revenue for a period, or available inventory, and which system’s field supplies each figure. Many disagreements between reports are not data errors at all but two teams answering slightly different questions with the same word.
Keep these definitions in a short shared document, sometimes called a data dictionary, and link it from the reports that depend on it. Give each definition a named person responsible for deciding changes. When a new report or system is added, check it against the dictionary before it goes live instead of after the numbers are questioned.
Clean the existing data once, then sync changes in one direction.
Before connecting anything, clean the records that already disagree. Merge duplicates, fill missing identifiers, and decide which value is correct where systems conflict, usually by trusting the system of record and reviewing exceptions by hand. Do this against a copy first, keep a log of every merge and change, and plan how to reverse the cleanup if a rule proves wrong.
Then change how data moves. Edits should be made in the system of record and flow outward to the others, through a direct integration, an integration platform, or a scheduled job. Lock or hide the copied fields in downstream systems where possible, so people are guided back to the right place to make a change.
Two-way sync is sometimes necessary, but it should be the exception. When both systems may edit the same field, define which change wins, how conflicts are flagged, and who resolves them. Unmanaged two-way sync is a frequent reason data drifts again after a cleanup, because each system keeps overwriting the other with its latest version.
Reconciliation and monitoring keep the fix from drifting.
Even well-designed syncs fail occasionally. A credential expires, a field is renamed, or a record is rejected because of a missing value. Build a visible error queue so failed records are seen and corrected rather than silently skipped, and alert a named person when the queue grows or a sync stops running entirely.
Add scheduled reconciliation checks for the data that matters most. Compare record counts and key totals between systems, such as open orders, invoiced revenue, or units on hand, and list records that exist on one side only. Reviewing a short exception list regularly catches drift early, when it involves a handful of records rather than months of history.
Where many reports draw on several systems, a central reporting database or warehouse fed from each system of record can give leadership one consistent view without forcing every tool to agree field by field. Baybloom builds these integrations and reporting layers, and the inventory of data types and systems described above is the right place to begin.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project