An asset register stays accurate in proportion to how cheap it is to update, and almost nothing else. Training, policy and annual audits don't fix drift. Making the update a by-product of something staff already do — scanning a label to look an item up — does.
I've now had this conversation about forty times, and it goes the same way every time.
Somebody built a register. It was good. Six months later it's half wrong, and the working theory is that people got sloppy. So there's a reminder email, a brief improvement, and then the same drift by the end of the quarter.
I want to argue that the theory is wrong, because it sends you after the wrong fix.
What register drift actually is
Register drift is the gap between what your register says and what's physically true. You can measure it. Pull fifty records at random, go and look at the things, and count how many are wrong about location, holder or status.
Most people who've never done this are surprised. A register nobody has deliberately maintained for a year is usually still broadly right about what exists — and 30 to 50% wrong about where it's and who has it.
That split is the interesting part. Drift eats the dynamic fields first, and the dynamic fields are the ones anybody actually makes decisions on.
Registers decay at the speed of friction
Here's the whole thesis. A register is accurate in proportion to how cheap it's to update. Not how important it's. Not how well the policy is written. How cheap.
If recording a movement means walking back to the office, opening a spreadsheet and finding a row, that update is competing for the next five minutes of somebody's day against loading a van. It loses. Every time. And nobody ever consciously decided to let it.
That's the part worth sitting with: it isn't a choice people are making badly. The register never enters the comparison at all.
Four places the friction hides
|
Friction |
What it looks like |
What it costs you |
|---|---|---|
|
Requiring a desk |
The update can't be done where the equipment is |
Deferred updates, which become updates that never happen |
|
Requiring a licence |
The person standing there has no access |
Every record made second-hand by somebody who wasn't present |
|
Requiring a decision |
Long forms, optional fields, judgement calls |
Entries abandoned halfway, or filled with placeholder junk |
|
Requiring perfection first |
Nothing works until the whole estate is tagged |
The project stalls before it delivers anything |
Requiring a desk
Anything that can't be finished where the equipment is will get deferred, and deferred means never. This is why offline capability on a phone isn't a nice-to-have for field work. A basement plant room with no signal shouldn't be able to stop a record being made, because it won't get made later.
Requiring a licence
If the person present doesn't have access, somebody else creates the record afterwards from a text message. Per-seat pricing quietly produces this. You ration operators to control cost, and data quality falls in exact proportion. I'd argue it's the single most expensive pricing decision in this category, and it never shows up as a line item.
Requiring a decision
Long forms turn every entry into a series of small judgements. Ask for what, who and when at the moment of the movement. Let somebody with time and context fill in the rest later.
Requiring perfection first
Projects that insist on tagging everything before the system is useful die in month two. Start with what moves and what's expensive. The rest follows once the habit exists — and if it doesn't follow, you've learned something about how much of it mattered.
The fix: make the update a by-product
If updating the register is a task, it competes with other tasks and loses. If it's a side effect of something the person already wanted to do, it happens for free.
Scanning is the clean example. Somebody scans a label because they want to know what this thing is, who's got it, or when it's due back. They get their answer. The scan also writes a dated, located event. Nobody did any admin. The register updated itself because looking something up happened to be the fastest way to find out.
Same with handovers. A signature on a phone at the moment kit changes hands takes about fifteen seconds and actually happens, because it's part of the handover. A form to fill in later is a task. Tasks lose.
*Custody captured as part of the handover rather than as paperwork afterwards.*
What doesn't work
- Training. People already know. Knowledge was never the constraint.
- Policy. A rule that makes the correct action slower produces workarounds, not compliance.
- Annual audits. A count tells you the register drifted. It doesn't stop the drift, and by then the trail's cold.
- Blame. It makes people less willing to report a loss, which kills your only early warning.
- A better spreadsheet. The format was never the problem. The walk back to the desk was.
How to tell whether you've fixed it
|
Metric |
How to measure it |
What good looks like |
|---|---|---|
|
Update latency |
Time your actual operator recording one movement |
Under 15 seconds, done where the equipment is |
|
Record accuracy |
Sample 50 records, physically verify holder and location |
Above 95% on both |
|
Scan recency |
Share of assets scanned in the last 90 days |
Rising. A falling number predicts drift before it shows up |
|
Unattributed items |
Assets with no holder that should have one |
Near zero, and investigated when it isn't |
Why the dynamic fields rot first
It's worth understanding the mechanism, because it tells you what to defend.
Static fields — make, model, serial, purchase price — are written once at acquisition and then left alone. Nothing erodes them. Dynamic fields, the ones that answer where is it and who has it, are wrong the moment reality moves and stay wrong until somebody does something.
So a register's accuracy isn't one number. It's two, and they decay at completely different rates:
|
Field type |
Examples |
Decay rate |
What fixes it |
|---|---|---|---|
|
Static |
Make, model, serial, purchase date, cost |
Essentially zero |
Careful capture at acquisition |
|
Semi-static |
Category, department, depreciation basis |
Slow |
Periodic review |
|
Dynamic |
Location, holder, condition, status |
Fast, continuous |
Frictionless updates at the point of movement |
Most register projects put their effort into the first row, because it's the row you fill in during setup and it feels like progress. The third row is the one every decision depends on, and it's the one nobody budgets for after go-live.
The three failure patterns I see most
The heroic spreadsheet
One person maintains it beautifully. It's genuinely accurate. Then they change role, go on leave, or leave entirely, and within two months it's the worst kind of wrong — wrong but still trusted, because it has a reputation for being right.
The tell is that you can name the person. If your register's accuracy is a property of an individual rather than of a process, you have a single point of failure with a notice period.
The big-bang rollout
Everything gets tagged over a fortnight by a temp. Coverage looks excellent. But nobody changed how movements get recorded, so within a quarter you have a complete register that's uniformly wrong about where everything is, which is arguably less useful than a partial one that's right.
Coverage without a maintenance mechanism is a snapshot, not a system.
The parallel universe
Finance has a fixed asset register. Operations has a spreadsheet. IT has an export from somewhere. All three are partially right and none agree, and every meeting about equipment starts with fifteen minutes of reconciling which list is being discussed.
This one is usually a symptom rather than a cause: the operational fields couldn't be updated in the operational system, so operations built their own.
What to do on Monday
- Measure first. Sample fifty records, physically verify holder and location, and write the number down. You now have a baseline, which is the only way you'll know whether anything you do works.
- Time an update. Watch your actual operator record a movement. Whatever that number is, it's the ceiling on your accuracy.
- Find who can't record. List the people who handle equipment and cross out the ones without access. That gap is where second-hand records come from.
- Fix the slowest step. Usually it's the trip to a desk. Sometimes it's a licence. Occasionally it's a form with eleven fields where three would do.
- Re-measure in a quarter. Same method, fresh sample. If the number hasn't moved, you fixed the wrong thing.
None of that requires buying anything, and the first two will tell you whether you need to.
One test, today
Go and stand next to whoever actually moves your equipment. Time them recording a movement.
Over about fifteen seconds, or it needs them to be somewhere other than where the kit is? Your register will drift no matter who you train. Under fifteen, done on the spot? It'll mostly be right without anyone being asked.
That number is the whole thing. Everything else is downstream of it.
Key takeaways
- Register accuracy is a function of update friction, not staff discipline.
- Any step needing a desk, a licence, a judgement call or a fully tagged estate will get skipped.
- The durable fix is making the update a by-product of a useful action — scanning to look something up.
- Measure update latency in seconds and record accuracy by sampling, quarterly.
- If recording a movement takes more than about fifteen seconds, training won't save the register.
Frequently asked questions
How often should an asset register be updated?
Continuously, as a by-product of normal work, rather than on a schedule. Anything that batches updates into a weekly or monthly exercise guarantees the register is wrong in between — which is most of the time, and usually the moment somebody needs it.
Why do asset registers become inaccurate?
Because updating them costs more effort than skipping them. The cause is nearly always structural: the update needs a desk, a licence, a long form, or all three. Remove those and accuracy improves without anyone changing their behaviour.
Is a spreadsheet good enough for an asset register?
For a small, stable set of items that rarely change hands, yes. It breaks down once equipment moves between people, because a spreadsheet can't record that somebody accepted responsibility, can't be updated from where the kit is, and is stale the moment it's printed.
How do I measure asset register accuracy?
Sample fifty records at random, physically verify holder and location, and express the correct ones as a percentage. Repeat quarterly on fresh samples. Below 95% on holder and location means decisions are running on unreliable data.
Does an annual audit fix register drift?
No. It measures drift after the fact and corrects the record at a point in time, but changes nothing about the process that caused it. Cycle counting through the year works better, because discrepancies surface while they're still recent enough to resolve.