How to Check a Xero Migration: A Complete Validation & Reconciliation Guide

A Xero migration is not validated because the data imported successfully. The real question is whether the new Xero organisation contains the history you agreed to migrate, whether the important balances reconcile back to the source system, and whether any differences can be explained.

That distinction matters. A migration can look perfectly normal on screen while still containing missing transactions, duplicated entries, incorrect mappings, broken allocations, VAT differences, foreign-currency issues or artificial journals added simply to make a Trial Balance agree.

At Migrate My Accounts, reconciliation is part of the migration itself. We compare the destination back to the source, investigate differences and document material exceptions rather than treating a successful import as proof that the accounting history is correct.

This guide explains the checks we consider useful when validating a historical migration to Xero. The exact process will vary by source system and scope, but the principles apply whether you are moving from Sage 200, Access Dimensions, Business Central, Exchequer or another accounting platform.

1. What migration validation actually means

Validation is the process of proving that the agreed accounting information has reached Xero in a form that is complete, internally coherent and traceable back to the source records. It is not a single report and it is not the same as asking whether the closing Trial Balance agrees.

A strong validation process answers several different questions: Did all agreed periods arrive? Are the balances right at meaningful dates, not only at the final cut-off? Are customer and supplier balances supported by the underlying invoices, credits and payments? Are VAT values represented appropriately? Were departments or cost centres mapped as agreed? Can unusual differences be traced to a known source-system issue or an agreed transformation?

This is why our professional Xero migration process treats reconciliation and exception reporting as deliverables, not optional checks after the import.

2. Before you compare the two systems

Before running reports, make sure you are comparing like with like. Many apparent migration errors are actually comparison errors.

• Use the same cut-off date. A source report run to 31 August cannot be compared meaningfully with Xero after September transactions have been posted.
• Confirm the same basis and filters. Check date ranges, status filters, currencies, reporting basis and whether year-end or adjustment periods are included.
• Freeze or control movement during testing. If users continue posting into one system while validation is taking place, keep a clear cut-off so new activity is not mistaken for a migration difference.
• Keep the source evidence. Export the reports and ledgers used for reconciliation. A report that changes later is poor evidence of what was validated at handover.

It is also worth establishing whether the source system itself reconciles before assuming it is a perfect benchmark. We regularly encounter legacy records with pre-existing inconsistencies. Our guide to accounting data errors before a Xero migration explains why a migration should not silently rewrite those problems.

3. Trial Balance reconciliation: necessary, but not enough

The Trial Balance is normally the first major control because it tests the overall nominal position. We compare source balances with Xero at the agreed migration dates and investigate account-level differences.

For a multi-year historical migration, we prefer not to rely only on the final closing Trial Balance. A final balance can agree even when transactions were posted into the wrong historical period and later reversed or corrected. Comparing meaningful period ends helps expose timing and mapping issues that a single end-point comparison can hide.

Where the Chart of Accounts has been restructured, the comparison needs to reflect the agreed mapping. Five legacy nominal codes may deliberately become one Xero account, or one old code may be separated according to a new reporting structure. In that situation, reconciliation is not simply old code versus identical new code; it is source balance versus the agreed mapped destination.

4. General Ledger and transaction-level checks

For complex migrations, the General Ledger is where much of the real detective work happens. One method we use is to compare source GL activity by nominal account and transaction date with Xero account transactions. This can reveal missing activity, duplicates, dummy journals, unexpected codes and transactions that have landed in a different period.

Useful tests include comparing transaction counts and values by month, checking high-value or unusual entries, reviewing journal populations, tracing a sample of source references into Xero, and investigating accounts whose movement differs even when the closing balance happens to agree.

Sampling alone is not enough for every project, but it is extremely useful alongside full control reconciliations. A good sample should include ordinary transactions and awkward ones: credit notes, part payments, foreign-currency invoices, old outstanding items, journals, refunds and transactions around VAT or year-end boundaries.

5. Aged Receivables and Payables

If sales and purchase history is included, the aged ledgers deserve their own reconciliation. The nominal debtors or creditors control balance can agree while the underlying customer or supplier position is wrong.

We look at whether the outstanding invoices and credits are present, whether payments have been allocated correctly, whether old items remain open when they should be settled, and whether the total aged balance relates sensibly to the relevant control position.

Timing matters here too. Run the source and Xero aged reports to the same date and understand how each system treats future-dated transactions, allocations and currency conversions. Differences in report logic can create apparent discrepancies even where the migrated transactions are present.

6. VAT and tax validation

VAT is one of the areas where a superficially correct migration can still create problems later. We do not assume that a matching gross transaction value means the VAT history is correct.

Depending on scope and source data, validation may include tax rates, net/tax/gross values, VAT control balances, transactions included in previously filed periods, late claims or late sales, and the position that will feed into the first live Xero VAT return.

Historical VAT returns themselves do not simply recreate in Xero as filed submissions. That is why it is important to distinguish between migrating the underlying transaction history and recreating the old filing record. We explain this in more detail in what happens to historical VAT and GST returns when moving to Xero.

The first live VAT return after migration deserves particular care because it is often the point where historical late transactions and the new live period meet. Where VAT treatment is uncertain or requires tax advice, the accountant or VAT adviser should confirm the accounting treatment rather than the migration provider making an unsupported tax decision.

7. Bank and control-account checks

Bank accounts are another useful control point. The migrated accounting balance should be compared at the cut-off, but it should not be confused with a live bank-feed balance or the bank statement balance unless the comparison is intentionally designed that way.

Control accounts need additional care because different accounting systems allow different posting behaviour. Some legacy systems permit direct journals to debtors, creditors or VAT controls that Xero restricts. If the old system contains those postings, the migration may require an agreed treatment rather than an artificial entry hidden purely to force a match.

The objective is not a pretty reconciliation at any cost. It is an explainable one.

8. Foreign currency and exchange-rate differences

Foreign currency can produce legitimate differences even when the underlying transactions have migrated correctly. Source systems and Xero may use different exchange-rate precision, revaluation methods, reporting dates or historical rate behaviour.

Validation should therefore separate the original transaction currency from the base-currency accounting effect. Check that the transaction currency, foreign amount and relevant source rate or agreed migration rate are represented correctly, then investigate base-currency or revaluation differences separately.

We have seen legacy data where GBP transactions carried exchange rates greater than 1, manual revaluations had been posted historically, or different rates were used across related entries. Forcing Xero to imitate every legacy-system calculation can create a worse accounting trail than documenting the genuine system difference.

9. Allocations, contacts, tracking and structure

Numbers can reconcile while the new system is still frustrating to use. Validation should therefore include the structure that users will depend on after go-live.

• Allocations: Are customer and supplier payments connected to the correct invoices and credits?
• Contacts: Were customers and suppliers mapped or merged as agreed, with source references retained where useful?
• Tracking: Did departments, cost centres or other analysis dimensions land in the agreed Xero Tracking structure?
• Chart of Accounts: Does the new structure match the signed-off mapping rather than merely reproducing every legacy code?
• Attachments: If historical documents were in scope, can a sample be opened from the correct Xero transaction?

Where a migration also involves redesigning reporting, our Xero data restructuring guidance explains why the mapping itself needs to be agreed before validation can be meaningful.

10. How to treat legitimate differences

Not every difference is a migration error. That is one of the most important principles in reconciliation.

A difference might come from a source-system defect, deleted or amended historical data, rounding, FX behaviour, a mapping decision, a Xero restriction, an accounting-period difference, or an intentional cleanup agreed with the client. The correct response is to identify the cause and record the treatment.

We strongly prefer an exception that says what differs, by how much and why over an unexplained journal created solely to make two totals equal. If an accounting adjustment is required, it should be deliberate and approved by the appropriate person.

11. What a useful reconciliation pack should show

A reconciliation pack does not need to be enormous. It needs to make the migration defensible and understandable.

Depending on the project, useful evidence can include the source and Xero Trial Balance comparisons, aged Receivables and Payables, mapping schedules, VAT checks, key control-account comparisons, transaction-level working files, exception notes and evidence of agreed treatments.

For a larger group migration, we also want a clear entity-by-entity status so that one completed company cannot mask another that still has unresolved items. This becomes particularly important in group and multi-entity Xero migrations, where consistent mapping and reconciliation across companies matter as much as the individual entity checks.

The pack should answer a future question: if somebody reviews this migration months later, can they understand how the Xero opening and historical position relates to the old system?

12. What to do if the migration does not reconcile

Do not immediately start posting manual journals until the cause is understood. An adjustment can hide the symptom and make the original problem harder to trace.

Start by isolating the difference: which account, period, transaction type, customer, supplier or currency is affected? Then determine whether the issue exists in the source, was introduced during transformation, occurred during import, or is caused by different reporting logic in Xero.

If you inherited a migration completed by someone else, preserve the evidence before making changes. Export reports, retain the migration workings if available and document what is currently wrong. Our guide to fixing a failed Xero migration versus migrating again explains how we approach the repair-or-remigrate decision.

Frequently asked questions

How do I know if my Xero migration was successful?

A successful migration should contain the agreed data, reconcile to the source at the agreed control points and have any material differences explained. A matching closing Trial Balance alone is useful evidence, but it is not sufficient proof that transaction history, aged ledgers, VAT, allocations and reporting structure are correct.

Should every figure in Xero exactly match the old accounting system?

Many key figures should reconcile exactly, but not every difference automatically indicates an error. FX, rounding, reporting logic, source-data problems, restructuring and system restrictions can create legitimate differences. Those differences should be investigated and documented.

Should I check every transaction?

The answer depends on the size, risk and scope of the migration. Full control reconciliations can be combined with transaction-level comparisons and targeted sampling. For complex migrations, automated or structured GL comparisons can test populations far more effectively than manually opening a handful of invoices.

When should validation happen?

Validation should happen before the migrated Xero organisation becomes the unquestioned live record. Ideally, source reports are retained at the agreed cut-off and reconciliation is completed before handover or before significant live posting makes comparison harder.

Can Migrate My Accounts validate a migration completed by somebody else?

Yes, depending on the available source data and access. Our post-migration support and migration-rescue work can include investigating discrepancies, comparing legacy and Xero records and identifying what needs correction. The quality of the conclusion will depend on what source reports, exports and migration workings are still available.

Final thought: reconciliation is what turns an import into a migration

Moving accounting data is only one part of the job. The more important question is whether the new system can be trusted.

For us, that means being able to trace the historical position back to the source, explain known differences and hand over evidence that makes sense to the finance team. Sometimes validation confirms that everything has transferred exactly as planned. Sometimes it uncovers a problem in the migration. And sometimes it exposes an issue that already existed in the old accounting system.

All three outcomes are useful—provided they are understood.