So this comes up on almost every first call. Somebody pulls up their CRM and it says one number of customers, then they pull up their accounting and it says a different number, and usually somebody in the room is a little embarrassed about it, like it's a housekeeping failure. And I always say the same thing, which is that both numbers are probably right. They're just counting different things.

They're not counting the same thing

The CRM counts relationships. A lead that never bought is in there. A contact at a company is in there right next to the company itself. A customer with three locations might be three records because three different reps entered them. The accounting system counts who you've billed, so it's one customer, one payer, and if two locations get one invoice, that's one customer as far as the books are concerned.

So right away you've got leads versus payers, contacts versus companies, and locations versus billing entities, and none of that is an error. It's three definitions of the word customer living in two systems, and the number you want depends on the question you're asking. If you want to know how many people could buy from you, the CRM number is closer. If you want to know how many did, it's the books.

The part that actually is an error

And then underneath the definitions there's the real mess, which is the same person entered three different ways.

You've got Bob Smith in the CRM and Robert Smith in the books. You've got an email typed with a capital letter in one place and lowercase in another, which a lot of systems treat as two different addresses. You've got a phone number stored as (801) 555-0100 in one system, 801-555-0100 in the second, and 8015550100 in the third. You've got an address with Street spelled out in one and St in the other, and Suite 200 versus Ste 200 versus #200.

Every one of those creates a customer that doesn't exist. And it's not the software's fault, right? Nobody ever told the two systems they were talking about the same person.

How to actually match them

So the way you fix this is not by cleaning up one system to look like the other. You leave both systems alone and you build the match in a layer that sits across them. And there's an order to it.

Number one, normalize before you compare. Emails get lowercased and trimmed. Phone numbers get stripped to digits and put into one international format, which is the E.164 standard the phone networks themselves use, so 801-555-0100 and (801) 555-0100 both become +18015550100 and now they match. Addresses get run through the Postal Service's addressing standards, which is the same list the post office uses to turn Street into ST and Suite into STE, so both versions collapse into one.

Number two, match in tiers, most reliable first. An exact email match is the strongest signal you have, so take those first. Then phone. Then name plus normalized address. And you keep a confidence score as you go, because J. Smith at 123 Main matching John Smith at 123 Main St is probably the same person, but you want a human to say so, not the software.

Number three, and this is the one people skip, keep every original record. Don't merge Robert into Bob inside the CRM. The moment you do that you've lost the history of how he got entered, and the accounting system doesn't know you did it, so the two drift right back apart. What you want is one customer identity with edges out to every record that belongs to it. The CRM record stays, the accounting record stays, and the identity knows they're the same person.

What you get when it's done

Now when you ask how Robert Smith is doing, you get one answer with his deals, his invoices, his open ticket and his last job under it, and you can see which system each piece came from. And when you ask how many customers you have, you can finally ask it properly. How many people paid us in the last twelve months, how many have an open deal, how many have both. Those are three different numbers, and now they're three honest numbers instead of two systems arguing.

That's how Liaison holds it. Every source record stays exactly where it lives, the identity gets resolved once in the layer on top, and every answer about a customer traces back to the records it was built from. We wrote earlier this year about the fourteen fields named Status that make this hard, and about doing all of it without migrating anything. This is the piece in between, getting the systems to agree on who they're talking about.

So if your CRM and your books are off by a few hundred customers, don't clean it up by hand. Bring both exports and let's see how many of those are definitions and how many are Robert.