How to switch accounting software

When switching is worth it — and when it is not

Good reasons: the current system genuinely cannot do something you need — multi-currency, proper inventory, the integration your business depends on — or it is being discontinued, or your accountant cannot work in it effectively, or the cost has risen beyond what the value justifies.

Weaker reasons: the interface is dated, or a competitor markets harder, or someone read that another system is more modern. Migration has a real cost in time, risk and disruption, and the most common regret is switching for a feature that turns out to be a small part of the actual day-to-day.

Whatever the reason, be specific about what will be better afterwards, and check that the new system can genuinely do it with your data — including how it imports bank transactions, since that determines the shape of the migration. Our QuickBooks and Xero pages cover what each accepts, and there are equivalent notes for Sage, DATEV and others.

Choosing the cutover date

The cutover date is the single most consequential decision in the project, because everything else is defined relative to it.

Before fixing the date, check one practical thing that migrations routinely miss: when can bank feeds start in the new system? If the feed can only be connected from the day you sign up, then every day between your cutover date and that connection is a gap you will import from statements — and a cutover three months before go-live means three months of PDF conversion nobody budgeted for.

How much history to bring

The instinct is "everything". The right answer is almost always less, chosen deliberately.

Two things make less history safer than it feels. Keeping the old system accessible in read-only form — or a full export of it — answers historical questions perfectly well. And the statements themselves remain the primary record of what happened, which is why the document store matters more than the ledger for anything genuinely old.

Whatever you choose, write it down and tell everyone. The most common source of migration frustration is a person expecting to find three-year-old detail in a system that was deliberately given one year.

Mapping the chart of accounts

A migration is the one moment when rationalising the chart of accounts is cheap, and skipping it means carrying every historical compromise into the next decade.

Export the old chart with balances and usage. Then, for each account, decide: keep it, merge it into another, or retire it. Accounts with no activity in two years are candidates for retirement; the four near-identical "software", "subscriptions", "IT" and "tools" codes are candidates for merging. Reporting improves immediately when categories are distinguishable.

Then map old to new explicitly in a spreadsheet — old code, old name, new code, new name, decision — and keep that mapping. It is the document you will need when a figure in the new system does not match the old one, and it is the first thing anyone reviewing the migration will ask for. A cleaner chart also makes automated categorisation more reliable afterwards, which is covered in categorising transactions.

Opening balances — where migrations go wrong

Take the trial balance from the old system at the cutover date and post it into the new one as a journal. Most systems provide a conversion or suspense account to absorb the difference while you are part-way through entering everything; when that account reaches zero, the balances agree.

Then do the step that separates a good migration from a bad one: reconcile every bank and card account to the actual statement balance on the cutover date. Not the ledger balance — the bank's. If the two differ, something in the old system was already wrong, and migrating it forward buries the problem under new activity where it becomes much harder to find.

Watch three items specifically: uncleared payments and receipts at the cutover date, which must carry across as reconciling items; accruals and prepayments, which need to exist in the new system so they reverse when they should; and any suspense balance, which should have been cleared during cleanup rather than migrated.

flowparse.io

Open invoices and unpaid bills

Open items have to move as individual documents, not as a total. If a customer owes three invoices, the new system needs all three with their own dates, references and amounts — otherwise the first part-payment cannot be matched and the chasing conversation becomes embarrassing.

Enter each unpaid sales invoice and each unpaid supplier bill with its original date so ageing is correct from day one. Then agree the totals to the aged listings from the old system, line by line for material balances. Two numbers must match exactly: total receivables and total payables.

This is also the moment to write off what is genuinely dead. A debtor from three years ago that nobody expects to collect should be dealt with before migration, not carried into a fresh system where it will sit in the ageing forever, quietly overstating what the business is owed.

Bank data and the feed gap

Here is the task that surprises people. A bank feed in the new system starts when you connect it. It does not go back and fetch the months before, or if it does, only a short window that varies by bank and provider.

So the timeline usually looks like this: cutover on 1 January, new system set up during January, feeds connected in early February. The bank transactions for January — and any part of February before the feed caught up — exist nowhere in the new system, and the business still needs them for reconciliation, VAT and reporting.

Plan the gap explicitly: list every account, the cutover date, the date its feed genuinely starts delivering, and therefore the exact period you must import from statements. Doing that at the start turns a nasty surprise into a scheduled task.

flowparse.io

Converting the historical statements

For the gap period — and for whatever history you decided to bring — the source is statements, and the job is turning them into the file the new system imports.

Download statements for every account covering the full period, including accounts with no feed at all and any closed mid-migration. Convert them into transactions rather than retyping: statement conversion produces QBO or OFX for QuickBooks-family imports, a Xero statement CSV, a DATEV booking file, or plain Excel when you want to review before importing.

Insist on two properties. Completeness: each statement's extracted transactions must reconcile to its own opening and closing balance, because a migration built on a listing that quietly lost four rows produces a bank reconciliation that will never tie. That check runs automatically per account and names the failing rows. And no duplicates: import one period at a time, check the date range before each import, and never import a period the feed has already delivered.

If you are bringing a full year across several accounts, consolidating them first makes the checking far easier — unified columns, duplicate detection across overlapping periods, and a source-file reference on every row so any figure can be traced back to the statement it came from.

flowparse.io

Sub-ledgers, registers and the things people forget

Beyond the general ledger sit several registers that each need a decision, and forgetting one is how a migration ends up half-finished.

• Fixed-asset register — assets, cost, accumulated depreciation and remaining life, so depreciation continues correctly.
• Inventory — quantities and valuation basis at the cutover date, agreed to a count wherever possible.
• Payroll — either migrate mid-year figures properly or start the new system at a tax-year boundary; mixing the two is painful.
• Recurring transactions — standing journals, repeating invoices and templates have to be rebuilt, not migrated.
• Customer and supplier records — with tax numbers, payment terms and bank details verified rather than assumed.
• Loans and finance leases — outstanding balance, rate and schedule so interest splits stay correct.

Supplier bank details deserve a special note. A migration is a moment when payment details get re-entered in bulk, which is exactly the condition fraudsters look for — verify changes through a known channel rather than from an email that arrives helpfully during the project.

Integrations, documents and the surrounding stack

The ledger rarely stands alone. Capture tools, payment processors, e-commerce platforms, payroll, expense apps and reporting tools all connect to it, and each connection has to be re-established and re-tested.

Make a list before go-live: what connects, what it does, who owns it, and what breaks if it stops for a week. Then reconnect in order of importance and verify each one with a real transaction rather than assuming the connection status is truth.

Documents are the part most often lost. Some systems export attachments in bulk and some do not; where they do not, export what you can into a folder structure organised by year and reference, and keep the old system readable for as long as your retention rules require. Extraction tools do not help here — FlowParse deletes originals after processing and is not an archive — so this is a storage decision, covered further in the audit guide.

The parallel run

Running both systems for one full period is the cheapest insurance available, and the reason is simple: differences are easy to explain while both systems are live and nearly impossible to explain after one is switched off.

In practice you enter the period's activity in both, close both, and compare. Any difference is either a migration error, a configuration difference or a genuine improvement — and all three are worth knowing about before you rely on the new numbers.

If a full parallel run is not realistic, do a reduced version: reconcile the first closed period in the new system back to what the old one would have produced for the same transactions. It costs a day and it catches the errors that would otherwise be found at year-end.

The parity check

That last row catches the failure this whole guide keeps circling: a listing that lost rows. Totals can coincidentally agree while a handful of transactions are missing and offsetting; counts do not lie, and a count mismatch tells you exactly where to look.

Go-live week

Pick a quiet week if the business has a rhythm — not the week of a VAT deadline, a payroll run and a board meeting. Tell everyone who touches the system what changes and when, including the people outside finance who raise invoices or submit expenses.

Freeze the old system to read-only on the agreed date so nothing new is posted into it by habit. Then, for the first week, check the things that quietly break: bank feeds actually delivering, invoices numbering from the right sequence, tax rates applying correctly, integrations firing, and documents attaching where they should.

Expect a bumpy fortnight regardless of preparation. The measure of a good migration is not the absence of issues but that every issue is small, visible and quickly explained — which is what the parity check bought you.

flowparse.io

Retiring the old system properly

Do not cancel the old subscription the day after go-live. Keep it readable long enough to answer the questions that will arrive over the following months, and take a full export before access ends — general ledger, trial balances, aged listings, invoice and payment detail, and attachments if they can be extracted at all.

Store that export where it can actually be found in three years, organised by entity and year, and check that the files open before you rely on them. An export in a format nothing can read is the same as no export, and that discovery is always made at the worst possible moment.

Then confirm your retention obligation for the underlying records and make sure the source documents — statements, invoices, contracts — are retained accordingly. That obligation follows the business, not the software.

Migrating clients as a practice

A firm moving many clients has a different problem: repetition. The answer is a standard runbook — the same sequence, the same checks, the same evidence pack per client — so nobody re-invents the process on the eleventh migration.

Batch the mechanical parts. Historical statement conversion is the biggest of them, and doing every client's statements in one sitting is far faster than context-switching per client; batch processing and the accountants' workflow cover how firms arrange it.

And sequence clients by difficulty rather than by size. Migrate two straightforward ones first to prove the runbook, then the messy ones with the runbook already tested — the reverse order is how a practice discovers a process problem on its most complicated client.

A worked example: a 1 January cutover

A ten-person services company moves from a desktop package to a cloud ledger, cutting over at the start of the financial year. Two bank accounts, one company card, one payment processor, about forty open sales invoices and twenty unpaid supplier bills.

November.The decision is made and the scope written down: balances plus the new year, with the prior year kept in the old system read-only. They check when feeds can be connected in the new ledger and discover the answer is "from the day the account is opened" — so January will have to be imported from statements. That single check reshapes the plan.

December. Cleanup. Every account is reconciled, a two-year-old suspense balance is investigated and cleared, six dead debtors are written off, and the chart of accounts drops from ninety-one codes to sixty-three by merging near-duplicates. This is the phase that later makes everything else easy.

Early January. The new ledger is configured, accounts mapped from the spreadsheet built in December, and the trial balance at 31 December posted as opening balances. Both bank accounts are then reconciled to the actual statement balance on that date — one is out by a payment that had not cleared, which is recorded as a reconciling item rather than adjusted away. Open invoices and bills are entered individually; the aged listings agree with the old system to the penny.

Late January.Feeds go live on the 22nd. The gap — 1 to 21 January across three accounts — is downloaded as statements, converted, checked against each statement's own closing balance and imported one account at a time. Because the feed already delivered from the 22nd, they check the date range of every import before running it, and no duplicates appear.

February. January is closed in the new system and compared with what the old one would have produced. Trial balance, bank balances, aged listings and transaction counts all agree. The old subscription is kept for six months, a full export is taken and stored, and the migration is declared done — three weeks of elapsed time and perhaps four days of actual work, most of it in December.

A realistic timeline

The cleanup row is the one that varies most, and it is the best predictor of the whole project. A business whose accounts are reconciled monthly migrates quickly; one with unexplained balances spends most of the project resolving them — which is work that had to happen anyway and merely became visible.

Common mistakes

Frequently asked questions

Keep reading