Accounting records when changing software

Changing accounting software should preserve the evidence behind balances and transactions. Choose a cutover date and decide which history will migrate and which will be retained separately. A successful import message does not prove that the new ledger is complete or correct.

Reconcile bank, customer, supplier, tax and loan balances before and after migration. Check currencies, tax codes, invoice numbering and attachment access. Keep the old system or readable exports available for the required retention period without relying on a subscription that may be cancelled unexpectedly.

Define the migration scope and cut-off

Identify the company, currencies, accounting dates and records moving to the new system. Decide whether the migration includes full transaction history or opening balances with retained legacy access. Include invoices, attachments, reconciliations, audit history and tax data where relevant. A feature called import accounts may cover only the chart of accounts, not the evidence needed to explain historic entries.

Choose a cut-off date and allocate responsibility for transactions around it. Keep the old system stable while exports are prepared, or record later changes for controlled transfer. Without a clear boundary, staff may enter the same supplier bill in both systems or omit a payment because each team assumes the other recorded it. Communicate the process to everyone who submits or approves financial records.

Map accounts and preserve the underlying meaning

Create a mapping from old codes to new categories and review material differences with the accountant. Do not merge unlike balances merely to fit a simpler chart. Separate director accounts, taxes, deposits and loans as needed. Keep the mapping so later comparisons can explain why a category changed rather than suggesting the business's underlying activity suddenly moved.

Check dates, currency, tax codes and customer or supplier references during import. A successful technical upload does not prove the financial meaning is correct. Test representative transactions, including credits, partial payments and foreign currency items. GOV.UK's company record guidance provides the continuing record responsibility regardless of the software used. ^[1]

Reconcile opening balances and selected history

Compare the new trial balance with the agreed closing position and explain every difference. Reconcile bank balances, debtors, creditors, fixed assets and relevant control accounts. Matching the overall total is insufficient if two errors offset. Inspect the underlying customer and supplier schedules so a balanced ledger does not conceal invoices assigned to the wrong account or duplicated opening entries.

Use Reconciling a business bank account for bank checks and Keeping a fixed asset register for asset schedules. Confirm that final year-end adjustments have been included if the migration follows accounts preparation. Preserve the approved source version and reconciliation report. If the old system continues receiving bank feeds or invoices during transition, ensure the agreed process captures those changes exactly once.

Protect access, evidence and the exit from the old service

Review user permissions and connected applications in the new platform before live use. Transfer administrator control appropriately and avoid sharing one login across staff and advisers. Check backup, export and retention options. A new interface may change who can see payroll or client information, so migration is also an access-control decision rather than only a bookkeeping exercise.

Do not cancel the old subscription until required records are exported, readable and securely retained. Use Keeping records after a company closes for the wider custody principles where access is ending. Confirm what happens to attachments and reports unavailable through the standard export. Record unresolved gaps and the agreed recovery route instead of assuming a provider will retain convenient access indefinitely after cancellation.

For Limited company bookkeeping, provide the migration plan, account mapping and test reconciliation. Agree who validates accounting treatment and who performs the technical import. Before using the new reports for decisions or returns, resolve material differences and obtain appropriate review. Keep a short post-migration check for feeds, invoice numbering and tax codes, then close temporary duplicate processes so staff do not continue maintaining conflicting versions of the company's books.

Test corrections made after migration

Choose a transaction imported from the old system and establish how a later correction would be recorded. Check whether users should amend the imported entry, post a separate adjustment or retain the historical record with an explanation. The appropriate method depends on the migration design and the records needed for reliable reporting.

Document the agreed approach before staff begin working around restrictions. Keep transaction identifiers or a mapping that connects the new record to the original evidence. Where only opening balances were migrated, make sure the archive remains searchable for the underlying detail. This prevents the business from creating a clean-looking new ledger while losing the ability to explain or correct the transactions that produced its opening position.

Illustrative scenario

A company imports customer opening balances but also imports the same unpaid invoices as new transactions. Receivables are doubled. A migration reconciliation against the old aged debt report exposes the issue before the new system is used for collection letters or management reporting.

Preparation checklist

• Agree the cutover date and migration scope.
• Reconcile control balances before and after import.
• Check attachments, audit history and readable exports.
• Limit duplicate entry and document the final cutover approval.