Skip to content

Verifying contact data is accurate before a CRM import

The question people ask once the file is already open: what "accurate" covers here, what this check actually verifies, and what only your CRM can tell you.

The tool itself

CRM Import Check

Drop a CSV or Excel file, pick HubSpot, Salesforce or Pipedrive, and see what the import would reject, cut short or resolve as a duplicate for you.

Check a file

Six more questions

The nine asked before anyone checks anything — what the tool does, which CRMs it supports, whether the file is uploaded, and the rest — are answered on the tool page itself, where they are needed. These come up once you are looking at your own file and wondering what "accurate" actually covers.

How can I verify contact data is accurate before importing it into my CRM?
"Accurate" covers two different things, and this tool only closes one of them. What it checks, against the target you pick: every required field is present (Last Name for a Salesforce contact, an email address or both names for a HubSpot one), every email address and phone number is structurally usable, dates and numbers are typed the way the target expects, no two rows carry the same email or key — which a CRM's own import resolves by keeping one row and dropping the other — and no value is longer than the target's own published field limit. What it cannot check: whether an owner, lead status or other picklist value actually matches one configured in your CRM, whether an email address really receives mail, and whether the person or company named is the real one. A clean verdict means the file will not be rejected, truncated or resolved as a duplicate on the checks above — it is not a claim that every fact in it is true.
Can it check that a picklist or owner value matches my CRM's configuration?
No. Picklist options, lead statuses, owner assignments and links to existing records only exist inside your CRM's own configuration, and this tool never connects to it — it reads the file you are about to hand over and nothing else. A value that looks fine in the file can still be rejected at import because the CRM has no matching option for it; only the CRM itself, or someone who knows its configuration, can check that.
If the verdict says "ready", is the import guaranteed to succeed?
It means every row cleared the checks run against the target you picked — required fields, formats, in-file duplicates, field lengths, column mapping. It is not a guarantee against anything the CRM decides on its own side: a picklist value with no match, an owner who no longer exists, a duplicate against a record already in the CRM rather than another row in your file, or a permission the importing account does not have. Those depend on state inside the CRM that a file check cannot see.
Does the accuracy check work the same way for company records?
Yes, with a different rule set. A company record does not need an email address — HubSpot accepts one with either a domain name or a company name, and Salesforce and Pipedrive have their own equivalent. The formatting, duplicate and field-length checks run the same way, against the company object's own required fields and limits rather than the contact object's.
Does it check that email addresses are real and will not bounce?
No. It checks that an address is structurally valid — the shape a CRM's importer expects — and flags role addresses like info@ or sales@, throwaway domains, and likely typos such as a domain ending in gmial.com. Whether a mailbox actually exists and accepts mail is a question that requires contacting a mail server, and this tool makes no network call carrying your data — verifying deliverability would mean sending every address somewhere.
If I apply every suggested fix, does the file become fully accurate?
It becomes free of the problems this tool can see and is willing to change automatically — trimmed whitespace, a lower-cased email, a stripped invalid character, a cleared placeholder. It does not become verified in the senses above: fixing formatting does not confirm a picklist value, invent a working email address, or decide which of two duplicate rows is the real record. Those stay judgment calls, and the change log shows exactly what was touched so you can make them.

What it looks like on a real file

Three cases where the file looked fine at a glance and was not.

A domain that looks right until you read it twice

Input: ada@gmial.com in the email column, one row among twelve hundred.

Output: one warning naming the row and the suspected correct domain.

Finding: the tool suggests gmail.com and shows both values side by side. Nothing changes unless you tick the fix — a suggestion is not a fact.

A value typed to get past a required field

Input: the Job Title column reads "n/a" for forty rows added the same day.

Output: one warning naming the rows and the repeated value.

Finding: the tool clears the placeholder rather than inventing a real title, and leaves the cell blank for a person to fill in or leave as it is.

Two columns claiming the same field

Input: a file with both a "Company" and a "Company Name" column.

Output: one warning naming both headers and the field they both match.

Finding: the tool proposes one of them and flags the other as unmapped — it does not decide which one is right, because it cannot know which column you trust.

Who is asking this

The question comes from people already holding the file, at four different points in the same job.

Someone running their first import

The first CRM import a company runs sets the shape of the database for years. Getting "accurate" right once, before anything is written, is cheaper than fixing it after.

Whoever owns data quality

Not a title most companies have, but someone always ends up doing the job. This is the check that happens before an import instead of a cleanup project after one.

Consultants onboarding a client

A different client's export every time, and no standing connection to their CRM to lean on. The file is the only thing there is to check.

Whoever is running a CRM migration

An export from the old system was never written with the new one's rules in mind. Checking it against the destination's rules, before the cutover, is the whole point.

Reference

Every HubSpot and Salesforce import error, one page each

The exact error strings HubSpot and Salesforce show, matched to the check that catches each one and what it means.

See every import error

The tool

Check a file now

Drop the CSV you're about to import. Nothing to install, no account, no upload.

Check a file