Phone Validation for CRM Imports: Fix E.164 Format Errors (2026)

Quick Answer

If your phone fields are blank after a CRM import, the row wasn't rejected — the phone was silently dropped. Most CRMs accept the contact record and drop only the phone field when it fails validation. Phone number failures fall into three predictable causes: missing country code, leftover formatting characters (spaces, dashes, parentheses), and wrong digit count for the country.

Why it happens: CRMs validate phone numbers against the ITU-T E.164 standard — a format that requires a country code, no punctuation, and a specific digit count per country. Most source data uses human-readable formatting that violates at least one of these rules.

The fix: Validate every phone number against E.164 structure before import. Detect missing country codes, strip formatting characters, and flag numbers with wrong digit counts — all before the CRM sees the file.

Root cause: Missing country code is one of the most common phone validation failures. US-based teams frequently export numbers without the +1 prefix, which is self-evident domestically but invalid for any CRM performing E.164 validation.

---

If Your Phone Fields Are Blank After Import

Blank phone fields after a "successful" import are one of CRM's most frustrating silent failures. The import summary shows all records imported. The problem only surfaces when a rep opens a record and tries to make a call.

3 causes of blank phone fields — check them in order:

1. MISSING COUNTRY CODE (most commonly seen)
   Your number: 4155550100
   E.164 requires: +14155550100
   → Add +1 for US numbers, +44 for UK, etc.

2. FORMATTING CHARACTERS LEFT IN
   Your number: +1 (415) 555-0100
   E.164 requires: +14155550100
   → Strip all spaces, dashes, dots, parentheses after the +

3. WRONG DIGIT COUNT
   Your number: +1415555010 (9 digits after +1, need 10)
   → Count digits after country code; US needs exactly 10

If any of these match your data, continue to the fix section for that cause.

---

Fast Fix (90 Seconds)

If your CRM is rejecting phone numbers or importing them blank, try this first:

1. Check for country code prefix — Every E.164 number starts with + followed by the country code. US numbers start with +1. International numbers start with their ITU country code. No prefix = validation failure on any strict CRM.
2. Remove all formatting characters — Strip spaces, dashes, dots, parentheses: +1 (415) 555-0100 → +14155550100.
3. Check digit count — US/Canada: 10 digits after +1. UK: 10–11 digits after +44. Count without the + prefix.
4. Run Data Validator — It flags invalid phone formats across your entire column in seconds, in your browser.
5. Reimport only the fixed rows — If the rest of the import succeeded, re-import just the rows with corrected phone numbers using your CRM's update/merge function.

---

TL;DR: Phone validation failures almost always trace to missing country code or leftover formatting characters. E.164 format is +[country code][number], no spaces, no punctuation. Run your CSV through Data Validator to detect every invalid phone format before the CRM rejects them.

---

Your sales team compiled a 12,000-lead import from three sources: a trade show badge scan, a LinkedIn export, and a legacy spreadsheet. The phone column has US numbers in five different formats, a handful of UK numbers, and some entries that are clearly not phone numbers at all. You import the file. The CRM accepts the rows but every phone field is blank.

Most CRMs don't reject the row when a phone number is invalid — they import the row and silently drop the phone field. The import summary says success. You discover the problem when reps start making calls and find empty phone fields.

CRM files with phone numbers almost always contain personal contact information — names paired with phone numbers constitute personal data under GDPR Article 4(1) and are covered by Article 5(1)(c) data minimization obligations. When you use a cloud-based phone validation service to check your list, you're transmitting personal contact details to a remote server before the list has even been cleaned. SplitForge's Data Validator checks phone format patterns entirely in Web Worker threads in your browser — the phone numbers and the names attached to them never leave your machine. Confirm this with Chrome DevTools Network tab during validation.

Each validation pattern in this guide was verified against the ITU-T E.164 standard and tested against Salesforce, HubSpot, and Zoho CRM phone field validation behavior, March 2026. For the complete CRM import failure taxonomy, see our CRM import failures complete guide. For phone format conversion (as distinct from validation), see Clean International Phone Numbers for CRM and Standardize Phone Numbers in CSV Files.

---

What CRM Phone Validation Actually Checks

❌ BROKEN — Phone numbers that fail CRM validation (by failure type):

MISSING COUNTRY CODE:
4155550100           → 10 digits, no + prefix, no country code → rejected
(415) 555-0100       → formatting + no country code → rejected
415-555-0100         → formatting + no country code → rejected

FORMATTING CHARACTERS:
+1 (415) 555-0100    → spaces and parens → may pass or fail depending on CRM
+1-415-555-0100      → dashes → may pass or fail depending on CRM
+1.415.555.0100      → dots → rejected by strict validators

WRONG DIGIT COUNT:
+14155550           → 9 digits after +1; US requires 10 → rejected
+141555501001       → 11 digits after +1; too long → rejected
+4412345            → too few digits for UK → rejected

NON-PHONE VALUES:
"N/A"               → text in phone field → rejected
"555-CALL-NOW"      → letters → rejected
""                  → empty → accepted (blank field, not an error)

FIXED — E.164 format, all US/international numbers:
+14155550100        → US: +1 + 10 digits
+14155550101
+447911123456       → UK: +44 + 10 digits (mobile)
+4920123456         → Germany: +49 + area code + number

---

E.164 Format Reference

ITU-T E.164 is the international standard for telephone numbers, maintained by the International Telecommunication Union. Every number in E.164 format consists of: + (plus sign) + country code + subscriber number. No spaces, no dashes, no parentheses, no extension notation.

E.164 structure by region

The leading zero rule: Many countries use a leading 0 in domestic format (e.g., 07911 123456 for a UK mobile). E.164 drops this leading zero. +447911123456 not +4407911123456.

❌ BROKEN — Common leading zero mistakes:

UK domestic: 07911 123456
Wrong E.164: +4407911123456    → includes the domestic leading 0
Right E.164: +447911123456     → leading 0 dropped after +44

France domestic: 06 12 34 56 78
Wrong E.164: +33 0612345678    → includes the domestic leading 0
Right E.164: +33612345678      → leading 0 dropped after +33

Australia domestic: 0412 345 678
Wrong E.164: +61 0412345678    → includes the domestic leading 0
Right E.164: +61412345678      → leading 0 dropped after +61

---

Table of Contents

• The Four Phone Validation Failure Patterns
• Fix 1: Missing Country Code
• Fix 2: Formatting Characters
• Fix 3: Wrong Digit Count
• Fix 4: CRM-Specific Phone Field Behavior
• Validation vs Formatting
• Common Scenarios
• Additional Resources
• FAQ

---

The Four Phone Validation Failure Patterns

Validation failure decision tree

Phone number in your CSV → Is it valid for CRM import?

Does it start with + ?
  NO → Missing country code → Fix 1
  YES → Continue

Does it contain spaces, dashes, dots, or parentheses after +?
  YES → Formatting characters → Fix 2
  NO → Continue

Is the digit count correct for the country code?
  NO → Wrong digit count → Fix 3
  YES → Continue

Does the CRM's phone field accept E.164, local format, or either?
  → Check Fix 4 for your specific CRM

---

Fix 1: Missing Country Code

Country code is required for E.164 format. For US-based teams, this is the most commonly missed issue — US numbers are self-evident domestically but fail international validation without +1.

The fix for a single-country list is straightforward: prepend the country code to every number that lacks it.

❌ BROKEN — US phone numbers without country code:

4155550100          → needs +1 prefix
(415) 555-0100      → needs +1 prefix and formatting removal
415-555-0100        → needs +1 prefix and formatting removal
555-0100            → 7 digits — missing area code AND country code

FIXED:
+14155550100
+14155550100
+14155550100
[incomplete — cannot fix without area code data]

For multi-country lists, the country code must be inferred or sourced. If your data includes a Country column, map each country to its ITU code and prepend it. If there's no Country column, missing country codes on international numbers cannot be reliably fixed without additional data.

E.164 Phone Examples by Country

Leading zero rule: Most countries use a leading 0 in domestic format (UK 07911, France 06, Australia 0412). E.164 drops this leading 0 — it's replaced by the country code. +447911123456 not +4407911123456.

---

Fix 2: Formatting Characters

Human-readable phone formats use spaces, dashes, dots, and parentheses. E.164 uses none of these. The fix is a bulk strip of all non-numeric characters (except the leading +).

❌ BROKEN — Formatting characters in phone fields:

+1 (415) 555-0100    → spaces and parens present
+1-415-555-0100      → dashes present
+1.415.555.0100      → dots present
+1 415 555 0100      → spaces only
+ 1 415-555-0100     → space after the + sign

FIXED — E.164, no formatting:
+14155550100
+14155550100
+14155550100
+14155550100
+14155550100

In Excel, a formula to strip formatting from a phone in A2 while keeping the + prefix: =SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(A2," ",""),"-",""),"(",""),")",""),".","")"

This removes spaces, dashes, parentheses, and dots. It doesn't add a missing country code — that's a separate step.

How to Fix 10,000 Phone Numbers Fast

For large datasets, manual row-by-row correction isn't an option. Use one of these bulk approaches:

BULK FIX STRATEGY — choose based on your situation:

Situation: All numbers are US, just missing +1
  Excel formula: ="+" & "1" & SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(A2,"(",""),")",""),"-","")
  Result: adds +1 and strips common formatting in one step

Situation: Mixed formats, need to strip characters only
  Find & Replace (Excel/Sheets):
    Find: (    Replace: [blank]
    Find: )    Replace: [blank]
    Find: -    Replace: [blank]
    Find: .    Replace: [blank]
    Find: [space]  Replace: [blank]
  Run each replacement in sequence.

Situation: Multi-country file, need to add country codes
  → Use Data Validator to flag which rows are missing + prefix
  → Use Data Cleaner to prepend country codes from a Country column
  → Both run locally — phone data never leaves your browser

Situation: Unknown format mix, need to identify bad rows
  → Run Data Validator on the phone column
  → It returns a list of rows failing E.164 pattern
  → Fix only the flagged rows; leave valid rows untouched

---

Fix 3: Wrong Digit Count

E.164 numbers have a maximum of 15 digits (including country code). Each country also has a minimum digit count. Numbers outside these ranges are structurally invalid even if they have the correct country code and no formatting characters.

❌ BROKEN — Digit count failures (after removing formatting):

+141555501          → 8 digits after +1; US requires 10 → too short
+14155550100123     → 13 digits after +1; US max is 10 → too long
+447911             → 6 digits after +44; UK mobile requires 10 → too short
+33612              → 5 digits after +33; France requires 9 → too short

These fail validation because the number cannot exist in that country's numbering plan.

FIXED — correct digit counts:
+14155550100        → 10 digits after +1 ✓
+14155550100        → trimmed to correct length (if truncation is appropriate)
+447911123456       → 10 digits after +44 ✓
+33612345678        → 9 digits after +33 ✓

Numbers with wrong digit counts cannot be fixed by reformatting alone — the underlying data is incomplete or corrupt. Flag these for manual review rather than attempting to repair them programmatically.

---

Fix 4: CRM-Specific Phone Field Behavior

Different CRMs have different tolerance levels for phone format variations.

Salesforce is a notable exception — it stores phone numbers as free-text fields and doesn't enforce E.164 on import. Numbers appear exactly as entered. If downstream automation (CTI, SMS workflows) requires E.164, validation must happen before import.

HubSpot enforces E.164 via the API but is more lenient in the browser-based import wizard. For API-based imports (common in migrations), strict E.164 is required.

---

Validation vs Formatting

These are two distinct operations that are often confused:

Validation answers: "Is this number valid — can it exist in the real world?" A validator checks structure (country code present, correct digit count, valid number range) and returns pass/fail per number. It does not change the number.

Formatting answers: "Is this number in the right format for my CRM?" A formatter transforms +1 (415) 555-0100 into +14155550100. It changes the number's representation but doesn't verify whether the number is real.

Validation result: +14155550100 → VALID (US number, correct structure)
Validation result: +14155550   → INVALID (too few digits)
Validation result: +1415555XXXX → INVALID (contains letters)
Validation result: +14155550100 (after formatting) → VALID

Always validate AFTER formatting.
Formatting a structurally invalid number doesn't make it valid.

For CRM imports, the recommended sequence is: format first (strip characters, add country codes), then validate (check digit counts and structure), then import.

---

Common Scenarios

Importing a mixed-country contact list

When your CSV has contacts from multiple countries in the same phone column, validation must happen per-country. A 10-digit number is correct for the US but wrong for a German number. If your data has a Country column, use it to validate digit counts per country code. If not, flag all non-standard-length numbers for manual review.

Phone numbers from legacy CRM exports

Legacy CRM exports often store phone numbers in whatever format the user entered them — a mix of local format, E.164, and completely ad-hoc strings. Run a validation pass to categorize them: numbers with recognizable structure (right length, has country code or obvious area code) can be formatted programmatically; numbers that are clearly wrong (6 digits, letters, completely missing) need manual review.

Extension numbers in the phone column

Extensions (+14155550100 ext. 123 or +14155550100 x123) are not valid E.164. Most CRMs have a separate extension field. Strip the extension from the phone column and populate the extension field separately. The extension notation breaks E.164 validation on every CRM that enforces it.

---

Additional Resources

Technical Standards:

• ITU-T E.164 Recommendation — International public telecommunication numbering plan (the definitive standard)
• Google libphonenumber — The reference library for phone number parsing, formatting, and validation used by most major platforms

Platform Phone Documentation:

• HubSpot — Phone Number Properties — HubSpot phone field format requirements
• Salesforce — Phone Field Best Practices — Salesforce phone field behavior

Privacy & Compliance:

• GDPR Article 4: Definitions — Definition of personal data; phone numbers paired with names are personal data

Tested: Phone number validation patterns verified against ITU-T E.164 specification and tested against Salesforce, HubSpot, Zoho CRM, and Copper CRM phone field behavior, March 2026.

PLATFORM SPECIFICATION SOURCE
Platform: ITU-T E.164 Standard + Multiple CRMs
Source: ITU-T E.164 Recommendation (2010, with amendments)
URL: https://www.itu.int/rec/T-REC-E.164
Verified: March 2026
Next re-verify: Annually (standard is stable; CRM behavior may change)

E.164 structure is defined by the ITU. Country-specific digit counts
are maintained by national numbering plan administrators.

---

FAQ