What Happens to Historical VAT and GST Returns When Moving to Xero?

If you’re moving years of accounting history into Xero, one question that often gets overlooked until quite late in the migration is: What happens to all the historical VAT or GST returns we’ve already filed?

The short answer is that migrating historical transactions into Xero is not the same as recreating every historical VAT or GST return exactly as it was originally filed.

Your invoices, bills, credit notes, payments, tax amounts and other accounting history may all be migrated into Xero. But previously submitted VAT or GST returns belong to the history of the old accounting system and the relevant tax authority.

And this distinction matters.

We’ve worked on Xero migrations where historical VAT reconciled beautifully from the start.

We’ve also worked on migrations where VAT was one of the most complicated parts of the entire project.

The important thing is understanding why.

Historical transactions and historical VAT and GST returns in Xero are not the same thing

During a full historical Xero migration, we may recreate several years of transactions.

Depending on the project, that can include:

• sales invoices and credit notes
• purchase invoices and credit notes
• payments and allocations
• journals
• tax codes and tax amounts
• foreign currency transactions
• bank transactions
• historical nominal balances

Where VAT or GST applies, we normally want the migrated transaction to preserve the relevant tax treatment as accurately as possible.

However, this doesn’t automatically mean that Xero will recreate the exact historical VAT or GST return that was originally submitted from Sage, Access, Dynamics, another ERP or another accounting system.

That’s because a filed tax return represents what was reported at a particular point in time.

The accounting data you are migrating today may no longer represent exactly what existed on the day that return was filed.

That is a surprisingly important distinction.

Why can historical VAT and GST returns in Xero be different after migration?

We’ve encountered this during real historical migration projects.

A VAT return may have been submitted months or years ago, but transactions in the source accounting system may subsequently have been:

• edited
• deleted
• reposted
• moved into another period
• adjusted through journals
• assigned a different tax treatment

There can also be historical postings directly affecting VAT control accounts or accounting treatments that Xero handles differently.

So when we recreate today’s historical accounting records in Xero, we are recreating the current version of that accounting history.

That isn’t necessarily identical to the dataset that existed when a particular VAT return was originally submitted.

This is why a difference in historical VAT does not automatically mean that something has gone wrong with the migration.

It needs to be investigated.

A real example: when transaction dates affect the next VAT return

One issue we’ve encountered during migration work is transactions that sit within one accounting period in the source data but need to be represented differently when recreated in Xero.

Changing the accounting date doesn’t necessarily change the fact that the VAT relating to that transaction was already included in a previous VAT return.

That creates a situation where the accounting history can be correct, but Xero may identify VAT associated with a previous period when preparing the next return.

In situations like this, we don’t simply ignore the difference.

We identify the transactions causing it, establish what was historically reported and agree the appropriate accounting treatment with the client or their accountant.

Sometimes an adjustment is required.

The important part is that the difference is understood and documented, rather than hidden simply to make a reconciliation appear correct.

Xero can identify changes relating to previous VAT periods

This is particularly relevant in the UK.

Xero explains that its MTD VAT return can include transactions relating to earlier periods where the relevant VAT return has already been filed.

Xero refers to these as late claims.

They can arise not only from newly entered transactions, but also when transactions from previously filed periods are subsequently edited, voided or deleted.

This becomes particularly important during a historical migration because, from Xero’s perspective, large amounts of historical accounting data may effectively be arriving in a new accounting system for the first time.

That is one reason we pay particular attention to the first live VAT return following a migration.

What happens to the VAT control account?

The VAT or GST control account is another area we reconcile carefully.

In an ideal migration, several things tell the same story:

historical transactions → tax reporting → VAT/GST control account → Trial Balance

But legacy accounting systems don’t always contain perfectly tidy histories.

We’ve encountered unusual historical control-account postings and situations where the accounting balance couldn’t simply be reproduced in Xero using the same method as the old system.

Xero also deliberately controls how certain system accounts behave.

In these situations, there can be a temptation to create a journal or additional nominal account simply to force the new Trial Balance to agree.

We don’t think that should be the first response.

First, we want to know:

Why is there a difference?

Is it a migration difference?

Is there a historical adjustment?

Was something changed after a return was submitted?

Is a tax code behaving differently?

Is the source VAT control account itself unusual?

Or is Xero treating the transaction differently from the legacy system?

Only once we understand that can the appropriate treatment be agreed.

Tax codes matter more than they may appear to

A tax code isn’t simply a percentage attached to a transaction.

It can determine how and where a transaction appears on a VAT or GST return.

This becomes especially important when migrating from older accounting or ERP systems containing bespoke, legacy or unusual tax codes.

We’ve encountered this ourselves.

A source system may contain a tax code whose behaviour doesn’t have an obvious one-to-one equivalent in Xero. Recreating the transaction value alone isn’t necessarily enough. We also need to consider how that transaction should behave for tax reporting purposes in Xero.

For complex migrations, tax-code mapping should therefore form part of the migration planning rather than being treated as an afterthought.

What about VAT groups, partial exemption and other complex VAT arrangements?

Not every VAT migration is a straightforward 20% sales and purchase VAT exercise.

Across our migration work, we’ve dealt with businesses where the VAT position involved considerably more complexity, including VAT groups, partial exemption and specialist VAT treatments.

These are exactly the situations where we would be cautious about assuming that an automated data transfer has solved the VAT question simply because all the transactions have appeared in Xero.

The accounting history needs to be considered alongside:

• the VAT scheme
• historical VAT treatment
• tax codes
• control-account balances
• adjustments
• previously submitted returns
• the intended go-live date in Xero

The more complicated the VAT structure, the more important that reconciliation becomes.

What about foreign currency and VAT/GST?

Foreign currency adds another layer.

We’ve worked on historical migrations where exchange rates and foreign currency accounting created differences that weren’t obvious from looking at the transaction value alone.

The source accounting system and Xero may not calculate or represent every element of a historical foreign currency transaction in exactly the same way.

So if a VAT/GST discrepancy involves foreign currency, we may need to look beyond the tax amount itself and investigate the original transaction, source exchange rate, accounting treatment and Xero’s treatment of the transaction.

Again, a difference isn’t automatically a migration error.

The question is why the difference exists.

What happens to GST when moving to Xero?

The same broad migration principle applies in countries that use GST rather than VAT:

Migrating the historical accounting transactions and recreating previously filed GST returns are two different things.

However, the exact GST reporting rules and Xero functionality vary by country.

Australia: GST and BAS

For an Australian business moving historical accounting data into Xero, GST should be considered as part of the migration rather than simply importing gross transaction values.

The GST treatment of migrated sales, purchases, adjustments and other transactions can affect how the accounting history is represented and potentially how subsequent reporting behaves.

The historical migration should therefore be reconciled against the source accounting records, with particular attention paid to the migration cut-off and the first reporting period that will actually be prepared from Xero.

New Zealand: GST

Xero’s New Zealand GST functionality uses the tax rate and tax type applied to transactions to determine how they are reported.

Xero also supports late claims. Once a GST return has been finalised, subsequent changes relating to that previous GST period can be reflected as late claims in a later return.

That makes the treatment of historical transactions particularly relevant when establishing a new Xero organisation containing previous accounting periods.

Singapore: GST

Xero’s Singapore GST functionality calculates GST on transactions and prepares GST F5 returns. It also supports foreign currency transactions, converting relevant amounts into Singapore dollars for GST reporting.

For businesses migrating historical transactions, this makes correct tax treatment and currency handling important parts of the migration design.

Should previously filed historical VAT and GST returns in Xero be recreated in Xero?

Not necessarily.

The objective of a historical migration is generally to create an accurate and usable accounting history in Xero while preserving appropriate evidence of what was previously reported.

That doesn’t mean pretending Xero was the system from which every historical tax return was originally filed.

In many migrations, the original VAT/GST reports and submission records remain part of the records retained from the legacy system.

The key questions are:

Does the migrated accounting history reconcile?

Can we explain the historical VAT/GST position?

Is the VAT/GST control balance correct at the migration cut-off?

And will the first live return from Xero behave as expected?

Those questions are much more important than making an old return in Xero look cosmetically identical to something originally filed from another accounting system.

What should be checked before migrating historical VAT or GST data?

Before starting a historical data migration to Xero, it is worth establishing whether the source accounting records actually reconcile.

This is particularly important for VAT and GST.

Depending on the migration, we may compare the source data against:

• historical VAT or GST reports
• the VAT/GST control account
• the Trial Balance
• sales and purchase tax reports
• previously submitted returns
• known VAT/GST adjustments
• transactions entered or changed after a return was filed
• foreign currency tax balances, where applicable

The aim isn’t to audit the business’s VAT or GST records. It is to establish a reliable position that we can use when reconciling the historical data migrated into Xero.

This matters because a migration can sometimes uncover a problem that already existed in the source accounting system.

We’ve encountered historical accounting data where control accounts contained unusual postings, transactions had been changed after reporting periods were closed, or balances didn’t reconcile in quite the way everyone expected.

In those situations, simply reproducing the difference in Xero isn’t always the right answer.

We’ve written separately about what happens when accounting data is wrong before a Xero migration, because identifying whether a discrepancy comes from the migration or was already present in the source system is an important part of complex historical migration work.

The same principle applies to VAT and GST.

Establishing the position before the migration starts makes it considerably easier to understand any differences that appear afterwards and reduces the risk of carrying an unexplained historical problem into the new Xero organisation.

Why we pay particular attention to the first VAT or GST return after migration

For us, the first live VAT/GST return isn’t just another report.

It is one of the points where the old accounting history meets the new system.

This is where historical transactions, migration cut-off dates, tax codes, previous adjustments and Xero’s own tax-reporting logic can interact.

Depending on the migration, we may therefore review:

• the VAT/GST control account
• transactions appearing in the first return
• previous-period transactions
• late claims or adjustments
• tax-code mapping
• the source VAT/GST reports
• the Trial Balance
• any known historical discrepancies

Finding a difference at this stage isn’t necessarily a problem.

Finding a difference that nobody can explain is.

Don’t just make Xero agree. Understand why it doesn’t.

This is probably one of the biggest lessons we’ve learned from performing complex historical Xero migrations.

When something doesn’t reconcile, it is tempting to focus entirely on making the numbers match.

But a journal that makes a balance disappear doesn’t necessarily solve the underlying problem.

Sometimes the migration has uncovered something that already existed in the source system.

Sometimes Xero handles the accounting differently.

Sometimes historical transactions have changed since a return was filed.

And sometimes there genuinely is something in the migration that needs correcting.

Our job is to establish which one it is.

A historical Xero migration shouldn’t simply move years of data from one database to another.

It should leave you with accounting history that you, your finance team and your accountant can actually understand and rely on.

Planning a historical VAT or GST migration to Xero?

If you’re moving from Sage, Access, Microsoft Dynamics, Business Central, Exchequer or another accounting/ERP system to Xero and need to retain historical VAT or GST data, it is worth considering the tax position before the migration begins.

At Migrate My Accounts, we specialise in historical and complex Xero migrations, including multi-year and multi-entity projects where reconciliation, data restructuring, foreign currency and historical tax treatment need more than a standard automated conversion.

We can review the source data, migration requirements and VAT/GST considerations before agreeing the most appropriate migration approach.

Planning a move to Xero? Get in touch with us to discuss your historical data before you migrate.

Frequently Asked Questions

Can historical VAT returns be migrated to Xero?

The transactions underlying historical VAT periods can be migrated into Xero, including their tax treatment where appropriate. However, this is different from recreating the original filed VAT return itself. The migration approach should consider previously filed periods, VAT control balances and the cut-off for future VAT reporting in Xero.

Can historical GST data be migrated to Xero?

Yes. Historical transactions containing GST can be migrated to Xero, subject to the capabilities of the source system, quality of the available data and the requirements of the destination Xero organisation. Country-specific GST settings and reporting requirements also need to be considered.

Will historical transactions appear on my next Xero VAT return?

They can in certain circumstances. For UK MTD VAT, Xero can identify transactions relating to previously filed periods as late claims. This is one reason the first VAT return after a historical migration should be reviewed carefully.

Why doesn’t my VAT control account match after moving to Xero?

There are several possible reasons, including historical adjustments, direct postings to control accounts, different tax-code behaviour, changed transactions, migration treatment or differences between the legacy system and Xero. The difference should be investigated rather than automatically adjusted away.

What happens to previously filed historical VAT and GST returns in Xero when moving from Sage 200 to Xero?

Previously submitted returns remain part of the business’s historical tax records. A Sage to Xero migration can recreate the underlying accounting transactions and VAT information, but that does not mean every previously filed return should or can simply be recreated as though it had originally been filed from Xero.

Should VAT or GST be reconciled before moving to Xero?

Where possible, yes. Reviewing VAT/GST reports, control accounts and known adjustments before migration provides a much stronger benchmark against which the migrated Xero data can be reconciled.

Should I check the first VAT or GST return after migrating to Xero?

Yes. The first return is an important post-migration checkpoint because historical transactions, previous-period adjustments, tax-code mapping and the migration cut-off can all affect what appears in the new system.

This is also one of several Xero migration risks that should be considered when planning a complex historical migration.