NetSuite implementation: six cleanup items to complete before go-live

Before a NetSuite implementation, six accounting areas need cleanup: the chart of accounts, the customer and vendor lists, old uncleared checks and deposits, unapplied AR and AP transactions, prepaid support files, and fixed asset support files. Each one determines what gets loaded at go-live. Each one is far cheaper to fix in your legacy system than it is inside NetSuite.

The reason is simple. Once a duplicate vendor, a stale uncleared check, or a miscoded journal entry crosses into NetSuite, correcting it means CSV update imports, audit trail noise, and a reconciliation you have to explain to someone. Correcting it in QuickBooks means editing a record.

Here is the NetSuite implementation checklist we walk clients through to prepare their accounting files before cutover.

Key Takeaways

• Redesign the chart of accounts first. It is loaded at the start of the implementation, and every other data set maps to it.
• Consolidate duplicate customers and vendors in the legacy system, not after they land in NetSuite.
• Void and reissue stale uncleared checks in QuickBooks before the first bank reconciliation, not after.
• Apply open payments and add a Name to every AR and AP journal entry so your opening subledger has no orphan lines.

How do you clean up the chart of accounts before a NetSuite implementation?

Start the chart of accounts (COA) redesign at the beginning of the project, because the COA is the first thing loaded into NetSuite and everything else maps to it. Most teams take the opportunity to restructure the COA when they change accounting systems, which is the right instinct and also the reason this item runs long.

Four things move it forward:

• Start early. COA design is the item most commonly begun too late, and it is the one item that cannot be compressed.
• Meet with key stakeholders. Finance, FP&A, and anyone who codes transactions should shape the structure before it is drafted.
• Add a definition to every account. Write one sentence explaining when to use each account. This is what keeps the new COA clean six months after go-live.
• Map legacy accounts to new accounts. Every legacy account needs a destination. This mapping file drives the historical data load, so it has to be complete, not approximate.

QuickBooks and NetSuite treat GL accounts differently, particularly around subsidiaries, currencies, and required account numbers. Our guide to importing your chart of accounts from QuickBooks to NetSuite walks through those differences and the import itself. For sector-specific patterns, see common biotech GL account structures.

Underestimating this step is expensive. A large nonprofit I worked with had to consolidate 16 separate QuickBooks Desktop charts of accounts into a single NetSuite chart. That effort took almost nine months. It significantly delayed the go-live, which compressed the project's return and drained the internal momentum the team had built at kickoff. The COA work itself was unavoidable. Starting it nine months earlier would have been.

Done on the right timeline, the same work pays off. A Vermont nonprofit we supported used the implementation as an opportunity to rationalize its chart, reducing it from 229 GL accounts in QuickBooks Online to 153 in NetSuite. That consolidation was theirs to drive, because only the client knew which accounts were duplicates and which ones mattered. Fewer accounts, each with a written definition, meant less coding ambiguity going forward and a cleaner mapping file for the historical load. The full project is written up in our case study on how a nonprofit migrated 15,671 QuickBooks transactions into NetSuite.

The difference between the two projects was not the amount of COA work. It was when the work started.

How should you clean up the customer and vendor lists before go-live?

Clean the entity lists in the legacy system during the same window as the COA, because customer and vendor records are loaded alongside it at the start of the project. Duplicates that survive the load permanently fragment your AR aging and your AP subledger.

Three actions:

• Consolidate duplicate records. Merge the "Acme Corp" and "Acme Corporation" versions before they become two separate NetSuite entities with split balances.
• Track changes in the system, not in Excel. If you update entity records, make the edits in the legacy system so the export you eventually hand over is the current state.
• Deactivate unneeded entities. Every inactive vendor you carry across is a record someone has to scroll past for the next decade.

If your legacy system stores multiple addresses per entity, review our guide to importing entity addresses from QuickBooks Online into NetSuite before exporting.

Entity cleanup is often more than deduplication. In connection with a recent acquisition of a personal injury law firm, we reviewed the acquired firm's QuickBooks customer list and found that each customer name contained three pieces of information: the case number, the client name, and the ID from the firm's litigation system. We separated those into discrete values so each one could land in the right field in NetSuite rather than being stranded in a name string. We then worked through the parent-and-child relationships to consolidate the list wherever the same client appeared in multiple matters. The list got shorter, and more importantly, it became structured data the finance team could actually report on.

The lesson generalizes past law firms. If your customer names encode information that belongs in a field, resolve that before the export, not after the load.

What should you do with old uncleared checks and deposits before migrating?

Void and reissue stale uncleared checks and deposits in QuickBooks before the migration, because doing the same cleanup after go-live is significantly harder in NetSuite. On the go-live date, you will import all outstanding bank transactions to complete the first bank reconciliation. Anything unresolved at that moment comes across.

Work through the aged items first:

• Review the uncleared list by age. Items older than a year are usually the ones that will never clear, and they are far easier to void and reissue in the legacy system than in NetSuite.
• Void and reissue in the legacy system. The correction is a single transaction in QuickBooks. In NetSuite, it becomes a suspense account entry, a reversing journal entry, and a matching exercise.
• Confirm the remaining list ties to the last completed bank reconciliation. This list is what your opening cash position is built on, and it becomes the source file for the open bank transaction load at cutover. Our guide to importing open bank transactions to NetSuite walks through how that load works.

This matters most if you are not importing detailed transactions, because the summary trial balance will tie to the GL while the transaction-level detail behind the reconciliation does not.

Not every client arrives with a clean starting point. A Florida-based food packaging supplier went live on NetSuite without having reconciled its cash account in several years. Two problems compounded each other. We had not migrated detailed transactions, so there was no transaction-level history in NetSuite to reconcile against. And because the legacy reconciliation had never been completed, there was no reliable point in time to anchor to either. I did not have a good answer for that client, and there is not a clever import that manufactures one.

That is exactly why this item belongs on a pre-implementation checklist rather than a go-live checklist. The entire open bank transaction process assumes a completed legacy bank reconciliation exists to migrate from. If yours is months or years behind, getting current in the legacy system is the prerequisite, and it takes longer than most teams plan for.

How do you clean up unapplied AR and AP transactions before cutover?

Apply every open payment to its invoice or vendor bill before the migration, because at go-live you will import all open accounts receivable (AR) and accounts payable (AP) transactions exactly as they sit. Unapplied items carry across as unapplied items.

Three cleanup steps:

• Apply customer and vendor payments. Match each open payment to the appropriate invoice or vendor bill in the legacy system.
• Address offsetting journal entries that net to zero. Journal entries tagged with an AR or AP account frequently offset each other. Clear them rather than importing both sides.
• Add a Name to every AR and AP journal entry. Without a customer or vendor on the line, NetSuite produces a No Customer or No Vendor line on your opening subledger, and it cannot be removed without reopening the closed periods. Auditors ask about those lines every time. If you are already living with one, our guide to fixing the No Customer line on NetSuite aging reports walks through the correction.

How should prepaid support files be prepared for NetSuite amortization?

Rebuild the prepaid schedule with NetSuite's segments before go-live so the balances can be loaded straight into amortization templates. At go-live,   you can allocate prepaid balances to an amortization template and use NetSuite's amortization journal entry functionality, but only if the support file is structured for it.

Before anything else, confirm the one prerequisite that stalls this load more than any other: the prepaid support file has to tie to the NetSuite trial balance as of the journal entry date. If the schedule and the GL balance disagree, the entry cannot post until someone explains the difference, and that reconciliation is far easier while you still have the legacy detail in front of you.

Then work through the file itself:

• Remove fully amortized items. Anything with a remaining balance of zero does not need to migrate.
• Add the new segments to every line. Account, department, class, and location. With those in place, the reclassification journal entry becomes a straightforward import instead of a manual rebuild.
• Put a vendor on every line. The opening entry is built with the amortizing amounts by vendor on the debit side and the total by prepaid account on the credit side. A schedule without vendor detail has to be rebuilt before it can be loaded.
• Set an amortization start and end date for each item. These drive the schedule NetSuite generates. For a single-period charge such as a conference registration, set the start and end date to the same month.
• Decide which amortization template each item uses. NetSuite builds the schedule from the template assigned on the line, so that decision belongs in the support file rather than in cleanup afterward.
• Confirm currency and subsidiary on every line if you operate multiple entities. Both have to be resolved before the entry is built, not corrected after it posts.

What does NetSuite need in the fixed asset support file at go-live?

If you are implementing the fixed asset module, the fixed asset records are imported on the go-live date, so the support file must include the full set of attributes NetSuite requires. A depreciation schedule built for a spreadsheet usually does not.

Start with the same gate as prepaids: the fixed asset subledger has to tie to the trial balance by asset type. If it does not tie, resolve that in the legacy system first. Loading assets off a subledger that does not reconcile moves an existing problem into a system where it is harder to find.

Confirm the file includes:

• Asset type and useful life for every asset, in values that map to what is configured in NetSuite.
• Department, class, and location. The asset segments determine the coding on the calculated depreciation expense, so they matter well beyond the asset record itself.
• In-service date and asset status. Status is new, depreciating, or fully depreciated, depending on where the asset sits in its life.
• The last depreciation period. This is the period through which depreciation has already been recognized, and it is the field to get right. It carries accumulated depreciation and remaining life forward so the first depreciation run in NetSuite picks up exactly where the legacy system stopped.
• An asset tag for each record. NetSuite does not require asset tagging, but implementing a tagging system supports SOX requirements and makes the financial statement audit substantially easier.

For the full load sequence, including how depreciation history is loaded after the asset records, see our guide to migrating fixed assets into NetSuite during an implementation.

Frequently asked questions

When should accounting cleanup start before a NetSuite go-live?

Start at the beginning of the implementation, not near cutover. The chart of accounts and the customer and vendor lists are loaded at the start of the project, so cleanup of those records must be completed before the first master data load. The bank, AR, AP, prepaid, and fixed asset items are tied to the go-live date itself and can run in parallel with the build.

Should you clean up data in QuickBooks or wait until it is in NetSuite?

Clean it in the legacy system. Voiding and reissuing stale uncleared checks, consolidating duplicate entities, and applying open payments are all faster in QuickBooks than in NetSuite. The gap widens if you are not importing detailed transactions, because the corrections must then be made against summary balances rather than the original documents.

What happens if you skip accounting cleanup before migrating to NetSuite?

Unresolved records carry into NetSuite and become permanent. Duplicate customers fragment AR aging, unapplied payments distort the opening subledger, journal entries without a Name create No Customer or No Vendor lines that auditors question, and stale uncleared checks block the first bank reconciliation. Each one is fixable after the fact, but the fix runs through CSV update imports and leaves an audit trail you have to explain.

The underlying principle

Every item on this list follows the same logic: cleanup is cheap in the legacy system and expensive in NetSuite. Your team still has full control over the source data today, including the original documents, the original coding, and the ability to correct a record with a single edit. That control ends at cutover.

The teams with the smoothest go-lives are not the ones with the cleanest starting data. They are the ones who decided early which cleanup was worth doing and finished it before the load, so that go-live week was about validating balances rather than discovering problems.

If you want to see how the data migration piece fits into your implementation timeline, take a look at our data migration process.