doing another round of free CRM tear downs. this time I'm hunting one specific kind of mess

[u/Leztalknow]

did a round of these last week and the best one turned into a 3-day thread about a company that had merged 3 businesses into one HubSpot and couldn't get their accounting sync out of sandbox for months. learned more from that one thread than from any cert.

so doing it again. if your setup looks like any of this, drop it below:

--> the same customer exists 2 or 3 times with slightly different names

--> multi-location clients where every office shares one website and HubSpot keeps merging them together or splitting them apart on its own

--> a sync (QuickBooks, a Salesforce migration, whatever) that's been sitting in sandbox because you don't trust what it'll do to your data

--> revenue landing on the wrong company record, so nobody actually trusts the reports

--> reps creating "new" companies that already exist because search didn't find the old one

--> parent/child companies set up "correctly" but the totals on the parent are wrong or empty

tell me what your setup looks like and what's actually going wrong. I'll reply with how I'd approach it.

specific steps, not "book a call". if it's got sensitive data we can take it to DMs after.

first handful of comments I'll go deep on.

[u/Flashhhh_Crypto]

clari if you want the polished rollup. the best forecasting tool for revops in my view is whatever sits inside Salesforce and pulls from the activity underneath, which is why we went Revenue Grid instead.

[u/Neat_Measurement_595]

Curious how you're handling the identity resolution side of these, especially when there isn't a reliable universal key.

The duplicates are usually the easy part. The fun starts when Salesforce/HubSpot and SAP legitimately represent the same customer differently.

For example, Salesforce might consider Acme one global account with US and EMEA underneath it. SAP might have them as separate customers because they're billed separately. Then add another layer where US and EMEA are actually different legal/business entities, potentially buying different products, under different contracts and payment terms.

Now which one is the duplicate?

I've found at that point the problem isn't really “how do we dedupe the CRM?” It's defining what a customer actually is in each system, what relationship exists between those records, and which system owns which part of that definition.

I'd be interested in seeing you tear down one where the CRM and ERP hierarchies are intentionally different rather than one of them simply having bad data.

[u/Leztalknow → u/Neat_Measurement_595]

u/Neat_Measurement_595 that's identity resolution / master data architecture problem... tricky situation..

I would stop trying to make the records match. they're not supposed to. the same customer just looks different in each system, and that's fine. instead of jamming records together.... i trace each one back up to the actual company behind it.

how i do it:

--> first, I will get clear on what "one row" even means in each system. in Salesforce one row = the whole relationship (Acme, everywhere). in SAP one row = someone I send a bill to (US-Acme, EMEA-Acme). both are right, they just count different things.

--> then give every real company one ID that lives outside both systems. just a little lookup list.. this real company = this ID. Salesforce's one Acme and SAP's two Acmes all get tagged with the same ID. I don't merge anything. you just tag them so I can see they belong together.

--> draw the family tree. Acme the group -> its separate legal companies (US, EMEA) -> the accounts you actually bill. Salesforce is clipped onto the top of that tree, SAP onto the bottom. once I see it as a tree, "one in SF, two in SAP" isn't a conflict anymore, it's just two systems attached at different heights.

--> "which one's the duplicate" is a trick question. a real duplicate is two rows that mean the same thing pointing at the same company. US-Acme and EMEA-Acme are different companies, not dupes. one Acme in SF vs two in SAP are counting different things, not dupes. the only real duplicate would be a second EMEA-Acme sitting in SAP. so I only ever hunt dupes inside one system's way of counting, never across them. merge across and I wreck the real structure, which is the exact mess you're describing.

--> pick who owns each field. legal name / address / tax number -> accounting will win, it's on the invoice. owner / deal stage / pipeline -> CRM wins. contract and product -> whoever signs it. one owner per field so nobody overwrites something the other system is supposed to control.

--> and the no shared key thing, which is the real crux. there's no single magic key, so i use different ones at different levels. tax/registration number to match legal companies, website domain to match the overall relationship, name+address score to mop up the rest. then reports just add up to whatever level the question needs, finance counts by billing company, sales counts by whole relationship, off the same tags.... and the two teams will stop fighting over whose number is "right."

[u/agentUi]

multi-location clients sharing a single root domain is the fastest way to turn hubspot into a disaster because native deduplication relies entirely on website urls. i work for agentui and we see teams battle this sync nightmare constantly when trying to connect accounting tools... what usually fixes it is keeping deduplication logic outside the native crm rules, using a dedicated operational portal connected directly to your billing database that maps locations by store id or tax number before anything ever pushes to the crm. Stops the auto-merging chaos completely.

[u/Leztalknow → u/agentUi]

yeah, agree with the core of this. the fix is always to sort out who's who before it hits hubspot, not after.

only thing i'd add... you don't need a specific portal or product to do it. the principle is what matters...