This specification is for the operations lead at a consultancy, accounting firm, managed service provider, agency or fund who keeps referral records apart from client work and wants one record per company, whatever the company calls itself.
Why domain matching splits some companies and fuses others
Most CRMs reach for the web domain first. HubSpot's help page on deduplication says, in our paraphrase, that it automatically deduplicates companies added by import or form using the primary company domain, while companies created through its API, including by installed sync apps, are not deduplicated that way. A domain is a fine hint and a poor key, because brands and entities do not line up with domains.
HubSpotThe U.S. Small Business Administration's naming guide explains the gap. A DBA, also called a trade name, fictitious name or assumed name, lets a business operate under a name that is not its entity name; registering one gives no legal protection by itself, most states still require registration, and the entity name, any trademark and any DBA are separate filings that need not match. So a single entity can trade under three names on three domains, and a holding company can share a domain with the business it owns.
Both failure modes hurt a referral program:
- A split company. Three brand records for one entity let three colleagues ask the same CEO, and a CEO who already declined under one name gets asked again under another.
- A fused company. A holding company and its operating company stored as one record name the wrong CEO as the decider, and an introduction built from that record identifies the wrong company. The partner agreement's sample says every introduction record must identify the company, its domain, the partner, the opportunity, the method and timestamps, so the identity line has to be right before anything is sent.
One entity, many names: what a company record may hold
The record holds identifiers and nothing about what the company keeps.
| Field | What goes in it | Where it comes from |
|---|---|---|
| Entity key | Legal name, jurisdiction and the registration number where the registry issues one | A public registry entry, or the CEO through the relationship owner |
| Aliases | Brand names, trade names, former names, every web domain and any merged record's old reference | The website, the registry, the CEO |
| Group | The parent's entity key, if there is one | The registry or the CEO |
| Decider | The CEO's name and the date it was confirmed; after an acquisition closes, the acquirer's CEO | The relationship owner |
| Relationship owner | The one colleague who may raise the topic with this company | The operations lead |
| Match status | Same entity, same group, distinct or unresolved, with the date and the reviewer | The review queue |
Copy the identifier, not the filing: a registry printout adds nothing the key does not. The fuller field set for permissions and next steps is in the three-object referral CRM schema, and finding the registered name behind a brand is covered in how to find a company's legal entity name.
The entity-brand matching specification
Normalize first, then compare. The normalized name is lowercase, with punctuation removed, "&" written as "and", a leading "the" dropped and legal-form words such as inc, incorporated, llc, ltd, limited, corp, co, gmbh, sa, bv and plc stripped. Domains lose "www." and everything after the domain itself. Normalization produces candidates, never answers.
| Rule | Two records share | Verdict | What happens |
|---|---|---|---|
| M1 | Registration number and jurisdiction | Same entity | Merge once the relationship owner confirms; the surviving record keeps both histories |
| M2 | Normalized legal name and jurisdiction, with a registration number missing on one side | Probable same entity | Review queue; add the number once found |
| M3 | A domain, primary or alias | Candidate | Review queue; never merged on a domain alone |
| M4 | A brand alias on one record matches a name or alias on the other | Candidate | Review queue |
| M5 | The same parent, but different registration numbers | Same group | Link through the group field and keep both records; there is no reward cap to pool, and the group link decides nothing about credit |
| M6 | Only the CEO's name | Hint | Shown to the reviewer; no verdict on its own |
| M7 | Only a similar spelling | Look-alike | Shown beside any M1 to M5 result; never merged on its own |
Four verdicts, and one word the CRM never uses. Every pair ends as same entity, same group, distinct or unresolved. Keep "duplicate" out of the CRM's vocabulary. Section 3 of SourceX's terms uses that word for something else entirely: a company that already had an application, relationship, lead, account or email correspondence with SourceX, which is not credited to a later partner. A report that says "duplicate" about your own record hygiene will one day be read as a statement about credit. Words like "credited", "ours" and "taken" are banned for the same reason.
Merge, link or leave apart
- Merge only same-entity pairs. The survivor is the record that holds the registration number, or the older record when both do. Move every permission, next step, introduction pointer and suppression flag into it, and keep the absorbed record's reference as an alias so old links still resolve.
- Never erase history in a merge. Introduction dates, permission dates and submission references survive intact. The agreement's sample says a dispute must not erase original evidence, and a merge that overwrites dates does exactly that.
- One voice per company. When two colleagues each owned a record, the operations lead names one relationship owner and the other stands down. If both had already contacted the CEO, record both dates and pause outreach until the named owner has spoken once.
- A no travels with the merge. If either record carried a CEO's decline, the survivor carries it, and nobody asks again under any alias.
- Link groups, do not merge them. A parent and each subsidiary keep separate records and separate deciders, joined by the group field, because each has its own decider. The program has no reward cap to pool across a group, and the USD 50,000 floor on a first qualifying transaction applies once per referred company, which SourceX counts under its terms, not your group field.
- Acquisitions move the decider. Before closing, the target's CEO decides; once the deal closes, the acquirer's CEO decides for it. Re-run matching on the closing date and update the group and decider fields. The consolidator's brand-entity separation map covers groups that own many brands.
Who runs the queue, and the gates it guards
The operations lead owns the review queue and clears each pair within three working days, using a registry entry, the entity named on the company's own site or the CEO's statement passed on by the relationship owner. Matching runs at four moments:
- On creation. Every new record, typed or imported, is matched before anyone may open a next step.
- Before the first ask. No CEO is approached while the company has an unresolved pair.
- Before submission. The introduction names the entity and the domain the CEO confirmed, and lists the brand names the CEO confirmed, so SourceX can compare the company against its own records.
- On news. A rename, acquisition or new brand reopens matching for that record and its group. The rebrand continuity sheet helps when only the name changed.
An unresolved pair after review goes to the relationship owner with one question for the CEO, asked only if raising the topic is already permitted: which entity holds the records, and who decides for it? Sometimes "deduplication" in a client's world means the records themselves, such as alert-deduplication decisions logged by an operations team; that is a data question, covered in the alert deduplication referral brief template, not a CRM one.
A matching run on six records (Illustrative)
Illustrative: placeholder names and invented facts.
| Record | As entered | Rule hit | Reviewer's finding | Verdict |
|---|---|---|---|---|
| 1 | "K Logistics", the brand on the website, domain k-logistics.example | M4 with record 2 | The site's footer names K Transport, Inc. as operator | Same entity, merged into 2 |
| 2 | "K Transport, Inc.", registration number from the state registry | Survivor | Holds the entity key | Same entity, survivor |
| 3 | "K Holdings, LLC", same domain as record 1 | M3 with records 1 and 2 | Registry shows it owns K Transport | Same group, linked |
| 4 | "K Logistics West", a second brand | M4 with record 1 | Operated by K West, LLC, a sister company | Same group, linked; separate record and decider |
| 5 | "Kay Logistic Services", another state | M7 only | Different registration and CEO | Distinct |
| 6 | "K Transport Inc", imported through a sync app with no domain | M2 with record 2 | Same state, same normalized name, number confirmed | Same entity, merged into 2 |
Before the run, records 1 and 6 had different owners, and the colleague holding record 1 was about to ask the CEO. After it, one record, one relationship owner and one decider remain for K Transport, while K Holdings and K West stay visible as one linked group, with no cap to share and nothing in the link that decides credit.
What the rule cannot see
- SourceX's records. Earlier applications, relationships, leads, accounts and email correspondence between SourceX and the company are invisible to you; ask the CEO about earlier contact before submitting, and let SourceX check its own records.
- Other partners. Another firm may have introduced the same company. Only one partner can be credited per company, and SourceX settles overlaps in duplicate review.
- Related-company credit. The terms say nothing about whether a sister company's earlier dealings with SourceX, or another partner's introduction of a related entity, change who is credited. SourceX resolves those cases in duplicate review, and a group link in your CRM predicts nothing about the outcome.
- Messy registries. Not every registry issues a number, and names repeat across jurisdictions; M2 and M7 will raise false candidates, which is why a person decides.
Closing and upkeep. Run a monthly sweep of every open pair and every record touched by news. When a record closes, keep its entity key, aliases, verdicts and any decline flag, so a future record under a forgotten brand name meets the same answer. How long anything else stays is your firm's retention policy; the agreement's return-or-delete clause already excepts records needed for reward accounting and dispute evidence, and the referral CRM never holds copies of company records in the first place. More operations playbooks sit in the guides library, and the pre-submission duplicate-claims checklist is the next step after a clean run.
Next step
Refer a company. No cap on rewards. Default reward on a company's first qualifying transaction: the greater of $50,000 plus 5% and 15% of Actual Supplier Payout, with no cap; further qualifying transactions first agreed within 12 months of the first Closing pay 15%. Eligibility and payment conditions apply, including the USD 100,000 Minimum Transaction, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
Once every open record resolves to one entity and one decider, register your firm as a partner, screen each entity against who qualifies and keep the program terms beside your match statuses, so nothing in the CRM is mistaken for a credit decision.