What to Do When Two Systems Disagree About Who Your Customer Is

A single source of truth is a written decision about which system's version of a fact wins when the systems disagree. It is not a database, not a migration and not a project. It is a rule, and most companies have never written one down.

You already know the symptom. Finance says the account is called Northgate Logistics Ltd, the CRM says Northgate Logistics, support has them under an old trading name, and the billing email in one is a person who left in March. Somebody notices when an invoice bounces. Then everybody agrees the data is a mess, someone volunteers to clean it up, and four months later there are three slightly different messes.

The clean-up is not the fix. The clean-up is the thing you will do again next year.

Why the systems disagree in the first place

Every tool your business runs was bought to solve one department's problem, and each one quite reasonably models the customer the way that department thinks about them.

Sales think in opportunities. The customer is the person who will sign. Finance think in legal entities. The customer is whoever the contract names and whoever the money comes from. Support think in users. The customer is whoever raised the ticket. Marketing think in email addresses.

None of those is wrong. They are four different objects that happen to share a name. When your CRM and your accounting package disagree about who the customer is, they are usually not disagreeing at all. They are answering different questions and you are reading both answers as one.

That distinction matters because it changes the fix. If two systems hold contradictory versions of the same fact, one of them is wrong and you need a rule. If two systems hold different facts that you have been treating as the same fact, you need a definition first, and no amount of syncing will help until you have one.

Write the definition before you touch anything

Take the word "customer" and say out loud what it points at in your business. One sentence. Most companies under fifty people land on something like: the legal entity we invoice.

Then take every other word that has drifted. Account. Contact. User. Client. Site. For each, name the system that is allowed to create one.

This sounds like bureaucracy and takes about twenty minutes. It is the only part of the job that cannot be delegated to a tool, because it is a business decision wearing a technical costume. Nobody can tell you whether a franchise with nine branches is one customer or nine. You have to decide, and the answer changes your reporting, your pricing and who gets counted in your churn number.

Then decide per field, not per system

Here is where most attempts go wrong. Someone declares the CRM the single source of truth, everything else syncs from it, done. Six weeks later finance are back in the accounting package editing addresses by hand, because the CRM's address is the one the salesperson typed and the invoicing address is different and always was.

Truth is not held by a system. It is held by whoever actually maintains a field.

So go field by field on the record that matters most, and write the owner beside it. Something like this:

Legal name and registered address: the accounting package owns it, because finance are the only people who ever have a reason to correct it, and they correct it the day an invoice is wrong.

Billing contact and payment terms: accounting again, same reason.

Deal stage, forecast, owner: the CRM, because that is where the work happens and nowhere else has an opinion.

Primary technical contact, sites, installed kit: whatever your service desk runs on, because the engineer on the job is the only person who finds out the day it changes.

Marketing consent: whatever captured it, and nothing may overwrite it. Consent is a record of what somebody actually clicked and it is not a field you tidy.

Four or five lines like that is a source-of-truth policy. It fits on one page. It survives a tool change, which a migration does not, because it describes who maintains a fact rather than where the fact happens to sit this year.

Make the rule visible where the work happens

A policy nobody can see is a policy nobody follows. The cheapest enforcement is not integration, it is labelling.

Turn off create permissions where a record should never be born. If only the accounting package may create a customer, the CRM should not let a rep type a new company name into a free-text field at ten to five on a Friday. Where a field is owned elsewhere, make it read only and say where it comes from. People are perfectly happy to respect a rule they can see; they route around one they have to remember.

Then accept that some fields will be entered twice by a human, on purpose, and that this is fine. A sync you have to babysit costs more than a person retyping a postcode four times a month.

Where this genuinely is not worth doing

Under about ten people, skip it. With one salesperson and one bookkeeper, the reconciliation happens in a conversation and it takes forty seconds. Writing a policy for that is procedure for its own sake, and it will not be read.

Skip it too if the disagreement only ever shows up in one report that one person reads once a quarter. Fix the report.

And be honest about the limit of the whole approach: a source-of-truth policy does not make your data correct. It makes it consistently wrong in one place instead of differently wrong in four, which is a real improvement but a smaller one than people expect when they start. If the underlying records are rotten, you still have to go and fix them, and the policy only stops them rotting again.

The order that works

Define the words. Assign each field an owner. Make the ownership visible in the tools. Only then, if a field genuinely needs to exist in two places, automate the copy in one direction with the owner as the origin.

Most teams do this in reverse. They start with the integration, discover the two systems mean different things by "customer", and end up with a sync that faithfully propagates a disagreement.

One more thing, and it is the reason this problem hides for years. The disagreement rarely lives inside a system. It lives in the handover between two of them, in a step somebody does by hand every week that nobody has ever written down. You find those by tracing the work rather than by auditing the databases. abi. Clone builds a free working model of how your business actually runs, department by department and system by system, so the handovers show up as the connections they are. Building it, editing it, exporting it and presenting it are free on any account, with no card and no time limit.

Start with the record that costs you money when it is wrong. For most businesses that is the one you invoice. Get its five fields owned, and the rest of the argument tends to settle itself.