Switching Invoicing Software Mid-Year: What Moves and What Stays
Back to blog
automation·September 11, 2026·4 min read·By Yehonatan Saadia

Switching Invoicing Software Mid-Year: What Moves and What Stays

Changing invoicing systems mid-year needs decisions on numbering, data export and shutting the old system. The order that prevents two series and lost documents.

Key takeaways

  • The single most important thing is one cut-off date: old up to here, new from here.
  • You do not need to migrate history. You need it accessible and readable.
  • The old system stays open for reading and is closed for issuing - not the other way round.
  • Most post-migration problems come from somebody continuing to issue in the old one.

Moving between invoicing systems is not a data import but three decisions: which number to continue from, what moves and what stays in an archive, and exactly when the old system stops issuing. A business that skips one ends up with two numbering series, documents in two places, and an accountant asking questions at year end.

This is an operational description, not advice. Decisions about numbering and how to record are a question for your accountant and the Tax Authority pages.

What actually needs to move?

DataMigrate?Why
Active customersYesYou cannot issue without them
Items and pricesYesSaves typing on every document
Open balancesYesOtherwise collection restarts from zero
Subscriptions and standing ordersYes, carefullyThe most complex part
Document historyUsually notAccessible in an archive is enough
Historical expensesNoThey stay in the old system and in reports already issued
Inactive customersNoImporting them produces a dirty list

The fourth row needs attention: subscriptions are not a record but an authority to charge, and they are tied to the clearing system rather than only to the invoicing system. Full detail in switching payment provider with active subscriptions.

The order of operations

  1. Choose a cut-off date - preferably the start of a month, ideally the start of a quarter.
  2. Export everything from the old system while you are still an active customer, as covered in exporting your data out of invoicing software.
  3. Clean before importing - duplicates, dead customers, old prices.
  4. Decide the numbering with your accountant and record the decision.
  5. Set up and test - issue three test documents and cancel them.
  6. Issue in the new system from the agreed date.
  7. Block issuing in the old one that same day, not a week later.
  8. Check after a month that no documents were issued in both systems.

Step seven fails most often, because it requires telling people to stop using something familiar. Without a technical block, somebody will continue.

What to do with the history

There is no need to move years of documents into the new system. What you do need:

  • A full export of all documents in a readable format, stored in two places.
  • Read access to the old system for as long as it is available.
  • A decision about what happens when the old subscription ends - usually access closes, so the export must come first.
  • A record of where the history lives, so somebody can find it in two years.

The third item is the trap: many businesses cancel the old subscription immediately to save money, and discover they lost access to documents they still need.

What breaks after a migration

  • Two numbering series, because somebody issued in the old system after the cut-off.
  • A balance collected twice, because balances were imported and also entered by hand.
  • A subscription charged twice or not at all, because charge instructions exist in both systems.
  • Duplicate customers, because the import did not recognise two records for the same person.
  • Documents sent from the old system after the move, carrying old branding.

Four of the five are prevented by blocking the old system and one check after a month.

When to move

The start of a year is ideal, because it tidies both numbering and reports. But if the decision lands in September, there is no point waiting - a start-of-month move with good records works fine. What to avoid:

  • Moving in the week of a quarter close.
  • Moving in your peak season.
  • Moving alongside implementing another system.

What to check in the first month

Open the document list after four weeks and ask three questions: are all of this month's documents in the new system; is numbering continuous from the agreed point; and does the debtors report reflect what is genuinely open. The three checks take ten minutes and catch almost every problem while it is still easy to fix.

Who needs to know about the migration

Migrations usually fail because of people rather than data. Four parties need to know in advance:

  • Whoever actually issues documents - they are the ones who will keep using the old system if uninformed.
  • The accountant or bookkeeper - they will receive material from two sources in the transition month.
  • Whoever answers customers - a customer will call about a document that looks different.
  • Whoever maintains the site or store, if there is an automatic document-issuing connection.

The fourth is the forgotten one: a store still sending transactions to the old system will keep producing documents there for two months after everyone else has moved.

What costs more than it looks

In planning a migration, three things take longer than estimated: cleaning the customer list before importing, checking open balances against the old system, and the team's habits. The first is one-off work, the second is an hour, and the third is two weeks of reminders. Anyone planning only the technical part discovers the third along the way.

How to know the migration succeeded

After two months, three signs say the migration genuinely finished: nobody has gone into the old system to issue anything; the debtors report in the new system matches what is actually open; and the accountant has not asked for clarifications about the first month. If any of the three is untrue, the migration is still open - and it is better to close it now than next quarter.

What to write down while it is fresh

During a migration, write one page: the cut-off date, the last document number in the old system and the first in the new one, what was imported and what was not, and where the export of the old system's history lives. That page is what answers every question that arises in the following year, and it takes five minutes on the day - versus an hour of reconstruction later.

Sources

#system migration#invoicing#numbering#export#implementation#אינטגרציה

Frequently asked questions

Can I move mid-year?

Yes, and it is done frequently. What is required is a clear cut-off date, a recorded numbering decision, and blocking the old system. Whether to start a new series or continue the existing one is a short conversation with your accountant, preferably before the first document.

Do I need to migrate all the history?

Almost always no. What you need is history that is accessible and readable - a full export stored in two places, and access to the old system while it exists. Importing years of records makes the migration more expensive and adds little.

What about open balances?

Migrate them, because otherwise collection restarts from zero. The safe method is importing open balances only, not the whole history, and confirming after the import that the total in the new system matches the old - a five-minute check.

What happens to subscriptions and standing orders?

That is the complex part, and it depends on the clearing system as well as the invoicing system. If clearing stays with the same provider, there is usually no problem. If it changes too, that is a separate project with its own plan.

Keep reading

Related service

Data Migration

Move systems without losing the history - mapping, pilot, delta, cutover.

Learn more

About the author

Yehonatan Saadia

Freelance automation, web & MVP developer

I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.

Work with me

Have a project like this?

Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.