Financial Statement Audit, Implementation, Fixed Assets
June 18, 2026
3 min Read
Migrating Fixed Assets into NetSuite During an Implementation
Introduction
Fixed assets are one of the migration workstreams that look simple on a project plan and then quietly consume a week. The asset balances have to tie, the depreciation has to continue from where the legacy system left off, and the whole thing has to land in NetSuite's Fixed Asset Management module in a structure NetSuite will accept. Here is the sequence we follow.
Start by tying the subledger to the trial balance
Before anything moves, get the fixed asset subledger from the client and tie the asset-type balances back to the trial balance. This is a gate, not a formality. If the subledger does not tie to the GL, stop and go back to the client. Loading assets off a subledger that does not reconcile just moves an existing problem into a new system, where it is harder to find.
Map what NetSuite needs for each asset
Once the file ties, build the upload from the subledger. A few fields carry most of the work:
- Asset type and asset lifetime have to map to the values configured in NetSuite. Keep the mapping in its own tab for auditability.
- Department, location, and class map to the segment values, which can differ slightly from the account mapping. This is important because the asset segments will determine the coding for the calculated depreciation expense.
- Depreciation start date is usually the end of the month of the in-service date. Depreciation end date follows from the start date and the useful life.
- Asset status is new, depreciating, or fully depreciated, depending on where the asset is in its life.
- The last depreciation period is the period through which depreciation has already been recognized.
The last depreciation period is the one to get right. It carries forward accumulated depreciation and remaining life, so the first depreciation run in NetSuite picks up exactly where the legacy system left off.
Load a sample before the full population
Do not load the whole population first. Load a sample of a handful of assets and confirm they look right with both the client contact and the implementation partner. A few mechanics matter here. The import type is a custom record against the FAM Asset record. The run-workflow box must be set, or the asset records will not be generated correctly. The external ID maps to the asset ID, and any field that NetSuite treats as an ID, including segments and the asset type, must map to the internal ID rather than the display name.
Once the sample is confirmed, load the full population and work through any errors.
See this NetSuite help article for additional help documentation on loading the fixed assets.
Then load the depreciation history
The asset records alone do not carry accumulated depreciation. After the assets are in, load the asset depreciation history records. Most of the fields come straight from the support file you already built. The transaction date is the last date depreciation was posted in the legacy system, and the transaction amount is the cumulative depreciation through that date.
See this NetSuite help article for additional help documentation on loading depreciation histories.
Why the order matters
The sequence is the point. Tie the subledger first, so you are not loading a broken balance. Map and sample before you commit the full population, so a structural mistake shows up on five assets instead of five hundred. Load the depreciation history last, so the assets exist for the history to attach to. Skip a step, and the depreciation schedule in NetSuite will not match what the client was running the month before go-live, which is exactly the kind of variance an auditor asks about.
If you are scoping a NetSuite go-live with a fixed asset register to migrate, let's talk through the sequence.
