Clean International Phone Numbers for CRM: 50+ Countries

Quick Answer

CRM imports fail because phone numbers are stored in human-readable local formats instead of the machine-required E.164 standard (+[country code][number]). CRMs validate using strict regex patterns and reject any spaces, dashes, parentheses, trunk prefixes, or missing country codes.

E.164 is the ITU-T international telecommunication standard that ensures every phone number worldwide is unique, machine-readable, and dialable. Your CSV has mixed formats—US: (555) 123-4567, UK: +44 20 7123 4567, Brazil: +55 11 98765-4321—but your CRM expects: +15551234567, +442071234567, +5511987654321.

The fix: Convert all phone numbers to E.164 format (+[country code][number], no spaces/dashes/parentheses), validate against country-specific rules (length, prefix requirements), remove invalid entries, then import. For files under 1,000 contacts, use find/replace patterns per country. For 1,000+ contacts with mixed countries, use automated detection tools.

Why it happens: Data merged from multiple sources (local marketing campaigns, international sales teams, web form submissions with inconsistent validation), CRM exports from different systems (Salesforce uses E.164, HubSpot allows local), manual entry without standardization rules, or copy-paste from business cards/emails with display formatting.

---

FAST FIX (90 Seconds)

If your CRM phone import just failed, try this first:

1. Identify country mix - Spot formats: (555) 123-4567 (US), +44 20 7123 4567 (UK), +55 11 98765-4321 (Brazil)
2. Choose target format - Use E.164 (+15551234567) for maximum CRM compatibility
3. Strip formatting characters - Remove spaces, dashes, parentheses, periods: (555) 123-4567 → 5551234567
4. Add country codes - Prefix with + and country code: 5551234567 → +15551234567
5. Validate length - Check against country rules (US: 11 digits total including +1, UK: 12-13 digits)

If you have 1,000+ contacts or 10+ countries, continue below for automated methods.

---

You're uploading 5,000 new leads to Salesforce. The CSV looks clean—phone numbers in every row, proper column headers, no obvious errors. You click Import.

Import failed: 2,847 records rejected. "Invalid phone number format in row 847, 1,203, 1,556..."

You scroll to row 847. The phone number looks fine: +44 20 7123 4567. Row 1,203 also looks good: (555) 123-4567. Row 1,556: 011 55 11 98765-4321. They're all valid phone numbers... just not in the same format.

You check Salesforce's phone field settings. It expects E.164 format: +[country code][number] with no spaces, dashes, or parentheses. Your CSV has:

• US numbers with area codes in parentheses: (555) 123-4567
• UK numbers with country code and spaces: +44 20 7123 4567
• Brazilian numbers with country code, area code, and dashes: +55 11 98765-4321
• Australian numbers missing country code: 0412 345 678
• German numbers with international prefix: 0049 30 12345678

You try manually cleaning 50 rows in Excel. 4,950 to go. At 30 seconds per number (identify country, look up format rules, reformat), that's 41 hours of work. Your import deadline is tomorrow.

This guide is based on international CRM implementation patterns across Salesforce, HubSpot, Zoho, Pipedrive, and Microsoft Dynamics. Phone number validation failures waste hours of sales ops time across enterprise teams monthly.

Here's how to diagnose and fix them permanently.

---

Table of Contents

• Quick Diagnosis: Identify Your Phone Format Mix
• TL;DR: Standardize International Phones in 5 Steps
• Why International Phone Formats Break CRM Imports
• E.164 Format: The Universal CRM Standard
• The Hidden Cost of Manual Phone Number Cleaning
• Method 1: Find/Replace Pattern Matching
• Method 2: Excel Formula Conversion
• Method 3: Automated Country Detection
• Method 4: Google Sheets Script
• Method 5: Python/JavaScript Bulk Processing
• Country-Specific Phone Format Rules
• Common International Phone Format Patterns
• Handling Missing Country Codes
• Mobile vs Landline Detection
• Duplicate Contact Prevention
• CRM-Specific Import Requirements
• Validation Techniques
• Real-World Example
• What This Won't Do
• Additional Resources
• FAQ

---

Quick Diagnosis: Identify Your Phone Format Mix

Before cleaning anything, run this 2-minute diagnostic on your phone column:

✓ Scan first 50 rows manually: Note unique format patterns (parentheses, spaces, dashes, country codes)
✓ Check for country codes: Do numbers start with +1, +44, +55, or lack codes entirely?
✓ Look for international prefixes: 00, 011 before country codes (need removal)
✓ Identify separators: Spaces, dashes, periods, parentheses (all need stripping)
✓ Count digit length variation: 10 digits (US local), 11 (US with +1), 12-13 (UK), 13 (Brazil)
✓ Spot mobile indicators: Some countries prefix mobile numbers differently (UK: 07xxx, Brazil: 9xxxx)

This diagnostic tells you which cleaning method to use.

---

TL;DR: Standardize International Phones in 5 Steps

If you need working phone numbers in your CRM in under 30 minutes:

1. Export your CSV - Download current contact list with phone column
2. Identify country mix - Note which countries appear (US, UK, Brazil, Germany, etc.)
3. Choose cleaning method - <1,000 single country = find/replace; 1,000+ mixed = automated tool
4. Convert to E.164 - Transform all to +[country code][number] format (no spaces/dashes)
5. Test import - Upload 50 sample rows to CRM, verify acceptance before full import

Skip to Method #3 if you have 1,000+ contacts from 5+ countries.

---

Why International Phone Formats Break CRM Imports

CRM phone validation fails when your file contains mixed international formats because modern CRMs expect standardized E.164 format (+15551234567) to enable global calling, SMS automation, mobile app integration, and duplicate detection. When your CSV has display formats designed for humans—(555) 123-4567, 020 7123 4567, (11) 98765-4321—the CRM's validation engine rejects them because:

1. Ambiguous country detection: Without explicit country codes, 0123456789 could be UK landline, Australian mobile, or invalid. CRMs refuse to guess.

2. Duplicate contact creation: Same person with +1 555 123 4567 (old record) and (555) 123-4567 (new import) creates duplicate because CRM sees different strings, not same phone number.

3. SMS delivery failures: Marketing automation platforms (Twilio, MessageBird, Plivo) require E.164 for international SMS routing. Display formats fail silently—campaign shows "delivered" but messages never arrive.

4. Click-to-call integration breaks: Salesforce/HubSpot mobile apps parse phone numbers for one-tap dialing. Format inconsistency breaks this feature for 40% of your sales team's calls.

5. Reporting accuracy collapses: Analytics showing "80% of leads have phone numbers" is meaningless if half are invalid formats that can't be called.

The technical reason: CRM systems store phone numbers as VARCHAR/TEXT fields with validation regex patterns that enforce E.164 structure. Your import file's (555) 123-4567 hits the regex validator, fails the pattern match (^\+[1-9]\d{1,14}$), and gets rejected. The CRM doesn't "fix" your formats—it rejects anything that doesn't match its rules.

The business impact: A rejected import file means sales can't call new leads, marketing can't SMS campaign participants, and customer success can't reach support tickets. Every hour delayed is revenue lost.

---

E.164 Format: The Universal CRM Standard

E.164 is the international telecommunication standard that defines phone number structure globally. Created by the International Telecommunication Union (ITU-T), E.164 ensures every phone number worldwide is unique, machine-readable, and dialable from any country.

E.164 Structure:

+[Country Code][Subscriber Number]

No spaces. No dashes. No parentheses. No dots. Just digits after the plus sign.

Examples:

• US: +15551234567 (not (555) 123-4567 or +1-555-123-4567)
• UK: +442071234567 (not +44 20 7123 4567 or 020 7123 4567)
• Brazil: +5511987654321 (not +55 11 98765-4321 or (11) 98765-4321)
• Germany: +493012345678 (not +49 30 12345678 or 030 12345678)
• Australia: +61412345678 (not 0412 345 678 or +61 412 345 678)

Why CRMs enforce E.164:

1. Globally unique identifiers: No two people have the same E.164 number (prevents duplicates)
2. Machine parseable: Software can extract country code, identify mobile vs landline, validate length
3. Direct dialability: Any VoIP system can dial E.164 numbers without transformation
4. SMS routing: Carrier APIs (Twilio, MessageBird) require E.164 for international delivery
5. Cross-platform compatibility: Works in Salesforce, HubSpot, Zoho, Pipedrive, Microsoft Dynamics

Length rules by country (including country code):

• US/Canada: 11-12 digits (+1 + 10 digits)
• UK: 12-13 digits (+44 + 10-11 digits)
• Brazil: 13 digits (+55 + 11 digits)
• Germany: 11-13 digits (+49 + 9-11 digits)
• Australia: 11-12 digits (+61 + 9-10 digits)
• India: 12-13 digits (+91 + 10 digits)
• France: 12 digits (+33 + 9 digits)
• Spain: 12 digits (+34 + 9 digits)
• China: 12-13 digits (+86 + 11 digits)
• Japan: 12-13 digits (+81 + 10-11 digits)

Conversion checklist:

1. Remove all formatting characters (spaces, dashes, parentheses, dots)
2. Remove international dialing prefixes (00, 011, +)
3. Remove trunk prefix 0 if present (UK, Australia, many EU countries start local numbers with 0)
4. Add + symbol
5. Add country code
6. Concatenate: +[country code][number without trunk prefix]
7. Validate total length against country rules

---

The Hidden Cost of Manual Phone Number Cleaning

Time calculation for manual cleaning in Excel:

• Identify country per row: 10 seconds (look at format, infer country)
• Look up country code: 5 seconds (Google "Brazil country code")
• Reformat number: 15 seconds (remove spaces/dashes, add +, add country code, verify length)
• Total per row: 30 seconds

For 5,000 contacts:

• 5,000 rows × 30 seconds = 150,000 seconds = 41.6 hours = 5+ workdays
• At $40/hour (avg sales ops salary), that's $1,664 in labor cost

Error rate with manual cleaning:

• Misidentified country (UK 020 number thought to be US): 5-10% of rows
• Incorrect country code added (typed +54 instead of +44): 3-5% of rows
• Missed formatting characters (left one space): 8-12% of rows
• Trunk prefix not removed (left leading 0): 15-20% for UK/EU/Australia

Net accuracy after manual cleaning: 60-75% (25-40% still fail CRM import)

Automated cleaning comparison:

• Processing time: 2-5 minutes for 5,000 contacts
• Cost: $0 (browser-based tools) or $50/month (API services)
• Accuracy: 92-98% for unambiguous formats

ROI calculation:

• Manual: 41.6 hours + 25-40% redo work = 55-60 hours total = $2,200-$2,400
• Automated: 5 minutes + 2-8% manual review (2 hours) = $80
• Savings: $2,120-$2,320 per 5,000-contact import

For recurring monthly imports (sales ops teams upload 2,000-10,000 new leads monthly), automated phone cleaning saves 20-50 hours per month = $800-$2,000 monthly.

---

Method #1: Find/Replace Pattern Matching (Under 1,000 Contacts, Single Country)

Best for: Small imports, one dominant country (95%+ of contacts), predictable format variations

Example scenario: You're importing 800 US contacts from a trade show. Most have formats like (555) 123-4567, 555-123-4567, or 555.123.4567.

Step-by-step:

1. Open CSV in Excel
2. Select phone number column (entire column, not just visible rows)
3. CTRL+H (Find & Replace)
4. Remove parentheses:
   • Find: (
   • Replace: (leave blank)
   • Replace All
5. Remove closing parentheses:
   • Find: )
   • Replace: (leave blank)
   • Replace All
6. Remove dashes:
   • Find: -
   • Replace: (leave blank)
   • Replace All
7. Remove periods:
   • Find: .
   • Replace: (leave blank)
   • Replace All
8. Remove spaces:
   • Find: (single space)
   • Replace: (leave blank)
   • Replace All
9. Add country code:
   • Insert new column
   • Formula: ="+1"&A2 (assuming phone column is A)
   • Drag formula down entire column
   • Copy → Paste Values to convert formulas to text

US-specific example:

Before:

(555) 123-4567
555-123-4567
555.123.4567
5551234567
1-555-123-4567
+1 (555) 123-4567

After find/replace steps:

5551234567
5551234567
5551234567
5551234567
15551234567
15551234567

After adding +1:

+15551234567
+15551234567
+15551234567
+15551234567
+115551234567  ← ERROR (double country code)
+115551234567  ← ERROR (double country code)

Fix double country codes:

• Find: +11
• Replace: +1
• Replace All

Final result (all E.164):

+15551234567
+15551234567
+15551234567
+15551234567
+15551234567
+15551234567

Validation:

• All numbers should be exactly 12 characters (+1 + 10 digits)
• Sort column to group invalid lengths at top/bottom
• Manually review any that aren't 12 characters

Time estimate: 5-10 minutes for 800 contacts

---

Method #2: Excel Formula Conversion (2-3 Countries, Moderate Complexity)

Best for: Mixed country imports where you can identify country per row (separate country column, or country code already present)

Example scenario: You have 2,000 contacts from US, UK, and Canada with a "Country" column.

Setup:

Step 1: Clean formatting (all countries)

Create helper column with formula to strip all non-numeric characters:

=SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(B2," ",""),"-",""),".",""),"(",""),")",""),"+","")

This removes spaces, dashes, periods, parentheses, and plus signs.

Step 2: Remove trunk prefix (UK/CA/EU only)

=IF(AND(A2="UK",LEFT(C2,1)="0"),RIGHT(C2,LEN(C2)-1),C2)

This removes leading 0 if country is UK.

Step 3: Add country code based on country column

=IF(A2="US","+1"&D2,IF(A2="CA","+1"&D2,IF(A2="UK","+44"&D2,D2)))

Step 4: Validate length

Add validation column to flag invalid lengths:

=IF(A2="US",IF(LEN(E2)=12,"Valid","Invalid - should be 12 chars"),IF(A2="UK",IF(AND(LEN(E2)>=12,LEN(E2)<=13),"Valid","Invalid - should be 12-13 chars"),"Check"))

Time estimate: 15-20 minutes setup, 2-5 minutes processing for 2,000 contacts

---

Method #3: Automated Country Detection & Conversion (1,000+ Contacts, Mixed Countries)

Best for: Large imports, mixed international formats, no country column available, recurring workflows

Why automated detection works:

Country codes follow ITU-T E.164 standards with predictable patterns:

• +1: US/Canada (followed by 10 digits)
• +44: UK (followed by 10-11 digits, landlines start with 2/11, mobiles with 7)
• +55: Brazil (followed by 11 digits, mobiles have 9 after area code)
• +49: Germany (followed by 9-11 digits)
• +61: Australia (followed by 9 digits, mobiles start with 4)

Without country codes, tools use heuristics:

• 10 digits: Likely US/Canada (if starts with 2-9)
• 11 digits starting with 1: US/Canada with country code
• 11 digits starting with 0: UK landline or Australian mobile
• 11 digits starting with 7: UK mobile (if 5-digit area code)
• 13 digits starting with 55: Brazil

Automated detection process:

1. Strip all formatting: Remove spaces, dashes, parentheses, dots, plus signs
2. Detect existing country codes: Check if starts with 1-999 (valid ITU country codes)
3. For numbers without codes:
   • Length analysis (10 = US likely, 11 = UK/CA ambiguous, 9 = Australia likely)
   • Prefix analysis (starts with 0 = UK/AU/EU trunk prefix)
   • Default country fallback (if 90% of file is US, assume remaining are US)
4. Validate against country-specific rules:
   • US: Must be 10 digits, area code 200-999, exchange 200-999
   • UK: 10-11 digits, valid area codes (020, 011x, 013x, etc.)
   • Brazil: 11 digits, area code 11-99, mobile starts with 9
5. Flag ambiguous cases: Manual review queue for 2-8% of records

Accuracy rates:

• Unambiguous formats (has country code, correct length): 99.5%
• Single country code, no separators (correct length): 98%
• Missing country code, 10 digits (assume US/CA): 95%
• Ambiguous formats (could be UK or AU): 70% with default country, 90% with manual review

Time estimate: 2-3 minutes for 5,000 contacts + 15-30 minutes manual review of flagged items

Use Data Cleaner for browser-based automated detection and E.164 conversion.

---

Method #4: Google Sheets Script (Recurring Imports, Same Countries)

Best for: Monthly/weekly imports from same sources, same country mix, scripting comfort level

Why Google Sheets: Built-in Apps Script environment, free, shareable across team, version control

One-time setup (15-20 minutes):

Create custom function to clean phone numbers:

function cleanPhoneNumber(phoneNumber, country) {
  if (!phoneNumber) return "";
  
  // Remove all formatting
  let cleaned = phoneNumber.toString().replace(/[\s\-\.\(\)\+]/g, "");
  
  // Remove international prefix (00 or 011)
  cleaned = cleaned.replace(/^(00|011)/, "");
  
  // Country-specific logic
  if (country === "US" || country === "CA") {
    // Remove leading 1 if present
    if (cleaned.startsWith("1") && cleaned.length === 11) {
      cleaned = cleaned.substring(1);
    }
    // Validate 10 digits
    if (cleaned.length === 10) {
      return "+1" + cleaned;
    }
  } else if (country === "UK") {
    // Remove trunk prefix 0
    if (cleaned.startsWith("0")) {
      cleaned = cleaned.substring(1);
    }
    // Remove country code if present
    if (cleaned.startsWith("44")) {
      cleaned = cleaned.substring(2);
    }
    // Validate 10-11 digits
    if (cleaned.length >= 10 && cleaned.length <= 11) {
      return "+44" + cleaned;
    }
  }
  
  return "INVALID: " + phoneNumber;
}

Usage in Google Sheets:

Drag formula down entire column. Script processes instantly.

Time estimate: 15-20 minutes one-time setup, 2 minutes per recurring import

---

Method #5: Python/JavaScript Bulk Processing (10,000+ Contacts, Complex Rules)

Best for: Enterprise imports, complex validation rules, multiple data sources, API integrations

Why Python: Library support (phonenumbers, pandas), batch processing, error handling, logging

Critical: The phonenumbers library is Google's libphonenumber — the same validation engine used by Android, WhatsApp, Twilio, Signal, and other major telecom platforms. This gives you enterprise-grade accuracy (98-99.5%) without building validation logic from scratch.

Install required libraries:

pip install phonenumbers pandas

Python script:

import pandas as pd
import phonenumbers
from phonenumbers import NumberParseException

def clean_phone_number(phone, default_country="US"):
    """Convert phone number to E.164 format"""
    if pd.isna(phone) or phone == "":
        return None
    
    try:
        # Parse with default country
        parsed = phonenumbers.parse(str(phone), default_country)
        
        # Validate
        if phonenumbers.is_valid_number(parsed):
            # Format as E.164
            return phonenumbers.format_number(parsed, phonenumbers.PhoneNumberFormat.E164)
        else:
            return f"INVALID: {phone}"
    except NumberParseException:
        return f"ERROR: {phone}"

# Read CSV
df = pd.read_csv("contacts.csv")

# Clean phone column
df["phone_cleaned"] = df["phone"].apply(lambda x: clean_phone_number(x, "US"))

# Separate valid and invalid
valid = df[~df["phone_cleaned"].str.startswith("INVALID") & ~df["phone_cleaned"].str.startswith("ERROR")]
invalid = df[df["phone_cleaned"].str.startswith("INVALID") | df["phone_cleaned"].str.startswith("ERROR")]

# Save outputs
valid.to_csv("contacts_cleaned.csv", index=False)
invalid.to_csv("contacts_invalid.csv", index=False)

print(f"Valid: {len(valid)}, Invalid: {len(invalid)}")

Advantages over Excel/Sheets:

• Speed: Processes 100,000 rows in 30-60 seconds
• Accuracy: Uses Google's libphonenumber library (industry standard, 98-99.5% accurate)
• Logging: Saves detailed error reports for troubleshooting
• Automation: Can schedule script to run daily/weekly

Time estimate: 30-60 minutes one-time script setup, <1 minute per recurring run

---

Country-Specific Phone Format Rules (50+ Countries)

Below are validation rules for 50+ countries. Use these for manual review or custom scripts.

Key patterns:

• North America (US/CA): Always +1, always 10 digits after country code
• Europe: Usually remove leading 0, variable length (9-11 digits after code)
• Asia-Pacific: Variable rules, some keep 0, some remove, some no trunk prefix
• Latin America: Usually no trunk prefix, mobile often starts with specific digits

---

Common International Phone Format Patterns

Pattern 1: Country Code Variations

Same number, different representations:

+1 555 123 4567
001 555 123 4567
011 555 123 4567
1-555-123-4567
(1) 555-123-4567

All mean: US number +15551234567

Issue: CRMs see 5 different strings, may create 5 duplicate contacts

---

Pattern 2: Trunk Prefix Confusion

020 7123 4567      ← UK local format (trunk prefix 0)
+44 020 7123 4567  ← INVALID (kept trunk prefix after country code)
+44 20 7123 4567   ← Correct (trunk prefix removed)

Issue: Many countries (UK, Australia, most of Europe) use trunk prefix 0 for domestic dialing. This 0 must be removed when adding international country code. Keeping it creates invalid number.

---

Pattern 3: Mobile vs Landline Ambiguity

UK:

020 7123 4567  ← London landline
07123 456789   ← Mobile (both start with 0, different meaning)

Brazil:

11 8765-4321   ← São Paulo landline (8 starts landline)
11 98765-4321  ← São Paulo mobile (9 starts mobile)

Issue: Some CRMs/marketing tools require mobile vs landline designation (SMS can only go to mobiles). Format must preserve this distinction.

---

Handling Missing Country Codes

Scenario: Your CSV has 5,000 phone numbers with no country codes.

Method 1: Default Country Assignment

Use when: 90%+ of contacts from one country

Process:

1. Analyze sample (first 100 rows)
2. If majority follow one country's format (10 digits = US, 11 digits starting with 0 = UK), assume all are that country
3. Apply country code to all
4. Flag outliers (wrong length, invalid prefix) for manual review

---

Method 2: Separate Country Column

Use when: Source system tracks country separately (CRM exports, web forms with country dropdown)

Process:

1. Check if CSV has "Country", "Location", "Region" column
2. Map country names to ISO codes (United States → US, United Kingdom → GB)
3. Apply country-specific rules per row

---

Method 3: Length-Based Heuristics

Length-to-country mapping:

• 10 digits: US/Canada (98% confidence)
• 11 digits starting with 0: UK landline or Australian mobile (70% confidence)
• 11 digits starting with 7: UK mobile (85% confidence)
• 11 digits starting with 1: US with country code (95% confidence)
• 13 digits starting with 55: Brazil with country code (99% confidence)

---

Mobile vs Landline Detection

Why it matters:

• SMS campaigns: Can only send to mobile numbers (landlines ignore or error out)
• Call prioritization: Some sales teams prioritize mobile calls (higher answer rate)
• Compliance: TCPA (US) requires consent for mobile calls/texts, different rules for landlines

Country-specific mobile detection rules:

United States/Canada

• Mobile: All numbers (no distinction in format)
• Note: US/CA don't differentiate mobile vs landline by number format; requires database lookup

United Kingdom

• Mobile: Starts with 07 (after country code: +447)
• Landline: Starts with 01 or 02 (after country code: +441 or +442)

Brazil

• Mobile: 9 after area code (e.g., +5511987654321)
• Landline: 8 or earlier after area code

Germany

• Mobile: Starts with 15, 16, 17 (after removing trunk 0)
• Landline: Other prefixes

Australia

• Mobile: Starts with 4 (after removing trunk 0)
• Landline: Starts with 2, 3, 7, 8

---

Duplicate Contact Prevention After Standardization

Problem: Before standardization, same person appears as 3 separate contacts:

Contact 1: (555) 123-4567
Contact 2: +1 555-123-4567
Contact 3: 555.123.4567

CRM sees 3 different strings → creates 3 duplicate contacts.

After E.164 standardization:

Contact 1: +15551234567
Contact 2: +15551234567
Contact 3: +15551234567

CRM sees same string → can merge or prevent duplicate on import.

Deduplication strategies:

Strategy 1: Pre-Import Deduplication

Before importing to CRM:

1. Standardize all numbers to E.164
2. Sort by phone number
3. Identify duplicates (same E.164 value)
4. Merge logic:
   • Keep most recently updated record
   • Or keep record with most complete data (email, address filled in)
5. Import deduplicated file

Python method:

df = pd.read_csv("contacts_cleaned.csv")

# Remove exact duplicates based on E.164 phone
df_deduped = df.drop_duplicates(subset=["phone_e164"], keep="first")

# Save
df_deduped.to_csv("contacts_deduped.csv", index=False)

print(f"Removed {len(df) - len(df_deduped)} duplicates")

---

Strategy 2: CRM Duplicate Rules on Import

Salesforce:

1. Navigate to Setup → Duplicate Management → Duplicate Rules
2. Create rule: "Phone Exact Match"
3. Matching rule: Phone (exact match)
4. Action on create: Block or Allow with alert

HubSpot:

1. Settings → Data Management → Duplicate Management
2. Set Phone as unique identifier
3. On import, HubSpot will prompt: "Contact with phone +15551234567 already exists. Update or skip?"

---

CRM-Specific Import Requirements

Salesforce

Phone field format: E.164 or local format with parentheses (but E.164 recommended for global instances)

Validation rules: Can be set per field via Setup → Object Manager → Contact → Fields → Phone → Validation Rule

Common requirement: E.164 format with regex validation:

Regex: ^\+[1-9]\d{1,14}$
Error message: "Phone must be in E.164 format: +15551234567"

---

HubSpot

Phone field format: Flexible (accepts local and E.164), but automatically normalizes to E.164 for deduplication

Duplicate detection: HubSpot uses E.164 internally, so (555) 123-4567 and +15551234567 match as same contact

---

Zoho CRM

Phone field format: Accepts local and international, no strict validation (unless custom validation rule added)

Risk: Zoho's lax validation means invalid/inconsistent formats enter CRM, causing issues downstream

Best practice: Enforce E.164 standardization yourself before import

---

Validation Techniques After Conversion

After standardizing to E.164, validate before importing:

Validation 1: Length Check

Every country has min/max length (including + and country code).

Automated check:

def validate_length(e164, country_code):
    length_rules = {
        "+1": (12, 12),      # US/CA
        "+44": (12, 13),     # UK
        "+55": (13, 13),     # Brazil
        "+49": (11, 13),     # Germany
        "+61": (11, 12),     # Australia
    }
    
    min_len, max_len = length_rules.get(country_code, (0, 20))
    return min_len <= len(e164) <= max_len

---

Validation 2: Format Regex

E.164 regex:

^\+[1-9]\d{1,14}$

Breakdown:

• ^ - Start of string
• \+ - Literal plus sign
• [1-9] - First digit 1-9 (no country code starts with 0)
• \d{1,14} - 1 to 14 additional digits (max international length)
• $ - End of string

---

Validation 3: CRM Test Import

Before full import, test with 50-100 rows:

1. Create test CSV with 50 cleaned numbers
2. Import to CRM (Salesforce, HubSpot, etc.)
3. Check:
   • All 50 imported successfully (no rejection errors)
   • Phone numbers display correctly in contact records
   • Click-to-call works from CRM interface
   • No duplicate contacts created

---

Real-World Example: Enterprise Sales Team Multi-Country Import

Context:

GlobalTech Solutions (B2B SaaS company) has 8,500 leads from 15 countries collected over 12 months via trade shows, web forms, partner referrals, and LinkedIn lead gen.

Problems Identified:

1. Mixed formats: US numbers have parentheses, UK has spaces, Brazil missing country code
2. No standardization: 7 different phone format variations across 8,500 rows
3. Duplicate risk: Same person from multiple sources with different phone formats

---

BEFORE vs AFTER

---

Solution: Multi-Step Cleaning Workflow

Phase 1: Automated Bulk Conversion (Day 1)

Used Python script with phonenumbers library processing 8,500 contacts.

Results:

• Valid: 8,127 (95.6%)
• Invalid: 373 (4.4%)

Phase 2: Manual Review (Day 2)

Sales ops team reviewed 373 invalid numbers, corrected 321.

Phase 3: Deduplication (Day 3)

Found 1,247 duplicates (14.8%), deduplicated to 7,201 unique contacts.

Phase 4: Mobile vs Landline Tagging (Day 4)

Results:

• Mobile (confirmed): 3,847 (53.4%)
• Landline (confirmed): 1,209 (16.8%)
• Unknown (US/CA): 2,145 (29.8%)

Phase 5: Full Import (Day 5)

All 7,201 contacts imported successfully to Salesforce.

Business Impact:

• Sales outreach started immediately: 5 days ahead of deadline
• SMS campaign launched: 3,847 confirmed mobile numbers, 17% conversion to demo booking
• Duplicate prevention: Avoided 1,247 duplicate contacts
• Long-term ROI: Script now processes monthly imports in <1 hour

---

What This Won't Do

International phone number standardization solves format compatibility, but it's not a complete telecommunications or CRM data management solution. Here's what this guide doesn't cover:

Not a Replacement For:

• Carrier lookup services - Can't verify if mailbox/line is active, disconnected, or spam
• Phone number validation APIs - No real-time SMTP-style verification or carrier intelligence
• Complete CRM data quality - Doesn't validate emails, addresses, company names, or other contact fields
• SMS compliance management - No opt-in consent tracking, TCPA compliance, or marketing automation
• VoIP/telephony platforms - Not a replacement for Twilio, RingCentral, or calling infrastructure

Technical Limitations:

• US/Canada distinction - Cannot differentiate +1 US vs +1 CA without area code lookup database
• Disconnected numbers - Valid E.164 format doesn't mean line is active
• Mobile vs landline for US/CA - Requires carrier lookup API, not determinable from format alone
• Number portability - Mobile numbers can be ported to landlines and vice versa
• Temporary/virtual numbers - Cannot detect Google Voice, Skype, or burner numbers

Privacy & Security:

• Caller ID spoofing detection - No protection against fraudulent caller ID manipulation
• Do Not Call registry - Doesn't check numbers against DNC lists (separate compliance requirement)
• International dialing permissions - Doesn't verify if your carrier/VoIP allows calls to specific countries

Best Use Cases: This guide excels at preparing international contact CSVs for CRM import by fixing the 7 most common format errors (mixed country codes, missing +, inconsistent separators, trunk prefixes, length mismatches, duplicate formats, invalid characters). For live phone number intelligence, carrier validation, SMS deliverability scoring, or regulatory compliance databases, use dedicated telecommunications APIs after standardizing to E.164 format.

---

Additional Resources

E.164 Standard & Telecommunications:

• ITU-T E.164 Recommendation - Official international phone numbering standard
• Google libphonenumber Library - Industry-standard phone validation (powers Android, WhatsApp, Twilio)
• Twilio Phone Number Formatting Guide - E.164 format requirements for SMS/voice APIs

CRM Phone Validation Documentation:

• Salesforce Phone Field Validation - How to set validation rules
• HubSpot Phone Number Properties - Phone field configuration and formatting

Data Cleaning & Privacy:

• GDPR Compliance for Contact Data - EU regulations for processing phone numbers and contact information
• Web Workers API - Client-side processing for privacy-compliant tools

---

FAQ