How OptimalData Proves a Detailed Transaction Migration Is Complete: The Tie-Out Process

Introduction

When you migrate detailed transactions into NetSuite rather than summary balances, you assume an obligation. You have to prove that what landed in NetSuite matches what was in the legacy system, transaction by transaction. The artifact we use to prove it is the detailed transaction tie-out.

This is the validation step that runs after a batch of detailed transactions has been loaded. It compares the legacy master transaction file against the NetSuite transaction list and reports, test by test, where the two agree and where they do not.

What the tie-out process checks

The tie-out is a single file with one tab per test. Each test gets its own column, so you can filter to pass or fail and work the exceptions. The tests cover:

• Existence: every NetSuite external ID maps to a valid legacy transaction in both systems. Zero-dollar records, such as bill payment voids and check voids, are returned as not applicable because they have no GL impact and cannot be loaded.
• Debit and credit variance: compares the debit and credit amounts between systems. This is where payment-application differences surface.
• Date match and transaction number match: straightforward field comparisons. Journal entries are excluded from the number match because auto-generated numbers often differ, and an account that allows duplicate transaction numbers can force a suffix on a record.
• Currency match and exchange rate: confirm the currency code and rate carried over.
• Due date: matters most when you are validating open AP and open AR.
• Line count variance: a transaction with five lines in the legacy system has five lines in NetSuite, so nothing was added or dropped in the load.
• Name, account, and amount: group transactions by transaction, entity, and account, then compare the net GL impact on each combination.

Not every fail is a problem

The point of the tie-out is judgment, not a green checkmark. Materiality matters. Some fails are expected on review. A check that debits and credits the same account, for instance, has zero GL impact, and NetSuite will not allow it, so it is intentionally omitted from the load. Or the client might choose to have NetSuite auto-generate transaction numbers, which would cause differences in transaction number validation. Some fails are corrections the client has explicitly asked for. And some are better surfaced to the client to investigate, such as an unmapped entity on a payment that looks like a source-data mistake, rather than being corrected on their behalf.

Document the variances

For every intentional variance, write the reason directly in the file. One line is enough: one fails due to a NetSuite constraint preventing a debit and a credit to the same account. The documented file is the audit artifact. It is what lets a controller, weeks or months later, explain why a number is what it is without having to reconstruct the cutover from memory.

The resolution loop

The workflow is short and repeatable. Run the tests and export the results. Review each failure and find the root cause. If it is fixable, correct it in NetSuite and re-run the tie-out. Save the final results to the batch folder for reference, and share the file with the client if they want to validate it themselves.

Conclusion

The speed of a migration is not what a controller remembers during an audit. The documentation is. A detailed transaction tie-out with every variance explained is the difference between fieldwork that moves quickly and fieldwork that turns into a reconstruction project.

If you are planning a detailed transaction migration and want the cutover to be audit-ready, let's talk.