What the software actually does
Fixed asset management software is the system of record for the physical things an organisation owns and capitalises: plant and machinery, buildings, vehicles, computers, laboratory instruments, furniture, and everything else that appears on the balance sheet rather than in the stores ledger.
Its job is narrower and harder than it sounds. It has to hold one version of the truth about each asset across a life that may run fifteen years, during which the asset will move between locations, change custodians, be repaired, be revalued, and eventually be sold or scrapped. Every one of those events changes a number that finance has to report and an auditor may test.
A working fixed asset system answers four questions at any moment without anyone preparing a report: what do we own, where is it and who holds it, what is it worth after depreciation, and can we prove all three.
Why asset registers stop being true
Almost every organisation has an asset register. Very few have one that is currently accurate. The failure is rarely dramatic. It is cumulative.
A machine is shifted from one line to another and the transfer is agreed over a phone call. A laptop is reassigned when an employee leaves and nobody updates the custody record. An air conditioning unit is scrapped and the disposal entry is passed six months later, if at all. Individually these are small. Across three years they produce a register that carries assets which no longer exist and misses assets that do.
The gap becomes visible at the worst possible time: during a statutory audit, during an insurance claim after a fire, or during due diligence before a transaction. At that point the organisation is not correcting a record, it is defending one.
Software helps because it changes where the effort sits. Instead of a heroic annual reconciliation, movements go through a workflow at the moment they happen, and verification becomes a scheduled cycle with evidence rather than an annual argument.
The six core functions
Any serious fixed asset system should do six things. If a product is weak on one of them, that weakness will define your experience of it.
1. Maintain a controlled register
One record per asset, holding acquisition details, cost, capitalisation date, class, useful life, location, department, cost centre and custodian. Crucially, the register should carry a field level change history, so any value in it can be traced to the person and the document that produced it.
2. Identify assets physically
Barcode, QR or RFID tagging under your own numbering policy rather than a fixed vendor format. RFID matters in dense environments such as stores and server rooms where scanning each item by line of sight is impractical.
3. Compute depreciation
Depreciation should be computed by the system from the asset class, useful life and method, not entered from a spreadsheet. In India that means the useful life method under Schedule II of the Companies Act 2013, and a parallel written down value working for the Income Tax Act 1961, which uses different rates and a block of assets concept.
4. Support physical verification
Field teams should be able to scan a tag on a mobile device, photograph the asset in place, capture geo coordinates and record its condition, working offline where connectivity is poor. Verification without evidence is an opinion.
5. Reconcile
The physical count, the register and the general ledger should be compared automatically, with every difference raised as a classified exception carrying a reason code, rather than adjusted quietly to make the totals agree.
6. Manage the asset lifecycle
Preventive and corrective maintenance scheduling, warranty and annual maintenance contract expiry tracking, and repair spend recorded against the asset rather than against a general expense head, so total cost of ownership is visible when a replace or repair decision comes up.
How it differs from an ERP asset module
This is the question most evaluations get stuck on, and the answer is usually not either or.
An ERP asset module is an accounting instrument. It holds the capitalised value, runs depreciation, and posts entries to the general ledger. It is built for the finance function and it is generally good at what it does.
What it rarely does well is the physical world. It has no concept of a barcode label printed under your numbering policy, a verification team working offline in a basement, a geo tagged photograph attached to an asset on a specific date, a custodian acknowledging a handover, or a preventive maintenance schedule triggered by a meter reading.
In practice most organisations keep the ERP as the accounting book of record and run a dedicated fixed asset system for the operational and evidentiary layer, with the two exchanging asset masters, capitalisation entries and depreciation postings. The important design decision is that they reconcile continuously rather than once a year.
What Indian organisations need specifically
A globally designed product will often handle the general case and miss the specifics that determine whether your audit goes smoothly.
| Requirement | Why it matters |
|---|---|
| Schedule II useful life depreciation | The Companies Act 2013 moved from prescribed rates to prescribed useful lives, with componentisation and residual value limits. A system built on fixed rate tables will not model this correctly. |
| Parallel Income Tax Act 1961 working | Tax depreciation uses the block of assets concept with written down value, and treats assets put to use for less than half the year differently. It is a separate computation, not a variant of the first. |
| Extra shift depreciation | Manufacturing operations running double or triple shifts depreciate applicable plant faster. This has to be configurable per asset and per period. |
| Physical verification evidence | Statutory auditors and internal auditors expect verification to have happened and to be evidenced. Geo tagged, timestamped photographs make the evidence checkable. |
| Public sector custody records | Departments, zilla parishads and urban local bodies are examined on custody and on departmental accountability, not only on valuation. |
How to evaluate a system
Feature lists are unhelpful because every vendor has the same one. These questions separate products more reliably.
- Can it model our organisation structure? Entity, site, building, department, cost centre and custodian, at the depth your chart of accounts actually uses.
- What happens when a verification finds something unexpected? Ask to see the exception workflow, not the happy path. This is where products differ most.
- Can the mobile application work offline? Test it in a basement, not in the meeting room.
- Show us the depreciation working, not the depreciation number. An auditor will ask for the working. If the system cannot produce it, someone will rebuild it in a spreadsheet, and you are back where you started.
- Who can change what, and is it recorded? Role based access with field level history is what makes the register defensible.
- How does data get in? Migration of an existing register through a validated template with duplicate detection is a real capability, not an afterthought.
Where to start
Start with an honest assessment of the register you have. Most asset programmes fail in the first stage rather than the third, because they begin with a configuration workshop when they should begin with a count.
A practical sequence is: assess the current register and quantify how far it has drifted, agree the asset classes and hierarchy, tag and verify one location as a pilot, correct the register from that verification, then extend. By the time the second location is verified, the organisation knows what its own data problem actually looks like.
MeltX FAM is built for this sequence, and MeltX also puts verification teams on the ground through its asset verification service, because software cannot verify an asset that nobody has looked at.