Four Records, One Human
A rep I worked with once spent twenty minutes convinced a contact had vanished from the CRM. The contact was in there. Four times. Same person, same number, stored as (555) 867-5309, then 555-867-5309, then 5558675309, then +1 555 867 5309. Four records, one human, and zero chance the system would connect them.
Pull a random hundred contacts from your own CRM and you'll find the same thing. Ten digits, a dozen shapes:
Then there's the stuff that doesn't fit a tidy list: leading zeros that Excel quietly ate, extensions bolted on the end (x123, ext. 123, #123), notes typed into the number field ("ask for Jim"), and the occasional stray letter.
Three things cause almost all of it. Manual entry with no validation, so the form accepts whatever a human types. Imports from different sources, where the trade show list, the acquired company's export, and your Shopify customer file each arrive with their own conventions. And copy-paste, which carries the formatting of every email signature and PDF it touches. Nobody did anything wrong here. People write numbers the way they see them on business cards. The mess is the mess.
The difference between this and a misspelled name is that a human can squint at "Jonh" and figure it out. No matching logic recovers from punctuation drift. That's why phone number formatting in a CRM isn't cosmetic. It decides whether your dedupe, your routing, and your counts are real.
- (555) 867-5309
- 555-867-5309
- 555.867.5309
- 555 867 5309
- 5558675309
- 1-555-867-5309
- +1 555 867 5309
- +15558675309
E.164, Explained Without the RFC
There is an international standard for this, and it takes one line to describe. E.164 looks like +15558675309. A plus sign, the country code, then the full national number. No spaces, no hyphens, no parentheses. Fifteen digits maximum.
The value is that it removes guesswork. A number stored as 020 7946 0958 could be London missing its country code, or it could be garbage. 089 636 48018 might be Munich, or a mangled US number. As +442079460958 and +498963648018, both are unambiguous. Your database no longer needs to know the context, because the number carries it.
That buys you three concrete things. SMS and voice providers require E.164, so a campaign sent to 020 7946 0958 fails silently while the same number in E.164 routes fine. Deduplication becomes an exact comparison instead of a judgment call, which is what lets SmartMatch collapse the customer who signed up on your US site and again on your UK one. And validation gets a baseline, because country codes imply predictable lengths and prefixes.
The catch is that nobody types numbers this way. E.164 is unfamiliar and slightly ugly, and asking a customer to lead with +1 adds friction to a form that's already too long. So don't ask. Let people enter numbers however they like, then standardize on save. Human input stays natural, storage stays consistent.
Country Codes, Leading Zeros, and Extensions
The leading zero catches everyone. In the UK, Germany, France, Australia, Japan, and plenty of other places, the 0 at the front is a national trunk prefix. It exists for dialing inside the country and it disappears the moment you add a country code. So 020 7946 0958 becomes +442079460958, not +4402079460958. That single extra zero is the most common conversion error I see, and it breaks message delivery completely. If you want to know whether a past cleanup went wrong, search your CRM for +440, +490, +610, and +330.
The US and Canada have the opposite problem. There's no trunk prefix, so a ten digit number looks finished on its own. It gets stored without the +1, then fails international checks later or gets mistaken for something else. People also type dialing prefixes instead of a plus: 0044 in Europe, 011 in North America. Both are legitimate ways to place a call and neither is E.164, so your rules need to recognize them and swap them for a plus.
Extensions need their own field. E.164 describes numbers on the telephone network, and an extension is a feature of the office phone system sitting behind it. There's nowhere to put it. Strip x123, ext. 123, and #123 out of the number, store them separately, and never discard them. A number that quietly loses its extension is incomplete data that looks clean.
After that come the leftovers. Vanity numbers with letters (1-800-CONTACTS). Short codes and service numbers like 911 or 411 that will never be valid E.164. Doubled country codes from a form that helpfully prepended +1 to a number that already had one. Numbers a digit short because someone transposed while typing. Each needs a rule or a flag, not a shrug.
A Normalization Ruleset You Can Actually Run
Here's the ruleset, in table form. Left side is what lands in your CRM, middle is the rule, right side is what you store.
Order matters more than any individual rule. Keep the original value in its own field first. Lift out the extension. Turn 00 or 011 into a plus. Strip the remaining punctuation and spaces. Decide the country. Drop the trunk zero if that country uses one. Then check the length against what that country code allows. Do the country step too early and you'll add +1 to a Munich landline.
Deciding the country is the one judgment call. If 90% of your contacts are US based, an unqualified ten digit number is almost certainly +1. If you're a UK company, assume +44. For genuinely mixed data, infer from the billing address, the account region, or the signup source, and if none of those exist, flag it. A UK number stored with a US country code isn't messy, it's corrupted, and it will fail every check downstream while looking perfectly formatted.
AutoFormat runs this whole sequence, including the trunk prefix rules for countries that use them, and it keeps the raw input beside the standardized value. What you're left with is the pile of genuine exceptions: too short, too long, unrecognizable prefix, text where digits should be. That pile is usually a fraction of a percent of your records, and it's the only part that needs a person.
- (555) 867-5309 | Strip separators, apply default country | +15558675309
- 0044 20 7946 0958 | Replace the 00 dialing prefix with + | +442079460958
- 020 7946 0958 (UK account) | Add +44, drop the trunk zero | +442079460958
- +1 1 555 867 5309 | Remove the duplicated country code | +15558675309
- 555-867-5309 x1234 | Move the extension to its own field | +15558675309, ext 1234
- 1-800-CONTACTS | Convert letters to digits, keep original for display | +18002668228
- 020 7946 0958 (no country signal anywhere) | Do not guess | Unchanged, flagged for review
- 555-8675 | Too short for any country | Unchanged, flagged for review
- 911, 411, short codes | Mark as non-standard, exclude from routing | Unchanged, labeled
Validation Versus Formatting, and Why the Difference Matters
+15555555555 is flawless E.164. It's also nonsense. Formatting fixes the shape of a number. Validation asks whether the number could exist and whether it belongs to the person in the record. They are separate jobs, and confusing them is how teams end up trusting a clean looking list that can't be reached.
Formatting is deterministic. Same input, same rules, same output, every time. Validation is a set of probability checks: does the length match the country and line type (UK mobiles start +447 and run to a fixed length, German landlines follow different rules than German mobiles), is the area code real, is this a known test prefix like 555 in the US, is it eleven identical digits, is it a short code. LogicGuard flags these as anomalies rather than silently rewriting them, because a suspicious number and an invalid number need different responses.
Standardize first, then validate. Validation rules only work against a consistent format, so running them on raw input produces noise. Once everything is E.164, your quality checks become simple and your Clarity Score actually reflects reachability instead of tidiness.
After any bulk standardization, audit the result before you trust it:
- Every value starts with + followed by digits only. Anything else didn't convert.
- No trunk prefix residue: search +440, +490, +610, +330.
- No doubled country codes: search +1+1, +44+44, and 11 or 4444 immediately after the plus.
- Lengths match by country. US numbers are +1 plus ten digits, no exceptions.
- Extensions that existed before still exist, in the extension field.
- A sample of converted numbers across countries actually receives a test message.
Preventing Regressions at Intake
Cleaning what you have is a one time win. Keeping it clean is where the effort pays back, because a CRM with no intake rules returns to its natural state within a quarter.
At the form level, guide instead of scold. Show a placeholder in your expected local format, auto-format as the user types if your form library allows it, and infer the country from profile, region, or page context so US visitors never have to type +1. Reject only what's genuinely impossible (far too short, far too long), and convert to E.164 on save while keeping the display version for humans reading the record.
For file imports, require a country signal. Either a country column or numbers that already carry a plus. An import with neither forces a guess on every ambiguous row, and guesses are how +1 ends up in front of Australian numbers. When the country column is missing but address or region data exists, SmartFill can populate it before formatting runs, which turns a guess into a lookup.
Then handle the syncs, because that's where regressions actually come from. Every Shopify order, Klaviyo signup, Mailchimp import, HubSpot form, and Salesforce record brings its own conventions. Run AutoFormat on the way in through DataBridge rather than cleaning up monthly, and watch your Clarity Score. If it drifts down, one source is misbehaving and you'll know which.
Fix It Once, Then Stop Thinking About It
The old way to do this was a week of hand written find-and-replace rules that worked beautifully on your US records and quietly wrecked the German ones. You don't need to spend that week.
Connect your CRM or upload the file. AutoFormat resolves every number to E.164, moves extensions to their own field, keeps the original value beside it, and flags the handful it can't read. Review the flags, decide what to do with the fakes and the short codes, then let SmartMatch show you the duplicates that were hiding behind the punctuation the whole time. Most teams find their contact count was inflated and their SMS deliverability was worse than their reports suggested.
Standardize your contact data in one pass. You can run your own list through the [self-serve product demo](https://www.cleansmartlabs.com/demo) and see exactly what changes before anything touches your CRM.
Frequently Asked Questions
Should I store the display format or the E.164 version?
Store both if your system allows it. E.164 is the canonical value for matching, deduplication, and anything programmatic, while the locally formatted version is friendlier for a human reading the record. If you can only keep one, keep E.164, because you can always format it for display but you can't reliably rebuild it from a formatted string.
What happens to numbers that can't be converted?
They get flagged, never deleted or overwritten. Numbers missing digits, carrying unrecognized prefixes, or containing text notes stay exactly as they are and land in a review queue with the original value intact. You then decide whether to correct them, ask the customer, or mark them invalid.
How do I handle a number when I don't know the country?
Use context before you guess: the billing address, the account region, the signup source, or the site the contact came from. If none of those give you an answer, leave the number unconverted and flag it. A UK number stored as +1 will fail every routing and validation check, and it's harder to find later than a number you knowingly left alone.