.svg)
This question matters most when there is no opportunity to go back and check. Once a NetSuite account has been decommissioned or a subscription has lapsed, an incomplete export is no longer an inconvenience. It becomes a permanent gap in the record, and that gap is usually discovered during an audit some years later.
Four layers of verification
A complete verification covers four layers. Record counts are the weakest of the four, and they are also the most commonly used.
- Record counts for each record type, compared between the source account and the export
- Financial totals, including trial balance and general ledger, reconciled to the penny
- Referential integrity, confirming that relationships between records have survived
- Spot-checks of individual records, inspected field by field
Many teams perform the first layer and stop there. It is also the layer most likely to produce a false result.
Why a matching record count is not sufficient proof
Consider a common scenario. You build a saved search to export your customer records, and it returns 14,231 rows. You export the results, count the rows in the file, and arrive at 14,231. The figures match, so the export appears complete.
The difficulty is that the figure you compared against was produced by the same search that generated the export. If that search excluded records, both figures are wrong in the same way, and they will agree precisely.
Inactive records
NetSuite allows a record to be marked inactive rather than deleted. Oracle's documentation on inactivating records explains that an inactive record remains in the system for future reference but no longer appears in lists for selection, which is why list pages provide a Show Inactives option.
That behaviour is appropriate for day-to-day operation. It is less appropriate when the objective is a complete archive. Inactive customers, vendors and employees are frequently the records an auditor asks about, precisely because they are no longer active in the live system.
Recommended check: for each entity record type, confirm the inactive criterion on your search explicitly rather than relying on the default, and verify that the exported set contains records you know to be inactive. If the export contains no inactive records at all, the criterion has excluded them.
Row limits and silent truncation
Export paths have row ceilings, and those ceilings differ by method. A saved-search CSV export behaves differently from a programmatic query. Where a limit is reached, the resulting file may open correctly, contain valid data, and simply be short. Confirm the current limit for the method you are using against Oracle's documentation rather than relying on a figure quoted elsewhere, because these limits change between releases.
Recommended check: treat a row count that falls on a round number as potentially truncated until you have established otherwise. An export returning exactly 5,000 or exactly 100,000 rows warrants confirmation before it is relied upon.
Duplicate rows
Certain record types can return several rows for what a user would consider a single record, with versioned items being the most common example. A count higher than expected is as significant a signal as a count that is lower.
Recommended check: deduplicate on internal ID before comparing counts.
Fields removed before extraction
Where a custom field has been deleted, its data is removed with it, and searches that reference the field may lose the column. Oracle documents this behaviour under inactivating a custom field.
Recommended check: compare the field list of your export against a current list of fields on the record type, including custom fields, rather than assuming the saved search covers them all.
Layer two: reconciling the financials
Record counts confirm that rows arrived. They provide no assurance that the values are correct.
- Run a trial balance as at your cutover date and reconcile it against the same period in the archive, covering every GL account and every subsidiary, to the penny
- Reconcile transaction totals by type and by period rather than relying on a grand total, because offsetting errors are concealed in aggregate figures
- Where Multi-Book accounting is in use, reconcile each book separately. A single-book reconciliation performed on a multi-book account will balance and remain incomplete
Counts identify missing rows. Financial reconciliation identifies missing values.
Layer three: confirming relationships survived
An archive of records without the relationships between them is a collection of rows rather than an archive. An invoice that no longer links to its customer, its sales order or its payment cannot answer an audit question. Confirm that transactions resolve to their entities, that line items remain attached to their headers, and that parent and child structures are intact. Attachments and File Cabinet documents should also resolve to the records they belong to. This is commonly the weakest point, because files and records are frequently extracted through separate processes.
Layer four: inspecting individual records
Select records deliberately rather than at random. Useful candidates include the oldest transaction in the archive, the largest by value, one with the greatest number of line items, one with attachments, one that was amended or reversed, and one belonging to an inactive entity.
Open each record in NetSuite and in the archive together and compare them field by field. Six records inspected carefully will reveal more than a thousand records counted.
Accounting for changes during extraction
Where staff continue to work in NetSuite while an export is running, the source is changing as the extraction proceeds. Records created or amended after extraction began will be absent from the file, and verification will not detect this, because the comparison takes place after the change.
There are two established approaches. A freeze, meaning a suspension of data entry for the duration of the extraction window, is the cleanest option and is rarely practical for a business in the middle of a migration. A delta pass takes the full extract, allows work to continue, and then captures everything that changed before the true cutoff. A delta pass requires re-verification, applying the same layers again across the combined set. The delta approach is usually the realistic one, and it is the step most frequently omitted.
A workable order of operations
- Inventory every record type and custom record in the account. You cannot verify what you did not know to export
- Capture baseline counts from the account itself rather than from the export
- Perform the extraction
- Reconcile counts for each record type and account for every discrepancy. An explained difference is acceptable; an unexplained one is a finding
- Reconcile the financials, covering trial balance, general ledger by subsidiary, and each accounting book
- Verify relationships and attachments
- Inspect the deliberately selected records
- Run the delta pass, then repeat steps four through seven across the combined set
- Ask the people who will use the archive to test it against real questions before sign-off
The final step is the one most often skipped. A finance team asked to answer three genuine questions from the archive will identify problems that no checklist will surface.
When verification exceeds what a checklist can cover
On a small account with a limited number of record types, a careful team can work through the above without assistance. The approach becomes impractical at scale, where there are hundreds of record types, extensive customisation, many years of history, multiple subsidiaries and accounting books, and a decommissioning date that cannot move. Verification then represents the majority of the work rather than a final step, and reviewing record types manually amounts to sampling rather than verification.
At that point, extraction and verification are better handled as a single managed process. Our NetSuite data extraction and archival service performs the extraction and the reconciliation together, and the resulting archive remains accessible and read-only in DBVault once the project is complete. If you are working toward a decommissioning date, the most useful conversation is the one held before extraction begins.
.svg)
.svg)
.svg)
.svg)
