Accounting Data Errors Before Xero Migration: What Happens If Your Data Is Wrong?
Accounting data errors before Xero migration aren’t always obvious. In fact, one assumption we regularly encounter at the start of a migration is that the accounting system we’re leaving must be the correct benchmark.
Usually, it is.
But not always.
We’ve worked on historical migrations where the source Trial Balance contains inconsistencies, foreign currency balances don’t behave as expected, aged debtors or creditors don’t reconcile cleanly, or transactions have been posted in ways that cannot be replicated directly in Xero.
That creates an important question:
Should the migration reproduce the old system exactly, including its problems, or should those problems be corrected before the data reaches Xero?
A migration should not silently “fix” your accounts
Our starting position is that a migration should preserve the client’s accounting records, not rewrite them.
If £100,000 exists against an account in the source system, we don’t independently decide that the balance should actually be £99,500 and change it during migration.
Doing so would make it extremely difficult to reconcile the two systems and could alter previously reported financial information.
Instead, when we identify something unusual, we investigate it and raise it with the client.
The important part isn’t simply making the difference disappear. It’s understanding why the difference exists in the first place.
Sometimes the source data cannot be reproduced exactly in Xero
Legacy accounting systems can allow accounting treatments that Xero does not.
A simple example is control accounts.
Some legacy systems allow direct journals or unusual postings against debtors, creditors or VAT control accounts. Xero deliberately restricts certain postings to these accounts.
So occasionally we face a choice.
We could create additional nominal accounts or journals purely to make Xero reproduce the legacy Trial Balance.
Technically, that may make the numbers match.
But it can also carry an unexplained historical difference into a brand-new system.
Where possible, we’d rather understand the underlying issue and agree the appropriate treatment with the client.
A real example
During a recent migration, we identified balances in the source system that could not be recreated in Xero without introducing additional nominal codes and manual journals.
It would have been possible to create those entries simply to force the Xero Trial Balance to match the legacy system.
Instead, we raised the issue with the client, explained why the difference existed and discussed the available options.
Sometimes the technically easiest solution isn’t necessarily the cleanest migration solution.
Foreign currency creates another layer
We’ve also encountered legacy data where multiple exchange rates have been used across transactions in ways that don’t translate perfectly into Xero.
Xero has its own foreign currency and revaluation behaviour.
That means a difference isn’t automatically evidence that the migration is wrong.
The important question is:
Why does the difference exist?
We investigate whether it comes from the migrated transaction, exchange-rate precision, revaluation behaviour, historical postings or the source accounting system itself.
Only then can the appropriate treatment be agreed.
This is particularly important with historical migrations because two accounting systems can contain the same underlying transactions while calculating subsequent foreign currency values differently.
Trying to force one system to behave exactly like another can sometimes create more problems than it solves.
This is why pre-migration reconciliation matters
Before processing historical data, we want to understand the condition of the source records.
Depending on the migration, this may include reviewing:
- Trial Balance
- Aged Receivables
- Aged Payables
- VAT balances and returns
- Bank balances
- Foreign currency balances
- Control accounts
- Suspense or unusual nominal balances
We’re not auditing the client’s accounts or determining the correct accounting treatment.
We’re establishing whether the information we’re expected to reproduce actually reconciles and identifying differences that may need to be reviewed with the client or their accountant.
Finding these issues before or during migration gives everyone the opportunity to understand them before the new accounting system becomes the live system.
Fix before migration or replicate and correct afterwards?
There isn’t one answer.
If the source system can still be corrected safely, correcting the problem there can provide the cleanest audit trail.
If historical periods are locked or previously reported accounts shouldn’t be changed, another treatment may be more appropriate.
Sometimes an adjustment in Xero is required.
And occasionally we need to reproduce an unusual historical position simply so the two systems reconcile.
The important part is that the decision is deliberate, documented and understood.
We don’t want to introduce unexplained adjustments simply to make a reconciliation report look perfect.
We want the client to understand what has been migrated, what is different and why.
Migration is sometimes the first time anyone looks this closely
Changing accounting software forces businesses to examine years of financial history in a way they may not have done for a long time.
That’s why migration projects sometimes uncover problems that have nothing to do with the migration itself.
A discrepancy discovered during migration doesn’t necessarily mean something went wrong.
Sometimes the migration is simply what found it.
At Migrate My Accounts, our objective isn’t to make differences disappear.
It’s to understand them, explain them and help the client decide how they should be treated before relying on the new system.
Frequently Asked Questions
Can you migrate accounting data if the Trial Balance doesn’t reconcile?
Potentially, yes, but the cause of the difference should ideally be understood before migration.
Depending on the issue, we may recommend correcting the source data first or agreeing how the difference should be treated in Xero.
The important thing is that known discrepancies aren’t simply carried into the new system without explanation.
Will you correct errors you find in our accounting data before Xero migration?
We don’t independently change historical accounting records.
We identify and explain migration-related differences and agree the appropriate approach with the client.
Where an accounting decision is required, this should be confirmed by the client or their accountant.
Does Xero treat historical transactions differently from legacy accounting systems?
Sometimes.
Different accounting systems can have different rules and functionality around control accounts, foreign currency, rounding, VAT, accounting periods and other accounting treatments.
Part of the migration process is understanding how those differences affect the historical data and determining how they should be represented in Xero.
Should I clean my accounting data errors before our Xero migration ?
Where possible, yes.
Resolving known reconciliation issues, reviewing old contacts and confirming unusual balances before migration generally creates a cleaner starting point and can reduce unnecessary investigation during the project.
However, you don’t necessarily need to make your data “perfect” before speaking to a migration specialist. Part of the initial migration review is understanding the condition of the existing data and identifying potential issues before the migration begins.
Planning a historical migration to Xero?
If you’re considering moving to Xero and are unsure about the quality of your existing accounting data, identifying potential issues before migration can make the transition considerably smoother.
At Migrate My Accounts, we specialise in historical accounting data migrations, including complex migrations involving foreign currencies, historical transactions, allocations and multi-entity structures.
