The record changes when the asset moves
A device can appear in an inventory database and still be difficult to account for. The location may be old. The person responsible for it may have changed. A warehouse receipt may exist without a corresponding update in the financial register. Adding another spreadsheet rarely settles the disagreement; it creates another version that somebody has to reconcile.
An asset record should explain what happened, when it happened, and who accepted the change. Location is one part of that history. Ownership, operational status, and the evidence behind each transition matter too. This article proposes a working method. The examples are fictional and do not describe an employer's systems or results.
Start with a small event model
For a transfer, capture an asset identifier, the previous and proposed location, the sending and receiving custodian, the event time, and a reference to the handover evidence. Keep the person who recorded the event separate from the person who approved it. A timestamp without a named decision owner is a weak audit trail.
Use separate fields for the operational event and the date it was entered. A transfer recorded on Monday may have happened on Friday. Overwriting Friday with Monday makes late reporting look like a new movement. It also makes it harder to reconstruct the asset's position at the close of a reporting period.
A correction should be another event, with a reason and a link to the record it corrects. Do not quietly edit the original movement. An honest correction history is more useful than a clean-looking record that hides how it became clean.
Treat a disagreement as an exception
Consider a fictional radio unit labeled DEMO-104. Operations lists it at Site A, a warehouse receipt places it at Depot B, and the financial register still associates it with Site A. None of those records should automatically win. They answer different questions and may have been updated at different times.
Put the unit in an exception queue. Assign a person to resolve it. Ask for the latest physical evidence, check whether the warehouse receipt identifies the same serial number, and establish whether the movement was accepted. Record the decision and the records that need correction. Keep the financial treatment with the team authorized to decide it.
The queue should distinguish missing evidence from conflicting evidence. A missing receipt requires a different response from two receipts with different serial numbers. Combining both into an undifferentiated data-quality score hides the work needed to resolve them.
Make the handover difficult to misunderstand
A proposed move is not an accepted move. Define the states before implementing the screen: requested, dispatched, received, accepted, or disputed. Decide which state changes the official location and which states merely describe progress. If a receiver rejects the handover, the workflow should preserve the sender's record and explain the dispute.
Test a duplicate request and a delayed response. The same accepted movement must not be applied twice. A receiver who opens an old notification should see the current state rather than accidentally reversing a later decision. These are ordinary workflow problems, but they have consequences when the records support financial or disposal decisions.
Measure whether the exceptions close
A useful review asks how many exceptions have an owner, how long unresolved cases remain open, and whether corrections are supported by evidence. Separate newly discovered issues from issues introduced by the workflow itself. A larger queue after better physical verification may mean the team is finding old problems, not creating new ones.
Before automating reconciliation, take a small, varied sample and trace it manually. Include a transfer, a return, a disputed receipt, and a retired asset. If people cannot agree on what the correct record should say, a faster matching algorithm will only produce faster disagreement. Agree on the decision rule first, then automate the parts that are repeatable.