IMEIAPI.orgTAC Base
Fundamentals

The sixteen-digit one is not a longer IMEI

An IMEISV swaps the check digit for two software-version digits. Store it as an identity and one phone quietly becomes four rows.

The IMEISV replacing the IMEI check digit with two software version digits

Occasionally a device or a network log produces sixteen digits where you expected fifteen. It is not a typo and not a different device. It is an IMEISV — the same identifier with the check digit replaced by a software version number.

What changed and what did not

The Type Allocation Code is the same. The serial portion is the same. What was the check digit is now two digits identifying the software build running on the handset.

So the first fourteen digits still identify the device, exactly as before. Everything appended after them describes its current state, not its identity.

That distinction is the entire practical content of this piece, because it decides how the value should be stored.

The mistake it invites

One phone producing four different rows as its software version changes
Same phone, four rows, and nothing in the data says so.

Store the whole sixteen digits as the device key and the value changes every time the phone updates. One handset accumulates a row per software version, and nothing in the data indicates that they are the same object.

The consequences are quiet and cumulative. Stock counts inflate. A returning customer looks like a new one. Repair history splits across rows so nobody sees the pattern. And a block or a flag placed against one value misses the device under all the others — which is the version of this bug that actually costs something.

Where you will meet it

Mostly in network-side data: operator logs, device management platforms, and diagnostic tools that read what the handset reports during registration. Consumer-facing screens almost always show the fifteen-digit form.

This means it tends to arrive through an integration rather than through a person typing, which is why validation that only checks length can pass it through unnoticed. A field expecting fifteen digits will reject it loudly; a field expecting "an identifier" will store it and cause trouble later.

The robust intake rule is the same as for MEIDs: accept what arrives, work out what it is, normalise to the device portion, and keep the original alongside. Guessing based on length alone is what produces the four-row phone.

Turn an IMEI into a device record.

Brand, model, code name, device type and radio bands, in one call. Tell us what you're building and we'll set you up with a key.