Phone numbers look simple until formatting, extensions and shared lines collide

A phone field often looks like the easiest column in a business dataset. It contains digits, perhaps punctuation, and sometimes an extension. That appearance invites a familiar cleanup move: remove everything except numbers, standardize the result, and use it to find duplicates.

That works only when the field means one thing. Phone data often carries at least three different kinds of information:

• Formatting tells people how to read or dial a number.
• An extension tells a call where to go after it reaches an organization.
• A shared line describes a contact path that may not identify one person, office, or even one business record.

Treating those as one cleanup problem can make records look tidier while making them less accurate.

Consider three entries:

> (617) 555-0142 > 617.555.0142 ext. 31 > +1 617 555 0142 x31

The punctuation differences are largely presentational. The extension is not. The first entry may be a reception line, while the other two may identify an internal destination behind that line. Before changing values, the useful question is not “Which characters should be removed?” It is “What does each part of this value represent?”

Formatting is not identity

For a confirmed international public number, a normalized form can make comparisons more reliable. The +1 617 555 0142 version, for example, retains the country code and can be compared without visual separators. RFC 3966, the specification for tel: links, treats separators in global numbers as insignificant for comparison.

That does not mean every number-like value is ready for global normalization. International numbering plans vary. A locally written number such as 020 7946 0018 needs country and dialing context before someone can safely add a country code. Guessing can produce a number that looks valid and is wrong.

Keep the source value even after normalizing a confirmed public number. It provides evidence for later review and preserves what the source actually published. It also supports a human-readable display value for websites, reports, and contact lists.

A practical distinction is:

• source_phone_text: exactly what the source supplied
• public_number_normalized: the confirmed public-network number in a consistent comparison form
• display_phone: the version intended for people to read

The North American Numbering Plan has a familiar ten-digit structure, but familiarity should not be mistaken for universality. Nor should an area code be treated as proof of a company’s current physical location. Portability, remote work, and cloud phone systems all weaken that assumption.

An extension is routing context

An extension is not a few extra digits attached to a public telephone number. In conventional business telephony, it identifies a station behind a private system. RFC 3966 represents that distinction with a separate ;ext= parameter in a telephone URI.

That is a useful data-modeling lesson. Store the extension separately.

For example:

This prevents a common matching error. 617-555-0142 ext. 31 and 617-555-0142 ext. 47 may belong to different people or departments. They share a public entry point, but they do not have the same full routing information.

Some source values contain commas, pauses, or other dial instructions as well. Those should not be discarded automatically. They may matter to a caller, even if they do not belong in the normalized public-number field.

A valid number may still be weak identity evidence

The same main line can correctly appear on many records. It may be a switchboard, a department number, a call queue, a shared service, or a common-area phone. Modern business phone systems can also support users without giving each user a dedicated public number.

That makes a normalized main number a useful candidate-linking feature, not a universal unique key.

Suppose five staff records list the same reception number. The number is still useful contact information. But it does not prove the five records are duplicates, belong to one location, or even have individual direct-dial access. To make an identity decision, check corroborating fields such as a name, email address, department, business website, address, profile page, and the authority and date of the source.

A phone_role field helps make this visible. Reasonable values might include direct, main line, department, call queue, shared, or unknown. Use a label only where the evidence supports it. An accurate unknown is better than a confident but invented classification.

Phone data also has a date

A phone number can remain with a customer when that customer changes providers. It can also be disconnected and later assigned to someone else. In the United States, the FCC’s reassigned-numbers framework exists because that later reassignment is a real contact-maintenance issue.

The lesson is broader than outbound calling: a phone value has provenance and a time dimension. Record where it came from and when it was checked. A number published on a current company contact page carries different weight from the same number copied from an old directory.

For matching, an exact normalized public number can start a review. It should not finish one. Compare the extension, organization name, address, website, person or department label, source date, and source authority before merging records.

Clean phone data does not mean every value looks alike. It means the record preserves the details that change how a number should be displayed, dialed, interpreted, and matched.