TL;DR
Serial number tracking is the one thing that makes an asset register worth reading. Asset tags fall off and spreadsheets drift, but the serial is stamped into the device and the manufacturer already knows it. Get the capture right at the point of purchase and most register problems never start. Get it wrong and you spend years reconciling a list nobody trusts.
- The serial is the only identifier the manufacturer, the reseller and the wipe report all share.
- Asset tags are useful for humans and useless as the primary key, because they come off.
- An IMEI is 15 digits: an 8 digit allocation code, a 6 digit serial and a check digit.
- Capture serials from the supplier’s file, not by typing them off a sticker.
- A register drifts through repairs, refurbishment and manual entry, in that order.
- If the serial on the wipe certificate does not match the register, you cannot prove disposal.
Why the serial and not the asset tag
Most registers start with an asset tag, because a sticker with a number on it feels like control. It is a reasonable thing to have. It is a poor thing to build on.
Tags peel off in transit. They get covered by a case. They get replaced when a device goes for repair and comes back with a new chassis. None of that changes the machine, but all of it breaks the link between the machine and the row in your spreadsheet.
Best tools for Device Management
The serial does not have those problems. It is set at manufacture, it is readable from the operating system, and it is the identifier your supplier, your insurer and your disposal vendor already use.
The practical test
Ask one question of any identifier you are considering as the primary key. If the device turned up in a warehouse with no packaging and no stickers, could you still identify it?
A serial passes. An asset tag does not. A purchase order line does not. That is the whole argument.
Keep the asset tags. They are genuinely useful for a human doing a physical count, and they are faster to read across a room. Just store them as a second column rather than the one everything hangs on.
The identifiers you will actually meet
Different device classes carry different identifiers, and a register that treats them all as one text field will eventually mix them up.
| Identifier | Found on | Format | Changes when |
|---|---|---|---|
| Serial number | Every machine | Manufacturer specific, no common standard | Mainboard replacement, sometimes |
| IMEI | Cellular devices | 15 digits, fixed structure | Never, for the life of the module |
| MAC address | Network interfaces | Six byte hexadecimal | Adapter change, and it can be spoofed |
| Asset tag | Whatever you label | Yours to choose | Any time somebody peels it off |
| Purchase order line | Finance records | Yours to choose | Never, but it is not on the device |
The IMEI is the only one with a real standard
An IMEI is 15 decimal digits with a defined structure. The first eight are the Type Allocation Code, which identifies the model. The next six are the unit serial. The last is a check digit calculated from the other fourteen using the Luhn formula.
That structure is set out in 3GPP TS 23.003, the specification that defines the IMEI structure, and the GSMA IMEI database, which allocates Type Allocation Codes is the body that allocates the codes. A variant called the IMEISV adds two software version digits, giving sixteen.
Two things follow for a register. First, you can validate an IMEI before you store it, because the check digit either works or it does not. Second, the format changed in 2003, so a very old device may show a six digit approval code where the eight digit allocation code should be.
Laptop serials have no equivalent standard. Each manufacturer picks its own length and character set. Your register has to accept all of them, which means the validation you can do on an IMEI is simply not available.
The four places a register drifts
Registers do not fail all at once. They drift, and serial number tracking fails in one of four predictable ways.
Manual entry
Somebody reads a serial off a sticker and types it into a form. Characters that look alike get swapped. The ones that cause trouble are zero and the letter O, one and the letter I, and five and S.
The device is now in your register under an identifier that does not exist. You will not find out until somebody searches for the real one.
Repairs that replace the board
On many machines the serial is held on the mainboard. Replace the board and the reported serial can change, while the chassis, the asset tag and the user all stay the same.
Your register now points at a serial the device no longer reports. The repair vendor knows this happened. Nobody told the register.
Refurbishment and redeployment
A returned machine gets wiped, checked and issued to somebody else. If the register treats issue as a new row rather than a new assignment, the same physical device appears twice with different owners.
Count the fleet now and you will over-count. Every redeployment cycle makes it worse.
Disposal with no matching evidence
A batch goes to a disposal vendor. The certificate comes back listing serials. If those serials were captured differently from the ones in your register, the two lists will not reconcile, and you cannot prove which machines were destroyed.
This is the failure that matters most, because it is the one somebody will eventually audit.
Serial number tracking that is right the first time
Disclosure: RemoAsset, named below, is owned by the same people who publish HROpsLab. It is described with its limitations stated, on the same terms as every other supplier. This site takes no vendor money and sells no placements.
Almost every problem above is a capture problem. Fix capture and the reconciliation work mostly disappears.
- Take serials from the supplier’s file. Resellers can provide a serial list for a shipment. That is machine-readable data from the party that packed the boxes, and it beats anything typed on arrival.
- Read from the operating system where you can. A management agent reports the serial the device itself believes, which is the one that will appear on a wipe certificate later.
- Scan, do not type. Most serial labels carry a barcode. A phone camera and a form that accepts a scan removes the character confusion entirely.
- Validate what can be validated. IMEIs have a check digit, so reject one that fails before it reaches the register.
- Record the source of each serial. Knowing whether a row came from a supplier file, an agent or a human is what lets you judge it later.
The last one is the least common and the most useful. When two sources disagree about a device, the one you trust should be a matter of record rather than a matter of argument.
Where a service takes this off you
If devices are bought, configured and shipped by one supplier, the serial can be captured once, at the point it is packed, and carried through issue and return without being retyped. That is what automated asset tracking tied to procurement is for.
Be clear about what that does and does not fix. It removes manual entry at the start, which is the largest single source of bad rows. It does not stop a repair vendor replacing a board, and it does not reconcile a register you already have. Those stay your problem.
Reconciling a register you already distrust
Most teams reading this are not starting clean. They have a list, they know parts of it are wrong, and they do not know which parts.
Do not try to fix everything. Reconcile against the sources you already have, in order of how much you trust them.
Start with the management agent, if you run one. Every device that has checked in recently is reporting its own serial, and that tells you which rows are real.
Then compare against supplier records. A reseller can usually export what it shipped you and when. Rows in your register that match no purchase are either mis-typed or never existed.
Then look at what is left. Devices in the register that no agent has seen and no supplier shipped are the interesting cases. Some are in a drawer. Some went out of the door with a leaver. Some were never real.
What a good reconciliation produces
Not a clean list. A clean list after one pass is a sign the pass was too shallow.
What it should produce is three groups: confirmed, missing and unexplained. Confirmed rows match a live device. Missing rows are real purchases nobody can locate. Unexplained rows match nothing at all and are probably data errors.
The missing group is the one to act on, because each entry is a machine you paid for and cannot use. If a meaningful share of it is with people who have left, the gap is recovery rather than record keeping, and device retrieval from former employees is the thing that closes it.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| No register at all | Under 50 | Spreadsheet or nothing | Cannot answer basic questions | Export serials from the management agent first |
| Register exists, nobody trusts it | 50 to 200 | Manual entry | Rows match no device | Reconcile against agent and supplier records |
| Fleet count keeps rising | Any | Redeployment in use | Duplicate rows per device | Make issue an assignment, not a new row |
| Disposal evidence requested | Any | Certificates on file | Serials will not reconcile | Match on serial before the next batch ships |
| Devices across many countries | Distributed | Multiple suppliers | Capture differs per supplier | Standardise capture at the point of packing |
The register and the disposal evidence have to agree
Everything above is housekeeping until somebody asks you to prove a specific machine was destroyed. Then the register stops being an inventory and becomes evidence.
A disposal or wipe certificate lists serials. If your register holds a different identifier as its primary key, or holds a mis-typed version of the serial, the two documents do not join up. You have a certificate and you have a register, and no way to show they describe the same devices.
Sanitization standards describe what to do to the media rather than how to identify the device. NIST Special Publication 800-88 on media sanitization is the usual reference for the method, and it assumes you can already say which machine you are talking about. That assumption is exactly what a drifting register breaks.
So the test to run before you need it: take ten serials from your last disposal certificate and search the register. If fewer than ten come back with one unambiguous match, fix that now rather than during an audit.
What to keep together
For each disposed device, keep the serial, the date it left, who collected it, the certificate reference and the method stated. Five fields. Stored together, they answer the question in one lookup. Stored apart, they turn a five minute answer into a week of archaeology.
If the chain from collection through wiping to disposal is handled by one supplier, those fields arrive already joined, which is the practical argument for running the collection, wiping and disposal chain as one process rather than three. It does not remove the need for your own register. It removes the need to stitch three vendors’ exports together to prove anything.
For the labelling side of this, which is worth getting right even though tags are not the primary key, see our guide to asset tags for IT equipment.
See how capture at the point of packing works with asset tracking built into procurement, or read our guide to equipment tracking software.
Frequently asked questions
Why use the serial rather than an asset tag as the primary key?
Because the serial survives everything that removes a tag. It is set at manufacture, readable from the operating system, and already used by your supplier, your repair vendor and your disposal vendor. An asset tag is a label somebody stuck on, and it comes off in transit, gets hidden by a case or gets replaced during a repair. Keep tags for physical counting, where they genuinely help, and hang the record on the serial.
How long is an IMEI and what do the digits mean?
Fifteen decimal digits. The first eight are the Type Allocation Code, which identifies the model and is issued through the GSMA. The next six are the unit serial. The fifteenth is a check digit worked out from the other fourteen with the Luhn formula, which means you can validate an IMEI before storing it. A variant called the IMEISV carries two extra software version digits for sixteen in total.
Can a device’s serial number change?
It can. On many machines the serial is held on the mainboard, so a repair that replaces the board can change the serial the device reports while the chassis and the user stay the same. This is one of the quietest ways a register drifts, because nothing visible changes and the repair vendor has no reason to tell your asset system. Ask repair suppliers to report board replacements as a matter of course.
What is the most common cause of a wrong serial in the register?
Somebody typing it off a sticker. Zero and the letter O, one and the letter I, and five and S are the pairs that get swapped, and the result is a row pointing at an identifier that does not exist anywhere. Scanning the barcode instead removes the problem completely, and taking the serial list from the supplier’s own shipment file removes the need to read the sticker at all.
How do I reconcile a register nobody trusts?
Work from the most trustworthy source down. Start with your management agent, because every device that checked in recently is reporting its own serial. Then compare against supplier shipment records. What is left over splits into three groups: rows confirmed by a live device, real purchases nobody can locate, and rows matching nothing at all. Act on the middle group first, because each one is a machine you paid for and cannot use.
Why do disposal certificates fail to match the register?
Usually because the two lists captured the serial differently, or because one of them was typed by hand. The certificate lists what the disposal vendor read off the device; your register lists what somebody entered months or years earlier. When they disagree you hold a certificate and an inventory with no way to prove they describe the same machines. Test it before you need it by searching ten serials from your last certificate.
Does asset tracking software fix serial number tracking on its own?
Not by itself. Software gives you somewhere to put the data and alerts when something looks wrong, but it inherits whatever capture process feeds it. A tool loaded from hand-typed spreadsheets produces a tidier version of the same errors. The capture method decides the quality of the register, and the tool decides how easily you can read it. Fix capture first.
