IMEI Tracking 101: Stop Selling Stolen Phones

If your inventory is tracked by SKU and not by IMEI, you don't actually know which physical phones are in your shop. You know how many you should have. That gap is where stolen-phone disputes, warranty fraud, and overnight shrink all live.

What "per-IMEI" actually means

Every smartphone is stamped with a 15-digit IMEI (International Mobile Equipment Identity). It's the device's unique fingerprint — the only piece of inventory data on a handset that a customer can't legally alter. Per-IMEI tracking means each handset is a row in your inventory ledger with a status: in_stock, sold, repair, transferred, returned. That row carries through the unit's entire life in your business.

Compare this to SKU tracking, which says: "We have 12 iPhone 15 Pro 256 GB units." Both models can tell you that twelve units are theoretically present. Only one model can tell you which twelve.

The failure modes SKU tracking can't catch

These are real things that have happened in shops I've worked with:

Stolen phone returned for warranty. A customer returns a unit claiming it's faulty. SKU tracking confirms "yes you bought an iPhone 15 Pro from us 4 months ago." Per-IMEI tracking says "yes, but the IMEI you've returned is 35... and that's not the one we sold you." The customer is trying to launder a stolen device through your warranty.

Inside-job shrink. A cashier sells a phone, voids the sale after the customer leaves with the unit, then walks out at end of shift. SKU tracking shows -1 phone, +1 phone, net zero. Per-IMEI tracking shows the unit IMEI is gone but no sold record exists. The audit trail surfaces this in minutes.

Cross-branch inventory dispute. Branch A claims to have transferred 5 units to Branch B; Branch B confirms 4 received. SKU tracking forces a manual count and an argument about who's right. Per-IMEI tracking shows exactly which 4 IMEIs arrived and which 5th IMEI is unaccounted for — usually still on the dispatch ledger because someone forgot to scan it onto the courier manifest.

Warranty claim with the manufacturer. Apple, Samsung, and Xiaomi all want the IMEI on every claim. If your records can't prove that specific IMEI passed through your shop with a sale receipt, the manufacturer rejects the claim. You eat the cost.

The five events every IMEI must be scanned for

If you're going to track properly, the IMEI gets scanned at every status transition. No exceptions.

1. Stock-in. When the unit physically arrives. Scan from the sealed box label or the device's *#06# screen. Status flips to in_stock. Supplier and PO number are attached automatically.
2. Sale. When it leaves the counter. Cart picks the IMEI, attaches it to the customer record, and the row flips to sold. The sale's published timestamp starts the warranty clock.
3. Transfer. Inter-branch transfers scan IMEIs onto the dispatch ledger and again at the receiving branch. Anything that left A but didn't arrive at B is a transfer-loss case.
4. Repair. When a unit comes in for repair, IMEI scan attaches it to the ticket. When it goes back out, IMEI scan closes the ticket and updates warranty days remaining.
5. Refund. Refund scans the IMEI to flip the row back to in_stock, restores the warranty start date so the next sale doesn't grant a fresh 12-month warranty.

A POS that doesn't enforce IMEI scan at one of these events isn't really doing IMEI tracking — it's doing optional metadata.

Luhn validation matters more than people think

IMEIs have a Luhn check digit. A POS that validates the IMEI as it's typed catches three things:

• Typos (transposed digits, dropped digits) — about 5–8% of manually entered IMEIs are invalid the first time.
• Counterfeit / tampered devices that have a non-Luhn-valid IMEI from the factory.
• Duplicate detection — most TRC databases reject duplicate IMEIs at registration; catching them locally before the registration call is faster than getting an error 30 seconds later.

If your POS accepts any 15-digit string as an IMEI without validation, you have a known-broken intake process. (For an end-to-end system designed around this, see our features.)

Camera vs barcode-scanner

The first instinct of most operators is to buy a USB barcode scanner. In 2026 the cheaper, faster answer is the rear camera on any modern tablet. Camera-based scanning:

• Reads the IMEI barcode on the box and the IMEI sticker on the device.
• Reads the on-screen *#06# IMEI as text via OCR (helpful when boxes are missing).
• Doesn't add another piece of hardware to power, charge, and lose.

The argument for a USB scanner is throughput — a dedicated laser scanner is faster on accessories. For a phone shop where IMEIs are the primary scan target, camera is fine.

Warranty lookup as a customer experience

The single most underrated benefit of per-IMEI tracking is the customer experience when someone walks back in 10 months later. Scan the IMEI once and the cashier has, on screen:

• Sale date and customer
• Original cashier
• Warranty days remaining
• Every repair ticket the unit has touched
• Every prior dispute or note

That conversation goes from "let me find your file, hold on" to "yes I can see your unit, you have 47 days of warranty left and you replaced the battery in March — what's wrong this time?" The customer feels seen. They come back. (More on customer retention: Loyalty Programs.)

Common implementation mistakes

Three patterns I see fail repeatedly:

• Treating IMEI as an optional field. If it's optional, cashiers will skip it during peaks. Make it required at sale; let only an admin override.
• Storing the IMEI in a free-text notes column. Search and aggregation break. The IMEI must live in a typed column with a unique index.
• Not back-filling existing inventory. Migrating from SKU to per-IMEI requires a one-day stocktake where every unit gets scanned. Skipping this leaves a permanent ghost layer in your data.

The audit-trail superpower

Per-IMEI tracking, done right, gives you something most retail businesses don't have: a tamper-evident chain of custody on every unit you've ever touched. Combined with cashier identity and timestamps, that chain is what turns a he-said-she-said into evidence. It's also what makes a future investor or acquirer sleep at night.

Want to see this running in a real POS? Start a 14-day trial and import a sample of 50 IMEIs to see the lifecycle.