Reviewing Fixed Assets Before Go-Live

The question is why a sandbox review matters before a fixed assets module becomes part of the month-end close. It is not because the screens need to look right. It is because fixed assets sit at the intersection of procurement, operations, accounting policy, depreciation, tax, reporting, and audit evidence.

What is at stake is control over a long-lived balance sheet area that moves slowly but accumulates errors quietly. A weak configuration may not fail on day one. It may fail three closes later, when depreciation posts to the wrong cost center, disposals bypass gain or loss accounts, or asset additions cannot be reconciled back to payables.

From first principles, an ERP fixed assets module should do three things well: capture the economic event, classify it according to policy, and translate it into repeatable general ledger activity. A sandbox review is the place to test whether the system can do that before real transactions depend on it.

The Sandbox Is a Model of the Future Close

A sandbox is not just a training environment. Used well, it is a low-risk model of the future operating system. It lets the team see whether configuration decisions support the actual work: creating assets, assigning books, calculating depreciation, posting journals, reconciling balances, and reporting to stakeholders.

For a fixed assets module, the review should not start with navigation. It should start with the close process. The practical question is simple: if the month ended today, could the team complete the fixed asset close in the system, explain the results, and reconcile them to the general ledger?

That question changes the nature of the session. Instead of asking whether each field is available, the team tests whether the full workflow holds together.

Configuration Decisions Become Accounting Outcomes

Fixed asset configuration can look administrative, but most choices have accounting consequences. Asset types, depreciation methods, useful lives, residual values, conventions, posting accounts, and subsidiary rules all shape the financial statements.

In NetSuite, the fixed assets setup typically depends on several connected components:

Asset types that define the default treatment for classes such as equipment, vehicles, leasehold improvements, furniture, or software
Depreciation methods that determine expense patterns over time
Accounting books that may support different reporting bases
GL account mappings for asset cost, accumulated depreciation, depreciation expense, disposals, gains, and losses
Department, class, location, or project dimensions used for management reporting
Transfer and disposal rules that determine how asset movement is reflected

A sandbox review should make these connections visible. If the asset type drives the wrong expense account, the problem is not cosmetic. It becomes recurring misclassification. If the location dimension is optional but required for reporting, the system will create cleanup work each month. If disposal accounts are incomplete, the team may discover the gap only when the first retirement occurs.

The GL Mapping Is the Control Point

The general ledger mapping is often the most important part of the review because it determines whether operational asset activity becomes reliable accounting activity.

A useful review asks:

Does each asset type map to the correct fixed asset cost account?
Does accumulated depreciation post to the right contra-asset account?
Does depreciation expense follow the intended department, class, or location logic?
Are gain and loss accounts defined for disposals?
Are write-offs and transfers handled consistently?
Are clearing accounts used, and if so, who reconciles them?

The team should test mappings with real examples rather than abstract confirmation. For instance, create a laptop asset, a warehouse equipment asset, and a leasehold improvement asset. Give each one realistic department and location values. Run depreciation. Post the journal. Then inspect the ledger impact.

This kind of test reveals whether the configuration is aligned with how the company actually reports. It also reduces reliance on memory. The system should carry the policy wherever possible.

Asset Creation Needs a Clear Source of Truth

One of the most common fixed asset issues is not depreciation. It is asset creation. Teams need to know how an asset enters the module and when it is considered complete enough to depreciate.

In many ERP environments, additions can originate from vendor bills, purchase orders, manual asset proposals, CSV imports, or project capitalization processes. Each path has different control risks.

A sandbox review should clarify:

Which transactions are eligible for capitalization
Who reviews and approves proposed assets
What minimum fields are required before asset creation
How partial invoices, deposits, and freight are handled
Whether multiple bills combine into one asset or remain separate
How repairs and maintenance are kept out of the asset register

A simple example helps. Suppose a machine costs 120,000, freight costs 4,000, installation costs 8,000, and a maintenance contract costs 6,000. The module and process should support capitalization of the correct 132,000 while excluding the maintenance contract. If that distinction depends entirely on manual spreadsheet work, the ERP configuration is not yet carrying enough of the process.

Month-End Workflow Should Be Rehearsed, Not Assumed

Training sessions often teach individual tasks. A sandbox review should also rehearse the sequence.

A fixed asset month-end workflow may look like this:

Review new capital transactions and create asset records 2. Confirm required classifications and in-service dates 3. Review additions, transfers, and disposals for the period 4. Run depreciation proposals or calculations 5. Review depreciation results by asset type and account 6. Post depreciation journals to the general ledger 7. Reconcile the fixed asset subledger to GL balances 8. Produce roll-forward and supporting reports 9. Investigate exceptions before close sign-off

The value of the sandbox is that the team can run this sequence with test data. They can see where the handoffs are unclear. They can identify which reports are missing. They can confirm whether depreciation can be reviewed before posting. They can test whether a posted journal contains enough detail for review and audit.

This is also where role design becomes visible. If the accountant who reviews depreciation cannot access the supporting asset detail, the control will not function. If too many users can change asset records after depreciation is posted, the process may lack discipline. Access is part of the workflow, not a separate technical detail.

Exception Handling Is Part of the Design

Clean transactions are easy. The system design is tested by exceptions.

The sandbox should include cases such as:

An asset with the wrong in-service date
A vendor bill coded to the wrong capitalization account
A disposal in the middle of the month
A transfer between departments or locations
A fully depreciated asset that remains in use
An asset split into components
An impairment or write-down scenario
A prior-period correction

These examples do not need to cover every possible event. They need to show whether the team knows where the process bends and where it breaks. A good configuration makes common exceptions manageable and makes unusual exceptions visible.

The review should also document decisions. For example, if mid-month disposals use a specific depreciation convention, that should be recorded. If prior-period corrections require controller approval, that should be part of the procedure. The sandbox is where undocumented assumptions become explicit.

Reporting Must Serve Both Close and Control

Fixed asset reporting has two audiences. The first is the close team, which needs accurate roll-forwards, additions, disposals, depreciation, and ending balances. The second is the control environment, which needs evidence that activity was reviewed and reconciled.

A practical reporting set should include:

Fixed asset register by asset type
Additions report for the period
Disposal report for the period
Depreciation expense detail
Asset roll-forward by GL account
Subledger-to-general-ledger reconciliation
Assets missing required classification fields
Assets with unusual useful lives or methods

The review should test whether these reports tie together. If the roll-forward says additions are 500,000, the additions detail should support that number. If depreciation expense posts to multiple departments, the report should show how those amounts were derived. If the GL balance differs from the subledger, the team should know whether the cause is timing, manual journal activity, or configuration.

A report that cannot be reconciled is not a report. It is a data extract.

What to Capture After the Session

The output of a sandbox review should be more than a list of observations. It should create a path to readiness.

A useful follow-up includes:

Configuration gaps and owners
Open accounting policy decisions
Test scenarios completed and results
Required report changes
Role and access issues
Month-end procedure updates
Data migration or beginning balance concerns
Items that must be retested before go-live

This creates a clean distinction between training and readiness. Training means users understand how to perform tasks. Readiness means the process, configuration, controls, and reporting can support production activity.

Small Errors Compound in Fixed Assets

Fixed assets rarely create the urgency of cash, revenue, or payroll. That is why they need a careful system review. Errors can sit inside the asset register for years. A wrong life, method, account, or department may repeat every month until someone notices a variance that no longer has an obvious source.

A sandbox review reduces that risk by forcing the configuration into the open. It gives accounting, finance systems, and operations a shared view of how asset activity will move through the ERP. It also helps the team decide what should be automated, what should be reviewed, and what should remain a controlled manual judgment.

Ultimately, the purpose is not to make the fixed assets module perfect. The purpose is to make it dependable enough for the close, transparent enough for review, and flexible enough for real business events.

What this means is that a training session should be treated as a design checkpoint. The navigation matters, but the larger question is whether the system can produce the right accounting outcomes repeatedly.

The takeaway: fixed asset readiness is built by testing the whole chain, from source transaction to asset record to depreciation journal to reconciliation. The sandbox is where that chain should be proven before production has to rely on it.