Asset Transfer Between Departments — Tracking Movements with Governance
Published: April 14, 2026
A projector was purchased for the Conference Room. Six months later, it is in the Training Department. The asset register still shows it in the Conference Room. The Training Department did not request it formally — someone carried it over because they needed it for a workshop. When the auditor asks about it during physical verification, the Conference Room says "we gave it to Training" and Training says "it was always here." The asset register is wrong, nobody knows when it moved, and there is no documentation of the transfer.
This is the most common way asset registers become unreliable. Assets move between departments, locations, and custodians constantly — but most organisations have no process for recording these movements. The asset stays on the source department's books while physically residing elsewhere. Over time, the asset register drifts from reality.
This article explains how structured asset transfers work when both departments must formally approve the movement — ensuring the register reflects reality and every transfer has an audit trail.
1. Why Informal Transfers Break the Register
Informal transfers — where someone physically moves an asset without updating the register — create cascading problems:
- Depreciation is charged to the wrong department. The source department's budget absorbs the depreciation cost for an asset it no longer uses. The receiving department benefits from the asset without bearing the financial cost.
- Physical verification fails. The verification team checks the Conference Room for the projector, does not find it, and marks it as "not found." It triggers an investigation that ends with "oh, Training has it." Hours wasted.
- Insurance claims are complicated. If the asset is damaged in the Training Department, the insurance claim references the Conference Room (per the register). The insurer may question the discrepancy.
- Custodian accountability is broken. The Conference Room manager is still the registered custodian. If the projector is lost or damaged, accountability falls on someone who has not had it for months.
- Budget planning is distorted. The Conference Room budget includes an asset it does not have. Training's actual asset base is understated — they may request a new projector when they already have one.
2. Dual-Phase Approval — How It Works
A structured asset transfer uses a MOVEMENT requisition that requires approval from both the source and receiving departments. This two-phase process ensures both sides of the transaction are documented and authorised.
Phase 1: Source Department Approval
The requester creates a MOVEMENT requisition specifying:
- Which asset is being transferred (by asset ID)
- Who the destination user is (the person who will receive the asset)
- The destination location (campus, building, floor/room)
- The reason for the transfer
The destination department is automatically derived from the destination user's department — it cannot be set independently. This prevents mismatches where an asset is assigned to a user in one department but the transfer is tagged to a different department.
The requisition is submitted and routed to the source department's approval chain — the same approval matrix used for procurement, but applied to the source department and the asset's classification. The source approvers are being asked: "Do you authorise releasing this asset from your department?"
When all levels of source approval are complete, the requisition moves to a special status: SOURCE_APPROVED.
Phase 2: Receiving Department Approval (Auto-Seeded)
When the source phase completes, the system automatically creates a second approval chain — this time using the receiving department's approval matrix. The receiving approvers are being asked: "Do you authorise accepting this asset into your department?"
This phase is seeded automatically — no manual intervention is needed to start it. The routing uses the destination department but the source asset's classification (because the classification does not change during a transfer — a laptop remains a laptop regardless of which department holds it).
When the receiving phase is fully approved, the transfer is ready for posting.
Posting: What Actually Happens
When the MOVEMENT requisition is posted:
- The source asset is reduced — its quantity is decremented (or the entire asset is marked as transferred if the full quantity moves).
- A new destination asset is created — with the destination user, department, and location. The asset ID is derived from the source:
{source_asset_id}-M{sequence}. - Financial attributes are inherited — original cost, accumulated depreciation, useful life, and depreciation method all carry over from the source.
- The audit trail records everything — who initiated, who approved (both phases), when, and the before/after state of both assets.
The key design decision is that a transfer creates a new asset record with a derived ID rather than simply editing the existing record's department field. This preserves the complete history — the source department's records still show the asset existed and was transferred out, and the destination department's records show when the asset arrived and where it came from.
3. Why Both Phases Matter
Some organisations use a single-approval transfer — the source approves the release and the asset automatically arrives at the destination. This is simpler but creates problems:
| Scenario | Single-Phase | Dual-Phase |
|---|---|---|
| Source pushes unwanted assets to another department | Receiving has no say — assets appear on their books | Receiving can reject — the transfer does not proceed |
| Transfer to a department with different approval limits | Source's approval chain may not match destination's governance requirements | Each department applies its own approval matrix |
| Accountability during transition | Unclear — is the asset the source's or destination's between approval and physical move? | Clear — SOURCE_APPROVED means released but not yet accepted |
Dual-phase approval prevents a common organisational problem: one department dumping assets onto another. Without receiving approval, the receiving department has no mechanism to refuse.
4. The Destination Fields
A MOVEMENT requisition captures specific destination details:
| Field | Required? | How It Works |
|---|---|---|
Destination User (to_user_id) | Required | The person who will be the new custodian |
Destination Department (to_department_id) | Auto-derived | Derived from the destination user's department — cannot be set manually |
| Destination Location (L1/L2/L3) | Optional | Campus, building, floor/room where the asset will reside |
Destination Classification (to_classification) | Optional | Only used if the classification changes during transfer (rare) |
The auto-derivation of department from user is a deliberate governance choice. It prevents a situation where an asset is transferred "to the IT department" but assigned to a user in Finance — which would create a register inconsistency on day one.
5. What Does Not Change During a Transfer
A transfer changes ownership and location. It does not change identity:
- Classification stays the same — a laptop remains IT_EQUIPMENT
- Category hierarchy is preserved — L1/L2/L3 categories carry over
- Item name and description are inherited
- Financial data — original cost, GST, accumulated depreciation, useful life
- Depreciation method and rate — SLM or WDV continues as before
This is consistent with the accounting treatment: an inter-departmental transfer within the same legal entity is not a sale or a new purchase. The asset's financial identity is unchanged; only its custodial assignment moves.
6. Tracking Movement History
Every transfer creates a documented chain. The asset ID encodes the lineage:
- Original procurement:
IT-EQ-2026-0042 - First transfer:
IT-EQ-2026-0042-M001 - Second transfer:
IT-EQ-2026-0042-M001-M001
Anyone looking at the asset ID IT-EQ-2026-0042-M001 can immediately see: this asset was originally IT-EQ-2026-0042 and has been transferred once. The full requisition history — who initiated, who approved both phases, when each step happened, and the destination details — is available in the audit trail.
7. Practical Considerations
7.1 Temporary vs Permanent Transfers
MOVEMENT requisitions in a governed system are designed for permanent transfers — the asset's custody formally changes. For temporary loans ("borrowing the projector for a week"), a lighter process may be appropriate. Some organisations use the self-declaration mechanism for this: the custodian declares the asset as "temporarily relocated" with a remark, and the formal transfer is only initiated if the temporary arrangement becomes permanent.
7.2 Bulk Transfers
When a department relocates (new building, floor change), dozens of assets may need to transfer simultaneously. A MOVEMENT requisition supports multiple lines — each referencing a different asset — so an entire department's assets can be transferred in a single requisition with a single approval flow.
7.3 Transfers and Tally
When the Tally integration is enabled, posting a MOVEMENT requisition enqueues the appropriate Tally accounting entries: a reduction on the source department's cost centre and a corresponding addition on the destination department's cost centre. The Tally vouchers are generated automatically, ensuring the books reflect the transfer without manual journal entries.
8. Frequently Asked Questions
Why does an asset transfer need approval from both departments?
A transfer affects two departments: the source loses an asset and the destination gains one. Without dual approval, transfers can happen informally — assets appear on a department's books without their consent. Dual-phase approval ensures the source formally releases the asset and the receiving department formally accepts it, preventing phantom assets that exist on paper in one department but physically reside in another.
What happens to the asset ID when an asset is transferred?
The source asset is reduced, and a new destination asset record is created with a derived ID in the format {source_asset_id}-M{sequence}. This preserves lineage — anyone looking at the destination asset can trace it back to the original procurement. The destination asset carries new ownership while inheriting the financial history from the source.
How is depreciation handled after a transfer?
The destination asset inherits the financial attributes of the source — original cost, accumulated depreciation, and remaining useful life. Depreciation continues from where it left off. A transfer within the same entity is not a new purchase — the asset's book value, method, and schedule remain unchanged. The depreciation charge simply shifts to the receiving department's cost centre.
Can a transfer be reversed if the receiving department rejects the asset?
Rejection happens during approval, not after posting. If the receiving department's approver rejects during Phase 2, the transfer does not proceed and the source asset remains unchanged. Once posted, reversal requires a new MOVEMENT requisition in the opposite direction — from receiving back to source — going through the same dual-phase approval. Every movement is documented, even reversals.
How do you track all movements of a specific asset over time?
Every transfer creates a MOVEMENT requisition linking source and destination assets. The asset ID chain encodes the lineage — following the -M suffixes traces the complete movement history. The requisition history for each transfer includes who initiated it, who approved both phases, timestamps, and destination details.