How to Verify Contact Data Before Importing It Into Your CRM

A CRM can successfully import a contact record that is completely wrong.

That is not a failure of the import tool.

It is a mismatch of jobs.

A CRM import primarily answers:

Can this file be imported?

If the headers map, the required fields are present, the emails look like emails, and the file encoding is valid, the import can succeed.

That does not answer the question that actually matters:

Should I trust the contacts I am about to import?

Those are different questions.

A file can be perfectly formatted for HubSpot, Salesforce, or another CRM and still contain stale job titles, duplicated people, reused email addresses, placeholder rows, contradictory phone numbers, and company names that no longer match the email domain.

Successful import is not proof of accurate contact data.

This article is about the second question.

If you still need the first — whether the file is technically ready to upload — start with how to clean a CSV before CRM import, then the more specific notes for HubSpot and Salesforce. Those articles cover mapping, identifiers, encoding, and destination-system rules.

What follows is the investigation that happens after the file could import, and before you decide that it should.

Three levels of contact verification

Most pre-import checklists mix these together.

They should not.

1. Format validity

Can the destination system parse the value?

[email protected] looks structurally like an email address.

+1 415 555 0100 looks structurally like a phone number.

Acme Corporation looks like a company name.

The CSV column may also be typed correctly. The header may map cleanly. The CRM may accept the row without error.

That only proves the value is shaped like contact data.

It does not prove the contact is accurate.

2. Data consistency

Do the fields within the record agree with each other?

Consider:

Name	Company	Email
John Smith	Acme Corporation	[email protected]

Each field can be valid on its own.

The record as a whole still deserves investigation.

The email domain does not match the company. That might be a consultant, a parent company, a recent job change, or a stale row. The spreadsheet cannot tell you which. It can only tell you that the pieces do not sit together comfortably.

3. Real-world accuracy

Is the information still true in reality?

Does John still work at Acme?

Does that email still belong to him?

Is the phone number current?

Has the company changed names, merged, or closed?

Is the same person represented twice under different emails?

A CSV cannot definitively prove those facts.

Internal analysis can surface records that look questionable.

External confirmation — a person, a system of record, a company site, an email-verification service, or another authoritative source — is what answers whether the information is still true.

Be honest about that limit. Spreadsheet review and Auditere investigation both operate mainly at levels 1 and 2. They help you decide where to look. They do not magically certify identity, employment, or deliverability.

Why this comes up before a CRM import

The file in front of you is rarely a freshly typed list of people you know.

It is more often:

• an old contact export
• a purchased or acquired database
• several years of accumulated leads
• event registrations mixed with sales prospects
• two CRM exports combined into one spreadsheet
• a billing list joined to a marketing list
• a “master” file that nobody fully trusts

Each of those sources can be formatted well enough to import.

Each can still contain contacts that should not become the next version of truth inside the CRM.

The practical job is to evaluate the contact information itself before you commit it.

12 checks for contact data you are about to trust

These checks are investigation prompts.

A flag is not a verdict.

1. Duplicate contacts

Look for exact duplicates and probable duplicates.

Exact duplicates are the easy case: two identical rows after somebody concatenated exports.

Probable duplicates are harder:

• same email, different name formatting (Priya Shah / P. Shah)
• same person with two email addresses
• same phone number attached to slightly different names
• same company + similar name, different title

Simple “remove duplicate rows” in Excel only catches identical rows.

It will not catch the more common operational problem: two rows that probably represent the same person, with different completeness, different phones, or different titles.

That is why duplicate handling is a judgment problem. You need to decide which version should survive, whether they should be merged, or whether they are actually two people.

If duplicates already live inside the CRM rather than in the pre-import file, start with the CRM’s own tools — and see when Excel, OpenRefine, your CRM, or Auditere is the right tool.

2. One email address attached to multiple people

This is not automatically wrong.

Shared inboxes are real:

• support@
• sales@
• info@
• a family or office address used by more than one person

It becomes a problem when two apparently distinct contacts — different names, different companies, different owners — share a personal-looking mailbox. That can mean an incorrect merge, a copied row, or a reused address after someone left.

Classify it as needs review, not delete.

3. One person represented by multiple conflicting records

Same name and company, but:

• different email
• different phone
• different job title
• different address

The question is no longer “is this a duplicate?”

The question is which record should be trusted.

One row may be historical. One may be the current version. One may belong to a different person with a similar name. Importing both often creates two living contacts. Importing the wrong survivor silently overwrites the better one later.

Do not resolve this by keeping the row that happens to sit first in the file.

4. Missing important contact information

“Missing” depends on the intended CRM workflow.

A newsletter list may only need email.

A sales territory file may need owner, country, and company.

An account-based motion may be useless without a company and a domain.

Common gaps:

• email
• phone
• first or last name
• company
• country
• owner or rep
• lifecycle or status

A blank field can still import.

A blank field can still make the record operationally unusable.

Decide what “complete enough to import” means for this workflow, then treat the rest as incomplete — not as failed syntax.

5. Suspicious or malformed email addresses

Separate two jobs.

Syntactic checks catch values that are not emails: missing @, missing domain, spaces inside the address, obvious typos like [email protected], placeholders such as [email protected], n/a, [email protected], or internal QA domains.

Deliverability is a different question. A well-formed address can bounce. A well-formed address can belong to someone else. A well-formed address can be a catch-all that accepts anything.

Do not treat a regex pass as proof that the mailbox exists or that it belongs to the named person.

If you need mailbox-level verification, that is an external check. Use it on the records that already look questionable, not as a substitute for reading the file.

6. Personal vs business email addresses

gmail.com, outlook.com, yahoo.com, and similar domains are often legitimate.

Founders use them. Consultants use them. Small operators use them. Some regions use them more than corporate domains.

Do not auto-label personal mailboxes as bad data.

Do review them against the purpose of the CRM:

• If the database is supposed to be named-account contacts at work, a personal mailbox may be a signal to confirm employment or to keep the record but mark the channel.
• If the database is a mixed lead list, personal mailboxes may be the correct channel.

The check is: does this email type match what we think this record is for?

7. Company-name inconsistencies

The same organization often appears as:

• Microsoft
• Microsoft Corp.
• Microsoft Corporation
• MICROSOFT
• Microsoft Inc.

Each variant can import cleanly.

Together they fragment reporting, segmentation, and account relationships. Two contacts at the “same” company will not roll up if the company string is not the same string.

This is a consistency problem, not automatically a fact problem. The legal name might genuinely have changed. A subsidiary might be correct. Normalization is a decision.

OpenRefine is often enough for clustering messy company strings on a small file. The investigation question remains: are these the same company, and which form should survive?

8. Email-domain and company mismatches

Example:

Company: Acme
Email domain: competitor.com

This is an investigation signal.

It is not automatically an error.

Possible explanations:

• the person changed jobs and the company field is stale
• the person is a consultant using a client company name
• parent / subsidiary / acquired brand
• a personal domain that happens to look corporate
• an actual copy-paste mistake

Detection tells you to look.

It does not tell you to overwrite the company or delete the row.

9. Conflicting phone, address, or location information

When two records appear to be the same person, inconsistent contact details are the useful part.

One US number and one UK number may mean a relocation, a dual-office setup, or two different people.

One billing address and one shipping address may both be correct.

Two mobile numbers with no shared email is a weaker match than two rows that share an email and disagree on the phone.

Use conflict as a reason to pause. Do not flatten every difference into one “winner” without knowing which field is current.

10. Placeholder, fake, internal, or test records

These survive into production exports more often than people expect:

• Test User
• John Doe / Jane Doe
• [email protected]
• dummy account
• internal QA contacts
• noreply@
• rows clearly created to test an integration

They often have valid-looking structure. They import. Then they pollute reports, sequences, and duplicate-matching rules.

If a record exists only to prove that a pipeline works, it does not belong in the live CRM as a customer.

11. Stale-looking records

Age is not invalidity.

A contact from 2019 can still be the right person. A contact from last week can already be wrong.

What you can look for are indicators that suggest — not prove — external verification:

• the file itself is a very old export
• job title looks frozen next to a company/domain mismatch
• lead source is a program that ended years ago
• last-modified or last-activity timestamps, if present, are empty or extremely old
• the person appears current in one source and historical in another

Do not apply a universal rule such as “contacts older than X months are invalid.”

Use staleness to prioritize review, not to mass-delete.

12. Cross-source disagreement

If the business has more than one list, the same human often appears differently in each:

• CRM export
• newsletter list
• billing system
• sales spreadsheet
• event registration
• support system

Email in the CRM, a different email on the invoice, a personal mailbox on the event list.

Before you pick a surviving record, compare the sources. The “newest file” is not always the most accurate file. Billing may be more current than marketing. The CRM may have an owner and a status the spreadsheet lacks.

Cross-source disagreement is one of the strongest reasons to investigate before import. Once the chosen version is inside the CRM, the other versions become harder to reconcile.

What you cannot verify from a CSV alone

This limit is the point of the article, not a footnote.

Internal data analysis cannot independently prove:

• whether an email inbox currently exists
• whether the person still works at that company
• whether a phone number still belongs to that person
• whether a mailing address is current
• whether a company has closed, merged, or changed legal structure
• whether a job title is still true

Those questions may require:

• direct confirmation from the person or the account owner
• history already in the CRM
• the company website or another public source the team already trusts
• a reputable external data provider, where the business actually uses one
• an email-verification system, where deliverability is the actual question

Keep the two jobs separate:

Detection of questionable records is what you can do in the file.

External verification of real-world facts is what you do for the subset that detection cannot settle.

If you skip that distinction, you either import junk with confidence or you try to “clean” records you cannot actually prove.

A worked example

The table below is synthetic. It is the kind of contact file that imports without drama and still should not be trusted as-is.

The Call column is a first pass only — not a verdict. The notes after the table explain why.

Walk through the interesting rows.

Rows 1–3. Row 1 looks internally consistent. Row 2 is the same row twice. Row 3 shares the email with row 1, so it is probably the same person, but the phone is different and the company string drifted (Ltd vs Limited). Importing all three would create noise. Importing only row 2’s twin still leaves the phone conflict unexamined. Classification: merge/dedupe investigation, not “delete Priya.”

Row 4. Valid name, company, and phone. Missing email. If this CRM motion is email-first, the record is incomplete. If it is a phone-based sales list, it may be usable. The blank is a workflow question.

Row 5. Format-valid. Company is Northstar; mailbox is Helix. That can be a consultant, a job change, or a stale company field. Do not overwrite the company to match the domain without checking. Do not assume the email is wrong because the strings disagree.

Row 6. This should not enter a production CRM as a customer. The structure is fine. The meaning is not.

Row 8–9. Personal email plus “Microsoft” / “Microsoft Corporation” and two different numbers. Possibly one person with a personal mailbox and an updated phone. Possibly two people. The company-name split will also fragment accounts if both import.

Rows 10–11. Same email and phone; company suffix differs. This is the reporting-fragmentation problem. It is not proof that Helix Apps is fake.

Row 12. Dummy data. Easy to miss in a 20,000-row file if you only look at whether the email field contains an @.

Notice what the table does not do.

It does not prove that Priya still works at Northstar.

It does not prove that Jordan’s Helix mailbox still works.

It does not prove that Chris’s Gmail is the right outreach channel.

It tells you where a human — or an investigation workflow — should spend time before the CRM becomes the system of record.

A practical pre-import workflow

Step 1 — Preserve the original data

Never make destructive edits to the only copy.

Keep the source export. Work on a copy. If you later need to explain why a contact was excluded, you will want the untouched file.

Step 2 — Confirm the file can technically be imported

Required fields, headers, formats, encoding, and mapping still matter.

Keep this pass short if you have already done the destination-specific work. Cleaning the CSV and the HubSpot / Salesforce checklists cover that layer.

You are only proving: this file will not bounce off the importer.

Step 3 — Investigate the records themselves

Now look at the contacts:

• duplicates
• missing values that the workflow actually needs
• conflicts inside a row
• conflicts across rows that appear to be the same person
• unlikely combinations
• placeholders and test data
• disagreement with other sources you already have

This is the accuracy pass, not the formatting pass.

Step 4 — Separate “definitely wrong” from “needs verification”

That split keeps you from treating every flag as a deletion.

Potentially deterministic: malformed email, exact duplicate row, obvious test user, n/a in a required identity field.

Investigation signal: domain/company mismatch, personal mailbox on an account list, two phones for one probable person, stale timestamps next to a title that looks outdated.

Signals get a review queue.

They do not all get the same fix.

Step 5 — Verify externally where necessary

Spend confirmation effort on the questionable subset.

Do not try to personally verify every row in a large list. That is how teams skip verification entirely.

Use the owner, the existing CRM history, or an external check only where the file cannot settle the question.

Step 6 — Resolve or quarantine questionable records

Options, depending on the case:

• correct a clear typo
• merge after you choose a survivor
• remove dummy/test rows
• exclude a batch from the first migration
• preserve a review set and import the rest

Quarantine is a valid outcome. It is often better than forcing a guess into the CRM.

Step 7 — Import a controlled sample

Load a small representative batch first: some clean rows, some edge cases you already classified, enough to see mapping, ownership, and duplicate behavior.

There is no universal “import 50 rows” rule. The sample should be large enough to expose the mapping and small enough to reverse.

Step 8 — Inspect the CRM result

Before the full load, check:

• field mapping
• record creation vs update
• unexpected duplicates
• company / contact relationships
• ownership
• values the CRM transformed (dates, country, lifecycle)

If the sample is wrong, the full import will be the same mistake at scale.

Then run the rest when the sample behaves as intended.

This is the same idea as audit before you import: treat the spreadsheet as something that can quietly damage the next system, not as a file that is finished because it opened.

What to use for this work

If the list is small and you can see the problems at a glance, Excel or Google Sheets may be enough for several of these checks: exact duplicates, blanks, obvious test rows, simple filters.

If the messy part is clustering company names, OpenRefine is often the better free tool.

If the duplicates already exist inside HubSpot or Salesforce, use the CRM’s own duplicate tools first.

When the dataset becomes difficult to reason about manually — too many probable duplicates, too many conflicting versions, too many sources, too many review decisions to keep in helper columns — Auditere is aimed at the investigation stage: detecting questionable records, reviewing why they were flagged, resolving issues deliberately, and verifying the resulting dataset before it moves downstream.

Auditere does not independently prove that an inbox exists, that a person still works at a company, or that a phone number still belongs to them.

CRM import tools help answer whether a file can be imported.

Data investigation helps answer whether the records deserve to be trusted.

Those should stay different jobs.

Related reads: How to clean a CSV before CRM import · Prepare a CSV for HubSpot import · Check a CSV before Salesforce import · Clean data before CRM import · Investigate missing and inconsistent data

Auditere is live for beta. Start your free trial or view pricing — if the bottleneck is investigating questionable contacts, not merely formatting the file.