Executive summary
Asset management systems are among the most commonly abandoned enterprise systems. The pattern is consistent: the register is built to satisfy financial reporting, the people who actually know where the assets are gain nothing from maintaining it, and within two years the register and reality have diverged past the point of reconciliation.
This piece covers the modelling and process decisions that determine whether an asset register stays accurate.
The problem
Two populations care about assets for different reasons. Finance needs acquisition cost, depreciation, book value and disposal — a view organised around accounting periods. Operations needs to know what exists, where it is, who has it, and whether it works.
Most systems implement the finance view, because finance sponsors the project. The custodians are then asked to maintain records that give them nothing back. They comply during rollout and stop shortly after, and the annual physical count becomes an exercise in reconciling a register nobody has updated.
Technical discussion
One asset, two views
Model the asset once and derive both views from it. The asset record carries identity, classification, location, custodian and condition; the financial attributes attach to the same record rather than living in a parallel register.
This sounds obvious and is frequently not done, because the finance and operations requirements arrive from different stakeholders at different times and get implemented as separate modules.
Give the custodian a reason to use it
The custodian will maintain the register if it does something for them: produces the accountability form they otherwise prepare by hand, tells them what is due for maintenance, gives them a defensible record when an item goes missing on someone else's watch.
In a Philippine government context, the property custodian's recurring pain is the accountability documentation and the physical count. A system that generates those from the register — rather than requiring separate preparation — earns its maintenance.
Transfers are the hard part
Assets move between custodians, offices and locations, and that movement is where registers go wrong. Model the transfer as a first-class transaction with an acknowledgement step: the receiving custodian confirms receipt, and until they do, accountability stays with the sender.
Without acknowledgement, transfers become one-sided assertions and the register accumulates assets nobody admits holding.
Identification that survives contact with reality
Tags fall off, get painted over, and are illegible on equipment that lives outdoors. Design for re-tagging: the asset's identity is the register record, and the tag is a pointer that can be reissued without changing identity or history.
Barcode or QR tags with a handheld scanner make physical counts dramatically faster, which is the moment the register's accuracy is actually tested.
Depreciation belongs to finance, not to the schema
Depreciation methods change and are prescribed externally. Hold the parameters as configuration and compute on demand rather than storing derived book values as the primary record. When a rule changes, you want to recompute, not migrate.
Architecture
A single asset record with role-appropriate views over it:
Recommendations
- Model the asset once and derive the finance and operations views from the same record.
- Deliver something the custodian needs — accountability forms, count sheets, maintenance due lists — or the register will decay.
- Make transfer a transaction with acknowledgement, so accountability is never ambiguous.
- Separate identity from the tag and design for re-tagging.
- Support scanned physical counts; that is when accuracy is tested.
- Compute depreciation from configurable parameters rather than storing derived values as the record.
- Keep full custodian and location history, not just the current state.
Conclusion
An asset register is only worth what its accuracy is worth. Accuracy comes from the custodian having a reason to keep it current and from movement being modelled honestly — not from a more detailed financial schema.