Take control of your fixed assets in NetSuite. NetAsset automates depreciation, reporting, and compliance for streamlined asset management.
Fixed asset management is one of the last finance processes to leave the spreadsheet, and the reason is that spreadsheets handle it adequately for a long time. A register with a hundred assets, straight line depreciation and a handful of additions each year is genuinely manageable in a workbook.
The difficulty arrives gradually. The register grows, a second depreciation book becomes necessary for tax purposes, disposals and transfers accumulate, construction in progress needs tracking, and the person who built the model moves on. At some point the business is relying on a file that produces numbers nobody can fully explain, and nobody chose that moment.
This article covers what fixed asset management actually requires, why spreadsheets eventually struggle, and what a purpose built application inside NetSuite changes.
The scope is broader than most people assume, which is part of why the spreadsheet grows so many tabs.
The register itself holds every asset with its cost, acquisition date, useful life, residual value, depreciation method, location, and whatever else the business needs for insurance or operational purposes.
Depreciation runs each period against those parameters, and the entries have to post to the right accounts and dimensions. Where the business maintains different values for accounting and tax purposes, that is two calculations rather than one.
Movements have to be handled properly. Additions, disposals with the gain or loss calculated correctly, transfers between locations or entities, and revaluations or impairments where they apply.
And the reporting has to satisfy both management and audit. A roll forward showing opening balance, additions, disposals, depreciation and closing balance, reconciled to the ledger, with the supporting detail available.
The initial calculation is not the problem. The maintenance is.
Multiple books is the first pressure point. Where accounting and tax depreciation differ, the workbook has to maintain parallel calculations for every asset, and the deferred tax consequence has to be derived from the difference.
Part period calculations are the second. An asset acquired mid month, disposed mid year or transferred partway through a period requires proration, and getting the convention consistent across hundreds of assets is harder than it sounds.
Disposals are the third and the most error prone. Removing cost, removing accumulated depreciation, calculating the gain or loss and posting it correctly is four things, and a workbook that handles three of them looks fine until somebody reconciles.
Volume is the fourth. A register with a few hundred assets across several categories, locations and entities becomes a file whose logic nobody wants to modify, which means it stops being improved and starts being worked around.
A distinct issue that affects models that were correct when they were built.
Spreadsheets get edited. A row inserted without a formula extending. A cell overwritten with a hardcoded figure to make something reconcile. A tab copied for a new asset class where a reference still points at the old one.
None of those produce an error. They produce numbers, and the numbers look plausible, and the depreciation charge in the profit and loss is not the sort of figure anybody scrutinises closely.
The risk grows with the number of people who have maintained the file and with the years it has run. A register maintained across five years by three successive people is genuinely difficult to have confidence in, however careful each of them was.
This is also where key person risk concentrates. Where the person who built the logic has left, the business depends on a model nobody can fully explain, which is an uncomfortable position at audit and a worse one if a material error is found.
Netgain's NetAsset is one of the applications built to run inside NetSuite rather than alongside it, and the architectural point matters as much as the functionality.
Because it sits on the platform, the asset register lives in the same database as everything else. Depreciation entries post directly rather than being prepared, exported and journalled. There is no integration to maintain and no reconciliation between an asset system and the ledger.
Practically, that means the schedules are maintained by the application rather than by a person, the period entries post as part of the close rather than as a manual step, and the roll forward reporting is available as reporting rather than as an assembly exercise.
It also means assets carry the same dimensions as everything else, so the depreciation charge lands against the right department, location or subsidiary automatically rather than being allocated afterwards.
What it does not remove is judgement. Useful lives, residual values, depreciation methods and impairment assessments remain accounting decisions somebody has to make and document.
For businesses maintaining different accounting and tax values, this is usually the capability that justifies the change.
The same asset can carry different useful lives, different methods and different residual values across books, calculated independently and reported separately, without anybody maintaining two versions of the register.
That removes an entire category of error, since parallel spreadsheets diverge. An asset added to one book and not the other, a life changed in one place, a disposal recorded once rather than twice. Each is easy to do and difficult to detect.
It also makes the deferred tax calculation straightforward, because the difference between the books is derivable rather than requiring somebody to reconstruct it.
For businesses that have been maintaining tax depreciation in a separate workbook prepared annually by their accountant, bringing it into the same system usually improves both accuracy and the year end timetable.
These are the movements where spreadsheet registers most often go wrong, and where an application removes the arithmetic risk entirely.
A disposal requires the cost and accumulated depreciation to be removed, the proceeds recorded, the gain or loss calculated and posted, and depreciation to stop from the correct date. Where the application handles it, entering the disposal date and proceeds produces all of that.
Transfers between locations, departments or subsidiaries need the asset moved with its accumulated depreciation intact, and for intercompany transfers the accounting is more involved again.
Part disposals, where only some units of a grouped asset are sold, are particularly awkward manually and straightforward in a system that tracks quantity.
The wider point is that these movements are individually infrequent and collectively constant, which is exactly the profile of work that people do occasionally and therefore do inconsistently.
For businesses building or fitting out assets, this is a specific area where spreadsheets manage poorly.
Costs accumulate against a project over months, from multiple suppliers, sometimes across categories, and none of it should be depreciating while it is still in progress.
At completion, the accumulated cost has to be capitalised into one or more assets with the correct commencement date for depreciation, and any costs that should not have been capitalised have to be identified and expensed.
Where this is tracked in the system, costs post against the project as they are incurred and the capitalisation is a defined step. Where it is tracked manually, the accumulation lives in a spreadsheet and the capitalisation is a reconstruction.
Businesses with regular capital programmes tend to find this the most immediately useful capability, because it is the area where manual tracking is both most effortful and most likely to miss something.
Fixed assets contribute to the month end close in a way that is small individually and reliable as a dependency.
In a manual arrangement, somebody calculates depreciation, prepares the journal, posts it, and reconciles the register to the ledger. That is a step in the close with a person attached, and it cannot start until additions and disposals for the period are recorded.
Where the application posts the entries, that step disappears. Depreciation runs, the entries post with the right accounts and dimensions, and the reconciliation between register and ledger is not required because they are the same records.
For a business trying to compress its close, removing a dependency with a person attached is worth more than the hours suggest, because it removes variance rather than only effort. Our piece on mastering the financial period close covers where this sits among the other close improvements.
Fixed assets are a standard audit area, and how the register is maintained affects how the testing goes.
Auditors will select assets and test cost, life, depreciation calculation and existence. Where the register is system maintained with the supporting transactions traceable, that testing is straightforward.
Where it is a spreadsheet, the auditor is testing a model as well as the numbers, which generates more questions and takes longer. Any hardcoded value or broken formula found in the process expands the testing further.
The roll forward is the other point of contact. A system produced roll forward that reconciles to the ledger by construction is different from one assembled at year end and reconciled by adjustment.
None of this is a reason on its own for a business with fifty assets and no audit requirement. For an audited business with a substantial register, it is a recurring saving.
Being honest about the threshold matters, because a purpose built application is not justified everywhere.
Where you have a small register, one depreciation book, straight line depreciation and few movements, a well built spreadsheet maintained by somebody competent is entirely adequate.
The case strengthens with register size, with the need for multiple books, with the frequency of additions, disposals and transfers, with construction in progress activity, and with multi entity or multi currency complexity.
It also strengthens where the current model is understood by only one person, because that is a risk that grows quietly and materialises at an inconvenient moment.
And it strengthens where an audit has raised questions, since the cost of remediating a fixed asset finding usually exceeds the cost of doing it properly.
Before adopting any third party application, the discipline worth applying is checking what standard NetSuite already does.
NetSuite includes fixed asset capability that covers a meaningful proportion of what many businesses need, and it is not uncommon to find a business licensing a third party tool to solve a gap that was a configuration exercise.
The honest assessment is where the standard capability stops relative to your requirements. Businesses with straightforward registers frequently find it sufficient. Businesses with complex multi book requirements, substantial construction in progress or unusual depreciation treatments more often need the additional depth.
Establishing that before committing is a short exercise and it occasionally saves the whole cost. Our piece on advanced NetSuite modules to consider after go live covers how to make that assessment generally.
Adopting an asset application is a small project and the work concentrates in establishing the opening register accurately.
Every asset has to be loaded with its cost, acquisition date, accumulated depreciation to date, remaining life, method and residual value, for each book maintained.
That opening position has to reconcile to the ledger and to the existing register, because everything afterwards builds on it. An opening balance that is slightly wrong produces a permanently slightly wrong register.
The accounting mapping has to be set so depreciation, disposals and transfers post to the right accounts and dimensions, which is what delivers the reporting benefit.
And the migration is a good moment to review the register itself. Assets that were disposed of physically and never removed, assets fully depreciated and still carried, and useful lives that no longer reflect how long things actually last. Most registers contain some of each.
The multiple books question is the most diagnostic, because it is where spreadsheet registers most often fail and where applications differ most in capability.
If your fixed asset register currently lives in a spreadsheet, the useful question is not whether it produces the right numbers today. It is whether it will still be right after the next disposal, and whether anybody other than its author could demonstrate that it is.
A short review of the register size, the number of books, the movement frequency and the effort it consumes each period will usually make the decision straightforward.
Our piece on optimising equipment returns with better asset management covers the operational side of the same data, and managed services covers the ongoing capability to run applications like this properly.
If you would like a view on whether your register warrants a purpose built solution, get in touch.
