Fixed Asset Management

This article will be helpful to users who would like to understand the underlying structure of NetSuite’s Fixed Asset Management (“FAM”) SuiteApp and its relationship with the General Ledger and with the standard transactions that affect Fixed Asset balances.

FAM Structure

The first key in understanding how FAM works is to remember that it is not a true subledger to the Fixed Asset GL accounts, although at first glance it appears to be one. To illustrate this, we can compare it to Accounts Receivable in NetSuite. Any transaction hitting a customer’s A/R account automatically is reflected in the general A/R account, and therefore no separate function is needed to post the A/R subledger accounts to the parent A/R account. In fact, we can look at each customer’s A/R subledger as merely a “filtered” view of the general A/R account.

In contrast, the FAM module sits as a separate system to the GL. It contains custom records that represent Assets, Depreciation, and other entries, all of which are intended to be supporting records to parallel transactions hitting the general ledger. For example, a Depreciation record in FAM is a custom record which will normally have a linked Journal Entry affecting the Ledger. This may not be obvious since FAM does automate the Journal Entries based on Depreciation records, so users can be confused and can make the wrong assumption that the Depreciation record is itself what affects the Ledger. The same goes for Asset proposal, creation, and disposal. They all normally have linked transactions which affect the ledger, but the records in FAM themselves are just custom records that support and contain detail about the transactions.

Data Layers

The next important point to realize about FAM is that it contains several layers of data that help automate the various transactions and processes. In other words, the link between the GL-hitting transactions and the custom records for Assets, Depreciation and the like is not a direct link. There are hidden records that serve as bridges between the native GL transactions and the FAM records.

Once we understand how these data layers work and interact with the custom records, it will become much easier to troubleshoot discrepancies and problems with FAM reports. In my experience, many of the discrepancy issues that arise between FAM reports and the GL result from problems with these “hidden” records.

Let’s look at a few of the main functions of FAM and examine what happens under the hood during the process.

Creating New Assets

New assets start with a transaction such as a Vendor Bill or Journal Entry which affects a ledger account that has been identified as an Asset account in the FAM Asset Type setup. The transaction automatically triggers a custom record called “FAM Asset Proposal”, which drives the asset creation. The user can accept or reject the asset proposal. When a proposal is accepted, the following records also get automatically created, in sequence:

1. Asset Record – this the user-facing record which holds all the information about the Asset.
2. FAM Asset Value Record – this is a linked record to the main asset record and contains only the values needed to calculate depreciation.
3. Depreciation History Records (DHRs) – these are records representing the various transactions that occur in the Asset’s life cycle such as Acquisition, Depreciation, Write-down, and Disposal. Upon asset creation, an Acquisition record and scheduled Depreciation records are created.

The FAM Asset Proposal record is what the Asset creation depends on. If an asset was created in error and the user wants to re-create the asset with corrections, the Asset Proposal needs to be deleted to start the process from scratch. There is a feature in FAM to delete an asset and all dependant records, but it doesn’t always succeed for various reasons. When there are problems deleting an asset, often the solution will be to first delete the FAM Asset Proposal.

The Asset record and the Depreciation History Records (DHRs) are visible and prominent when using FAM. However, to view the FAM Asset Value records, a saved search based on that record type is needed, as there is no menu navigation to these records within FAM. The Asset Value records are what directly drive the DHRs, and therefore if these failed to get created, no DHRs will get created, and in turn, it will not be possible to run depreciation.

FAM Depreciation

More about DHR’s

As mentioned, the Depreciation History Records consist of several types, representing the various transactions that affect an asset’s net book value. Upon creation of an asset, DHRs are created that represent all future scheduled depreciation, and one more record type is sometimes created:

1. BG Summary Record – this is a record that will be a bridge between the Depreciation DHRs and the Depreciation Journal Entries each month.

This record holds summary information for each combination of depreciation period, asset type, subsidiary, class, department, and location. The purpose of these records is to make the monthly depreciation process more efficient. As each new asset is created, NetSuite’s FAM scripts look to see if BG Summary records already exist for the combination of dimensions relevant for the new asset. If records exist, the Depreciation DHRs get tagged with the existing BG Summary records, otherwise, new BG Summary records are created.

(Side note: I’m not sure what “BG” stands for, but I believe it’s “BackGround” based on the wording in some SuiteSolutions articles).

Monthly Depreciation

When the monthly depreciation process is triggered in FAM, the depreciation values are aggregated across all assets of the same type, subsidiary, class, department and location, and a Journal Entry is created with lines for each summary amount. Then the BG Summary records are updated with a link to the relevant Journal Entry and the aggregate Depreciation amount. The BG Summary records appear in a sublist on the Journal Entry.

This record structure makes it difficult to craft searches that show a reconciliation of Depreciation amounts posted to the GL and the records in FAM, since there is no direct link between the two.

Asset Revaluation

Let’s focus on one more FAM process. Asset revaluation is similar to Depreciation, in that it is a process initiated in the FAM module, but which triggers a Journal Entry which hits the Ledger. Here again, a DHR record is created called a “write-down”, but unlike depreciation, there is a direct link between the DHR and the Journal entry, populating a field on the DHR “Posting References”.

The Revaluation also updates the Asset Record, and its underlying “FAM Asset Value” record (see the section above “Creating New Assets”). This step is needed so that future depreciation reflects the change in Asset value.

Conclusion

FAM is an excellent module, but it can be tricky to understand because of the fact that it is really a separate system of records that indirectly links to the core NetSuite financial system. If you can use some help using or troubleshooting FAM, I’d be happy to hear from you!