Every asset register is correct on the day it is built. The question is what keeps it correct, and the answer is almost never a person with a spreadsheet.
Somebody builds an asset register. It takes a fortnight, it is thorough, and on the day it is finished it is accurate. Six months later it is wrong in about a quarter of its rows, and twelve months later nobody trusts it enough to use it for anything, which means nobody maintains it, which completes the circle.
This happens to competent people in well-run organisations. The failure is structural: the register depends on humans remembering to update it at exactly the moments when they are busy doing something else.
The rule that fixes most of it
If a field cannot be populated automatically, be very sure you need it.
Modern device management already knows your serial numbers, models, operating system versions, encryption state, last check-in and current signed-in user. It knows these accurately and continuously, with no human involvement. That is the spine of your asset register, and it is free with tooling you probably already own.
Around that spine, add the small number of things no system knows: what it cost, when the warranty expires, and where the money came from. Those are entered once and rarely change.
Everything else, and in particular anything a person would have to remember to update, is a liability dressed as thoroughness.
Physical location is the field that kills more registers than any other. It feels essential. It is accurate for about three weeks in any organisation where people take laptops home, and once one field is visibly wrong, trust in all of them goes.
Where records actually break
Step three, moves
A laptop changes hands. The person leaving hands it to IT or directly to their replacement, it gets reassigned, and nothing updates the record because nothing in the process requires it.
The fix is to make the reassignment happen through the system that already tracks the device. If the signed-in user comes from device management, this solves itself: the record updates when the new person logs in. If reassignment is a form somebody fills in, it will be filled in sometimes.
Step five, retirement
The device is wiped and disposed of, and then stays on the register, keeps consuming a licence, and remains in the identity system as a stale object.
Retirement should be a single checklist that covers all four things at once: wiped with a certificate retained, removed from device management, removed from identity, licence reclaimed. If those are four separate activities owned by different people, three of them will happen.
What the register is actually for
It is worth being clear, because this determines what the register needs to contain.
Budgeting. Warranty expiry and operating system support dates, aggregated, tell you what next year's refresh costs. This is the single highest-value output and the reason finance should care. A register that cannot produce a three-year refresh forecast is not earning its keep.
Security. You cannot patch what you do not know about. The gap between devices in your management tool and devices signing in to your identity provider is a list of unmanaged endpoints, and that comparison is the most useful security report asset data produces.
Licensing. Reclaiming licences from retired devices and departed users is real money, and the savings are usually visible in the first reconciliation.
Incidents. When something happens, "who had this device" and "what was on it" need answering in minutes.
Notice that none of these require a condition rating or a photograph.
Software, which is harder
Hardware is countable. Software licensing is where the money actually leaks, and it is harder because entitlement lives in a dozen vendor portals with different models.
Three practices worth the effort:
Reconcile seats to headcount quarterly. For every per-user subscription, compare licensed seats with active users. The gap is money, in one direction or the other.
Keep entitlement documents in one place. Not in the inbox of whoever bought it. A single folder with the agreements, the seat counts and the renewal dates.
Watch for per-core licensing. Anything licensed per core or per socket on virtualised infrastructure is where audit findings come from, because the entitlement was sized for hardware that has since changed.
Discovery, and what to do with what it finds
Run a discovery scan, or simply compare device management against identity sign-in logs. Both approaches produce the same uncomfortable result: devices nobody expected.
Expect to find machines belonging to people who left, personal devices accessing corporate data, a server somebody forgot, and test equipment set up for a project three years ago. This is normal. The point is not to be alarmed; it is to resolve each one into managed, decommissioned, or deliberately accepted with a named owner.
Do this once properly, then quarterly as a fifteen-minute check. The quarterly version only works because the first one was thorough.
A reasonable implementation
Week one: export everything your device management and identity systems already know. That is your register, and it is already more accurate than most hand-built ones.
Week two: add purchase date, cost and warranty expiry for everything you have records for. Accept gaps for older kit rather than guessing.
Week three: reconcile against identity sign-ins and resolve the differences.
Week four: build the two reports that justify the exercise, being the three-year refresh forecast and the unmanaged device list. Put a recurring calendar entry on the quarterly reconciliation.
Then stop. The temptation at this point is to add fields. Resist it: every field you add is a field that can be wrong, and a register that is ninety percent correct in ten fields is worth far more than one that is sixty percent correct in forty.
