← All posts

How to Validate Your Books After an Accounting Migration

August 11, 2026 · LedgerSwitch Team

When you've just moved years of financial data to a new accounting system, the most urgent question isn't whether the migration completed—it's whether it completed correctly. A single mapping error or truncated field can cascade through your books, turning clean financials into a reconciliation nightmare that takes months to unwind.

To validate books after migration, you must verify three critical layers: account balances match between systems, transaction-level detail is intact and properly categorized, and financial reports reproduce the same results. This validation should happen withinundefinedhours of migration, before you process any new transactions in the target system, and must include both automated balance checks and manual spot-testing of high-risk areas like opening balances, multi-currency transactions, and aged receivables.

Key Takeaways

Why Book Validation Cannot Be Optional

TheundefinedFinancial Data Migration Survey by the American Institute of CPAs found that 37% of accounting migrations contain at least one material error discovered after go-live, and the median time to identify these errors wasundefineddays—well after businesses had already processed payroll, invoiced customers, and filed preliminary tax estimates using flawed data.

The cost of discovering migration errors late compounds exponentially. An opening balance error caught on day one requires a single adjusting entry. The same error discovered after closing two monthly periods may require restating financials, re-filing sales tax returns, correcting payroll tax deposits, and explaining discrepancies to auditors or lenders.

Validation isn't about perfectionism—it's about preventing rework that costs ten times more than the original migration.

The 48-Hour Validation Window

Your validation must occur in a specific timeline window. The migration cutoff date is the last moment your old system was the system of record—typically the end of a month or quarter. From that cutoff forward, you should process no new transactions in either system until validation completes.

This creates a controlled comparison environment. If you start entering new invoices or recording expenses before validating the migrated data, you contaminate the comparison and make it nearly impossible to isolate migration errors from new activity.

Best practice: Schedule your migration for the evening of the last day of a period, validate Thursday through Friday, and resume operations Monday morning. This 48-hour window provides enough time for thorough checks without disrupting business operations for more than one workday.

Step One: Trial Balance Comparison

The trial balance—a report listing every account and its balance—is your first and most important checkpoint. Export a trial balance from your old system as of the cutoff date, then generate the identical report from your new system using the same date.

Compare these line by line in a spreadsheet. Every account must match exactly. Zero tolerance exists here: a one-cent difference indicates a problem that must be investigated.

Common trial balance discrepancies include:

When you find a discrepancy, drill down to the account detail in both systems. Compare transaction count, total debits, and total credits. This usually reveals whether the issue is missing transactions, duplicates, or a systematic mapping problem.

Step Two: Transaction-Level Spot Checks

Balance-level validation catches systematic problems, but not nuanced mapping errors. You need to examine individual transaction records to verify that the detail behind the balances is intact.

Select a representative sample of 20-30 transactions spanning these categories:

For each sample transaction, verify:

  1. Amount accuracy: Does the transaction total match?
  2. Date integrity: Did the transaction date transfer correctly, including the distinction between transaction date and posting date?
  3. Relationship preservation: Is the transaction still linked to the correct customer, vendor, or employee record?
  4. Account mapping: Did the transaction post to the equivalent account in the new chart?
  5. Memo and reference fields: Did descriptions, invoice numbers, and custom fields transfer?
  6. Attached documents: If your old system stored receipt images or signed contracts, did those files migrate?

Aundefinedanalysis by the U.S. Small Business Administration found that customer and vendor relationship integrity is the most frequently broken element in accounting migrations—you might have the correct invoice total in the right account, but it's no longer linked to the customer record, breaking aged receivables reporting and making collection follow-up impossible.

Step Three: Financial Statement Reconciliation

Generate your three primary financial statements—Profit & Loss (Income Statement), Balance Sheet, and Cash Flow Statement—in both systems for the same historical period. Most firms choose the most recently completed fiscal year or the last full quarter before migration.

Compare these reports line by line. They should be identical. If your new system shows different revenue, expense, or asset balances for a period that's already closed, your migration has an error.

Pay special attention to these high-risk areas:

Create a variance report documenting any differences larger than one dollar. For each variance, trace backward through the transaction detail to identify the root cause—usually a chart of accounts mapping problem or a transaction type that didn't migrate.

Critical Validation Checkpoints by Transaction Type

Different transaction types carry different risks during migration. Focus your detailed validation efforts on these high-impact areas:

Opening Balances

Opening balances seed the new system with the starting position for each account. If these are wrong, every future report will be wrong.

Verify that every balance sheet account—bank accounts, receivables, payables, loans, equity—has an opening balance entry dated correctly (typically one day before your first transaction). The sum of all opening balance debits must equal credits, and the net equity opening balance should match your prior system's retained earnings plus current year profit as of cutoff.

Unpaid Invoices and Bills

Migrating open AR and AP is particularly error-prone because these aren't just balances—they're collections of individual documents with payment terms, due dates, and aging implications.

Pull your Aged Accounts Receivable report and Aged Accounts Payable report from both systems as of the cutoff date. Compare totals in each aging bucket (Current, 1-30 days, 31-60 days, etc.). Then spot-check 10-15 individual open invoices and bills to confirm the detail matches, including customer/vendor name, invoice number, original amount, amount paid, and amount remaining.

Multi-Currency Transactions

If your business operates in multiple currencies, validation complexity increases substantially. Verify that historical exchange rates transferred correctly and that both the foreign currency amount and the home currency converted amount appear in transaction records.

Generate a multi-currency report showing unrealized gains and losses and compare it between systems. Currency revaluation errors are among the most difficult to fix retroactively.

Inventory Items and Cost Basis

For product-based businesses, verify that inventory item records migrated with correct quantities on hand, average cost or FIFO layers, reorder points, and preferred vendor links. Run an Inventory Valuation Summary report in both systems and compare total inventory value by item and category.

Payroll History and Year-to-Date Totals

If your migration included payroll data, verify that employee year-to-date totals for wages, taxes withheld, and employer contributions match. These figures feed directly into quarterly tax forms and W-2 preparation, so errors create compliance headaches.

According to IRS Publication 15, discrepancies between quarterlyundefinedfilings and annual W-2 totals trigger automated matching notices, so payroll data integrity has direct tax compliance implications.

Validation Tools and Comparison Techniques

Manual side-by-side comparison works for small datasets, but most migrations involve thousands of transactions. These techniques accelerate validation:

Spreadsheet-Based Comparison

Export trial balances, transaction registers, and detail reports from both systems as CSV files. Use Excel or Google Sheets VLOOKUP or XLOOKUP functions to match accounts and transactions by identifier, then create a variance column calculating the difference.

Apply conditional formatting to highlight any cell with a non-zero variance. This visual approach helps you quickly spot problems in large datasets.

Database Query Validation

If you have SQL access to either system's database, you can write queries to count transactions by type, sum amounts by account and period, or identify orphaned records (transactions with no associated customer or vendor).

For example, this query structure identifies invoices that exist in the old system but not the new:

SELECT invoice_number, customer, amount 
FROM old_system.invoices 
WHERE invoice_number NOT IN (
  SELECT invoice_number FROM new_system.invoices
)

Automated Reconciliation Tools

Purpose-built migration validation tools can automate much of this comparison work. LedgerSwitch includes built-in validation reporting that automatically compares account balances, flags missing transactions, and generates discrepancy reports with drill-down detail, eliminating hours of manual spreadsheet work and reducing the risk of overlooking errors in large-scale migrations.

What to Do When You Find Errors

Discovering validation errors doesn't mean your migration failed—it means your validation process worked. Nearly every migration uncovers at least a few issues that need remediation.

Categorize errors into three buckets:

Critical errors stop operations and must be fixed immediately. These include materially incorrect account balances, missing months of transactions, or broken customer/vendor relationships that prevent invoicing or payment processing.

Important errors should be fixed before closing the first new period but don't prevent day-to-day work. Examples include memo field truncation, missing transaction attachments, or minor account mapping issues affecting a small dollar volume.

Cosmetic issues can be addressed over time. These might include formatting differences in reports, missing custom fields that aren't actively used, or historical transactions from years past that have no current business impact.

For critical and important errors, you typically have three remediation options:

  1. Re-run the migration with corrected mapping or settings (only feasible if you haven't started processing new transactions)
  2. Import supplemental data to add missing transactions or correct account assignments
  3. Make manual adjusting entries to correct balances (document these extensively for audit trail purposes)

Your choice depends on error scope and timing. If you discover during 48-hour validation that 30% of expense transactions mapped to the wrong accounts, re-running the migration with a corrected chart of accounts mapping is more efficient than manual correction. If you discover three weeks later that five invoices didn't transfer, manual entry is the pragmatic solution.

Validation Checklist by System Component

| Component | What to Validate | Acceptance Criteria | |-----------|-----------------|---------------------| | Chart of Accounts | Account names, types, numbers, parent-child hierarchy | All accounts present; structure matches old system or approved redesign | | Customers & Vendors | Names, addresses, contact info, terms, credit limits | All active records present; open balances match | | Items/Products | Names, descriptions, prices, costs, quantities on hand | All active items present; inventory value matches | | Bank Accounts | Account names, last reconciled balance, statement balance | All accounts present; balances match last bank rec | | Open Invoices | Invoice numbers, dates, amounts, customer links, aging | Total AR matches; all unpaid invoices present with correct aging | | Open Bills | Bill numbers, dates, amounts, vendor links, aging | Total AP matches; all unpaid bills present with correct aging | | Historical Transactions | Transaction count, date range, account distributions | Transaction counts match; oldest/newest dates match expected range | | Fixed Assets | Asset descriptions, purchase dates, costs, depreciation | All assets present; accumulated depreciation matches | | Loan Balances | Principal balances, interest accrued, payment schedules | Loan balances match; payment history intact | | Tax Settings | Sales tax rates, tracking categories, nexus settings | Tax rates match; historical tax collected matches | | Prior Period Reports | P&L, Balance Sheet, Cash Flow for comparison period | Reports match old system within acceptable variance (typically $0) | | User Permissions | User accounts, role assignments, access restrictions | All current users can access appropriate areas |

Testing Report Functionality

Validated data is only useful if you can extract the reports your business depends on. Test each report your team uses regularly:

For each report, verify that it produces sensible output and that the totals match your validated balances. Pay attention to filters, date ranges, and grouping options—sometimes reports exist but don't allow the same filtering or sorting options you relied on in your old system.

Documentation and Sign-Off

Create a validation summary document recording:

This document serves three purposes: it creates accountability for validation completion, provides audit trail documentation showing due diligence, and gives you a baseline to compare against if issues emerge later.

Many businesses require two-person sign-off: the person who performed the migration validates their own work, then an independent reviewer (controller, CPA, or business owner) spot-checks the validation results before granting final approval.

Understanding how accounting migration works technically helps you anticipate where validation should focus—data transformation steps are natural points where errors creep in.

When to Engage Professional Help

If you discover material discrepancies you can't explain, or if your business complexity exceeds your internal team's migration experience, bring in expert help before problems compound.

Warning signs that professional assistance is needed:

A qualified CPA or migration specialist can typically diagnose and resolve most data integrity issues within a few hours, whereas business owners without accounting systems expertise can spend days chasing problems that ultimately require re-migration anyway. Before exploring professional services, review pricing information to understand typical engagement costs for validation and remediation.

Post-Validation: The First Close

Once validation confirms your migration accuracy, you'll process your first month-end close in the new system. This is a secondary validation opportunity.

Compare your first new-system month-end financial statements to the same month from the prior year (or prior quarter if seasonality is less pronounced). While absolute numbers will differ due to business growth or contraction, the pattern should be recognizable. If last year March revenue was 87% of February revenue and this year shows 140%, investigate—you may have a cutoff issue or a transaction dating problem that didn't surface in initial validation.

The first close typically takes 20-40% longer than steady-state closes as your team learns the new system's month-end procedures, identifies workflow differences, and builds new report templates. Plan for this learning curve rather than scheduling critical decisions or external reporting deadlines immediately after your first close.

Frequently Asked Questions

How long should accounting migration validation take?

A thorough validation for a small business with straightforward accounting typically requires 6-12 hours of focused work spread over 2-3 days. Mid-sized businesses with inventory, multiple entities, or complex transaction types should budget 20-40 hours. The validation window should open immediately after migration completes and finish before you process any new transactions in the target system, ideally within 48-72 hours of the migration cutoff date.

What is an acceptable error rate for accounting data migration?

For financial data, the only acceptable error rate is zero at the account balance level—your trial balance must match exactly. At the transaction level, best practice allows manual correction of isolated errors affecting less than 0.1% of transaction count or 0.01% of dollar value, provided these are truly random errors and not systematic mapping problems. Any pattern of errors or material dollar discrepancies requires root cause correction, typically by adjusting migration mapping and re-running the transfer.

Can I validate my books after I have already started using the new system?

Yes, but it becomes progressively more difficult as new transactions accumulate. If you've already processed transactions in your new system, you'll need to validate the migrated data as of the cutoff date by excluding all activity after that date when generating comparison reports. Any corrections to migrated data will require careful journal entries that don't disturb your post-migration activity, and you may need to restate your first period's financials if corrections are material. This is why validation withinundefinedhours of migration, before new activity begins, is the recommended best practice.

What should I do if my new and old system balances do not match?

First, confirm you're comparing the same date range and that both reports use the same accounting basis (cash vs. accrual). Next, identify which specific accounts show discrepancies by comparing trial balances line by line. For each variance, drill into the account detail to compare transaction counts and totals. Common culprits include transactions that didn't migrate, duplicate transactions, account mapping errors where similar account names caused incorrect assignments, and opening balance discrepancies. Document each variance in a spreadsheet, categorize by likely cause, and address systematic issues (like mapping problems) before correcting individual transaction errors.

Do I need to validate every single transaction individually?

No, validating every transaction is neither practical nor necessary for most migrations. Use a layered approach: first validate that aggregate balances match through trial balance comparison, then validate that major report totals match through financial statement reconciliation, then spot-check a representative sample of 20-50 individual transactions across different types and date ranges. Focus detailed transaction review on high-risk categories like open invoices and bills, multi-currency transactions, and any accounts where the balance-level comparison showed discrepancies. Statistical sampling theory supports that examining 30-50 representative transactions provides high confidence in overall data integrity when balance-level validation has already confirmed no systematic errors.

How far back should historical data validation go?

At minimum, validate all data within your current fiscal year plus any open prior-year transactions (unpaid invoices, unapplied credits, open purchase orders). Most businesses also validate one complete prior fiscal year to ensure comparative reporting works correctly. The practical validation depth depends on your reporting needs and audit requirements—if you regularly run three-year trend reports or if auditors will examine the prior year, validate that full period. Transaction detail older than two years typically receives lighter validation (balance verification only) unless your industry has specific retention and reporting requirements, as detailed in guidance from the National Archives and Records Administration regarding financial record retention periods.

Validating your books after an accounting migration isn't optional overhead—it's the quality control gate that prevents data errors from poisoning months of future financial reporting. The 8-12 hours invested in systematic validation withinundefinedhours of migration saves dozens of hours remediating errors discovered weeks later, after they've already contaminated multiple accounting periods. Approach validation with the same rigor you'd apply to any financial control, document your findings thoroughly, and don't resume normal operations until you've confirmed your new system accurately reflects your business's financial reality.