The Handover Nobody Is Asked to Do
An officer transfers out at the end of the month. Somewhere in the building are a laptop, two tablets, a projector and a set of keys that were signed out to them over four years. Our register can tell you exactly what they hold — the list is one click away on their own record. Nothing in the process of them leaving asks the question, and nothing stops them going.
A handover in a public entity is a formal thing. There is a memo, there is a date, there is an incoming officer and an outgoing one, and somewhere in the file there should be a list of what passed between them. Six months later, when a piece of equipment cannot be found, that list is the only thing standing between an inconvenience and a query. Everybody knows this. It still goes wrong constantly, and the reason is rarely that the register was bad.
It goes wrong because a handover is an event — a moment when somebody has to be asked a question — and most asset registers are built as state: a set of fields describing who currently holds what. State is easy to keep accurate while people remember to update it. The whole difficulty of a handover is that the person with the most reason to update it is the person leaving.
This post is about where our register sits on that line. It is strong on state, and specifically strong in ways that matter for an audit. It does nothing whatsoever at the event.
What the register does well, and it is not a small list
Custody in this product is not a field that gets overwritten. Every change of hands is a movement — a dated row that records what happened and cannot be quietly edited away — and the movement carries considerably more than the new holder's name.
| Recorded on every movement | Why it matters at a handover |
|---|---|
| Custodian before and after | The chain of responsibility is explicit, not inferred from an edit history |
| Department, location and warehouse, before and after | Where the item physically moved, not just who is answerable |
| Condition before and condition after | The state it was handed over in — the single most disputed fact later |
| Who performed it, and when | Attribution on the action itself |
| Who approved it, when — or who rejected it, and why | A second pair of eyes, where policy requires one |
| Latitude and longitude, where policy requires it | Where the person was standing when they recorded it |
| Expected return date | For items going out temporarily rather than transferring |
| Free-text notes and the scan event, if it was scanned | Context, and proof the item was physically present |
Movement approval is configurable rather than all-or-nothing, which is the setting most public entities will want. You can require approval on every movement, on none, or — the default — only on assets that meet a high-risk policy, with a value threshold you set. You can choose which actions the policy covers, and you can mark an individual asset as always requiring approval regardless. GPS capture can be required per action.
And the register does know what each person holds. That is not an inference from a report; it is a defined relationship between an employee and the assets in their custody. It is loaded on the employee's own detail page, it appears as a count against every custodian in the custodian list, and the asset reports will sort custodians by how many assets they are carrying.
The register can answer "what does this officer hold" in one click. Nothing in the process of them leaving asks the question.
Nothing initiates the handover
The product does have an offboarding concept. An employee record has an employment status, and a service exists that treats a terminated employee as offboarded, works out whether they still have a working login, and can revoke it. There is an access audit that lists offboarded employees who can still sign in — a genuinely useful control, and one plenty of organisations lack.
That service is about logins. Searching it for any reference to assets returns nothing. There is no hook on termination that looks at what the person is holding, no checklist that appears, no flag on the employee record, no report of leavers with outstanding custody, and nothing anywhere that treats an unreturned asset as a reason to pause anything.
An officer with eleven assets is marked terminated
The information is complete and correct throughout. Nobody is misled by the data. The failure is that nothing prompts anyone to look at it at the one moment it is decisive.
And when you do it, it is one asset at a time
Suppose the handover does happen properly, because somebody is diligent. An outgoing officer holding forty items hands over to their successor. That is forty separate transfer actions, each recorded individually.
There is no bulk custody transfer — no way to select a custodian, choose a successor, and move everything in one recorded action. Assets can be bulk imported, which is a different thing entirely and often mistaken for this in a demo. For a handover of any size, the correct process is real work, and processes that are real work are the ones that get skipped when somebody is leaving on Friday.
There is no signature
This is the third gap and for a public entity it may be the most important, because it goes to what the record actually proves.
A movement records who performed it and, where policy requires, who approved it. There is no field anywhere for the receiving custodian to acknowledge that they took the item. No signature, no acceptance step, no confirmation. The record is made about the incoming officer rather than by them.
In practice this means a storekeeper can transfer forty assets to a colleague who never touched a screen and may not know it happened. The register will show that colleague as the custodian, dated and attributed, and it will be a perfectly good record of what somebody entered. It is not evidence that the person accepted responsibility, which is precisely what a handover memo is for.
What this means for your file
If your handover procedure requires a signed acknowledgement — and most public procedures do — that document still has to exist outside this system. Our record is a strong, dated, attributed account of what was moved and in what condition. It is not a substitute for the signature, and it should not be described as one in a procedure document.
What to do about all three
None of these gaps requires you to wait for software. They require you to put a person or a form where the software is silent, deliberately, and to write that down.
-
Make custody a named step in the exit procedure
The employee record shows what they hold. Someone has to open it. Put that in the clearance form as a line item with a signature, the same way you would for keys or an identity card.
-
Run the custodian list as a standing report
The custodian list carries an asset count per person. Reviewed monthly against your staff list, it surfaces holders who no longer work there. It is a manual reconciliation, and it takes minutes.
-
Do the transfers before the last day, not after
Forty individual movements is an hour's work with the outgoing officer present. It is a fortnight of chasing once they have gone.
-
Use condition capture properly during the handover
Condition before and after is recorded on every movement and is the field most likely to matter later. A handover done with the item in hand is worth far more than one done from a list.
-
Require approval on the transfers that matter
Set the movement approval policy so that high-value transfers need a second person. That is the closest thing in the product to a countersignature, and it is configurable today.
-
Keep the signed memo
The register does not capture acceptance. Your paper or scanned acknowledgement remains the artefact that proves it, and it should reference the asset codes.
What the register gives you
- A dated, attributed movement for every change of custody
- Condition recorded before and after each hand-over
- Configurable approval — none, all movements, or high-risk only
- Optional GPS capture on the actions you choose
- What any individual currently holds, on their own record
- A count of assets against every custodian, sortable
- Verification as a separate, dated confirmation that an item was seen
What it does not give you
- Any prompt, flag or block when a custodian is terminated
- A report of leavers with outstanding assets
- Bulk transfer of one person's custody to their successor
- A signature or acknowledgement from the receiving custodian
- A handover document generated from the register
- Any link between the exit process and the asset register
Questions worth asking any vendor
Ask to see it happen
- Mark an employee as leaving. Show me every screen that changes.
- Show me the report of people who have left and still hold assets.
- Transfer one person's entire custody to their successor. How many actions is that?
- Where does the incoming custodian confirm they accepted the items?
- Can I produce a handover document from the system, listing what passed and in what condition?
- Who approved the transfer, and can a transfer be made to require approval by value?
The first and fourth questions are the ones that find the boundary fastest. Every register will show you a custodian field. Very few will do anything at the moment that field is about to become wrong, and fewer still will have the receiving person confirm anything at all.
Built and verified in the code
- Movement-based custody. Every change of hands writes a dated row recording custodian, department, location and warehouse before and after, rather than overwriting a field.
- Condition before and after on every movement, which is the fact most often disputed after a handover.
- Configurable movement approval — none, all movements, or high-risk only by default — with a value threshold you set, a per-action policy, and a per-asset flag that always requires approval.
- Approval and rejection recorded, with the approver, the timestamp and the rejection reason.
- Optional GPS capture per action, including on verification.
- What each person holds, as a defined relationship surfaced on the employee record, as a count on every custodian, and as a sortable column in the asset reports.
- Verification as a separate dated action, stamping who confirmed the item exists and when.
- An access audit for leavers, listing offboarded employees who still hold a working login.
Not built — verified absent
- Nothing connects termination to custody. The offboarding service handles logins only; a search of it for any reference to assets returns nothing. No hook, no flag, no task, no block.
- No leavers-with-assets report. The information exists on each employee record; nothing aggregates it.
- No bulk custody transfer. Moving one person's holdings to their successor is one action per asset. The bulk facility on the asset screens is an import, which is a different thing.
- No signature or acknowledgement. A movement records who performed and who approved it. The receiving custodian never confirms receipt, and there is no field for them to.
- No handover document. Nothing in the product generates a list of what passed between two custodians for signing and filing.
- No expected-return enforcement on a leaver. Overdue returns are counted as a general figure; they are not tied to anyone's departure.
Where the line falls
- If you need a defensible record of who held what, when it moved and in what condition, that exists today and it is thorough.
- If you need the system to stop a leaver walking out with equipment, it will not — put that control in your clearance procedure and give it an owner.
- If your procedure requires a signed acknowledgement of receipt, that document stays outside the system for now.
All three gaps are well-shaped work rather than research: an asset check in the offboarding flow, a leavers-with-custody report, a bulk custody transfer between two custodians in one recorded action, and an acknowledgement step the incoming custodian completes themselves. The acknowledgement is the one we would build first, because it is the one that changes what the record proves.
Verified against the repository on 7 August 2026. The absence of any asset check in the offboarding path was established by searching that service and its controller for the word, not by failing to find a feature.
A register that records custody accurately is worth having, and this one does. What it will not do is tap anyone on the shoulder. In a public entity, where handovers are scheduled events with paperwork attached, that is a gap you can close with a line on a clearance form — provided somebody wrote the line, which is the only reason this post exists.
Send us your clearance procedure
If you are specifying an asset register for a public entity, send the handover or clearance procedure it has to support. We will map it step by step against what the register does today and tell you exactly which steps still need a person and a form.
Talk to us about asset custody in the public sector