Moving off accounting software: what breaks and when

How do you know you have outgrown your accounting software?

Four signals, and they are specific rather than vague. Stock sitting in a second location. A second currency in daily use. Stock large enough that a wrong figure changes your reported profit. And a month end that keeps stretching because operational data is being rebuilt by hand every time.

Wanting to be more organised is not a signal. Plenty of companies move too early, pay for complexity they cannot use, and go back to running the important numbers in Excel anyway. The useful test is whether a specific question is now impossible to answer quickly, and whether that question matters to how you make money.

Listen for what people say rather than what they ask for. 'The stock figure in the accounts is a guess.' 'We cannot price this job because we do not know the landed cost.' 'The branch and head office gave me different answers about the same item this morning.' Each of those describes a limit of the software, not a discipline problem.

One more that people miss: the number of spreadsheets that sit between the operation and the accounts. If pricing, stock, commissions and job costing each live in their own file maintained by one person, you already run a second system. It just has no controls and no backup.

What actually breaks first?

Stock valuation, in most companies. Accounting software records what you bought and what you sold. It is weak on what you hold, where it is, and what it cost to land. Once stock is material, the figure in your accounts becomes a maintained estimate, and estimates drift.

Landed cost is where it usually starts. Freight, customs, clearance and handling arrive as separate supplier invoices, weeks after the goods. Somebody spreads those costs across the shipment in a spreadsheet and posts a journal. It works until volumes rise, and then the margin on each product becomes a number nobody can defend.

Transfers between locations break next. A branch takes stock from the warehouse, the paperwork follows a week later or never, and the two counts stop matching. There is no clean way to fix this with journals, because the problem is that movements are not being recorded as movements.

Currency is the third, and in Lebanon and the Gulf it is often the first. Buying in one currency, selling in another, holding balances in both, and revaluing at period end is possible in most accounting packages and painful in all of them. The work moves to a spreadsheet, and once the spreadsheet exists, the books are a copy of it.

Controls go last. Approval limits, credit limits enforced before delivery rather than after, and a trail showing who changed a price. These matter more as headcount grows, and they are usually the reason a growing company finally moves.

What do you gain, and what do you genuinely lose?

You gain one version of the numbers and the ability to answer a question without rebuilding a spreadsheet first. You lose simplicity. Small tasks get slower, your accountant loses a system they knew by heart, and your team has to follow process where they used to improvise.

The loss most people underestimate is speed on small things. In accounting software, raising a quick invoice is a few fields. In an ERP the same invoice may pass through a customer record, a price list, a stock check and an approval. That is the point of it, and it is still slower on the day. If most of your work is small and fast, the trade is worse for you than for a distributor.

The second loss is your accountant's familiarity, and it is worth taking seriously. Someone who has closed your books in the same software for years works quickly because they know where everything is. Move them and they will be slower and less confident for a couple of quarters. Involve them in the choice early, give them access during configuration, and expect their first close in the new system to take longer than the last one in the old.

The third is flexibility, which cuts both ways. A spreadsheet lets anyone do anything, including things that should never have happened. An ERP will refuse. People who have been quietly working around the rules will discover the rules, and some of them will complain to you about the software when the real subject is the control.

How do you move opening balances and stock without corrupting your history?

Migrate balances, not transactions. One dated opening entry per account, agreed with your accountant and reconciled to the old system before anything new is posted. Stock arrives as a counted quantity and an agreed cost per item, not as an import of years of past purchases.

Importing transaction history is the request that causes the most damage. Old records carry old mistakes, old item codes and old customer names, and once they are inside the new system they are much harder to identify and remove. You also end up with a general ledger that does not tie to the accounts your auditor already signed. Almost nobody who does this is glad they did.

What you do need in detail is the open items. Unpaid sales invoices with their dates and amounts, unpaid supplier invoices, and any partly delivered orders. Those have to come across line by line, because you will be chasing and paying against them. Everything settled can stay behind as a balance.

Stock is its own exercise. Count it physically, agree a cost per item with your accountant, and load quantity and cost together on the cutover date. Do not load quantities and let the system work out cost from an incomplete purchase history, because the valuation will be wrong from day one and every margin report afterwards inherits the error.

Then freeze. Announce a date after which nothing new is entered in the old system, and hold it. A soft cutover where two or three people keep posting in the old software for another week is the most reliable way to end up with two incomplete sets of books.

• Trial balance agreed before anything is posted

  The opening entry has to equal the closing position in the old system, to the cent, signed by whoever closes your books.

• Receivables and payables listed line by line

  The total must match the control account, and each line must be one you would be willing to chase.

• Bank balances reconciled to statements

  Use the statement, not the old system's figure, and clear uncleared items deliberately.

• Stock counted, not assumed

  A physical count on or near the cutover date is the only version anyone will trust afterwards.

• Item and customer lists cleaned first

  Merging duplicates is far cheaper before the migration than after, when transactions are attached to them.

When in the financial year should you switch?

The first day of a financial year is cleanest, because your opening balances are the closing balances someone has already signed off. The start of a quarter or a month is the workable second choice. Switching mid-month is the version that creates reconciliation work for the rest of the year.

The year-start option has one catch. Your finance team is busiest around year end, which is exactly when the migration work needs them. The way through is to do the preparation months earlier, so the only thing left in January is loading agreed figures. Clean the lists, decide the chart of accounts and run a test load in the autumn.

If waiting for the year start means holding a decision for eight months, take the start of a quarter instead. You will have one year split across two systems, which your accountant can handle as long as the cutover is clean and both sides reconcile. Tell them before you commit to the date, not after.

Whichever date you choose, avoid your busiest operating month regardless of what the calendar says about the financial year. A clean accounting date during your peak season is a worse trade than a slightly awkward date during your quiet one.

What do you do with the historical data?

Keep the old system readable and stop writing to it. Export the reports you are required to keep, retain access for as long as your auditor and the tax authority need, and accept that for about a year you will look some things up in two places. That is normal and it is cheaper than importing history.

Before you let a subscription lapse or a server get wiped, export everything you might need while you can still open it. General ledger detail for the years you must retain, aged receivables and payables at the cutover date, customer and supplier statements, sales history by item, and PDF copies of issued invoices. Then open the exports on a different computer and confirm they are readable. Files that only open on the machine that made them are not a backup.

Decide who keeps the archive and where. One named person, one location, and a note in your procedures saying what is in it. Companies lose years of history because a laptop was replaced or a subscription was cancelled by whoever was managing costs that month.

For comparative reporting, a small amount of summary history inside the new system is usually enough. Monthly totals per account for the previous year or two gives you year-on-year comparison without dragging old transactions across. It is a modest piece of work and it removes most of the reason people ask for a full history import.

When should you not move?

If you run one location, one currency, and stock is small or absent, staying is the right answer. Many service companies never need an ERP. Moving because a competitor did, or because a new hire prefers the software they used before, is not a reason and will cost you a year.

Timing rules out more companies than size does. If you are in the middle of an audit, a funding round, a relocation, a change of ownership or a major hiring push, do not add this to it. An ERP migration needs your finance and operations people at their most available, and those events take exactly the same people.

The other clear stop sign is having nobody to own it. If you cannot name one person with the authority to decide how processes should work and the time to spend on it, the project will drift regardless of which system you buy. Fixing that comes first, and it may mean hiring before buying.

There is also a middle option people skip. Sometimes the real problem is one function rather than the whole finance stack. An inventory or warehouse system alongside your existing accounting software can carry you for another year or two, particularly if the accounting side genuinely works and only the stock side does not. It is not a permanent answer, because you will be reconciling two systems, but as a deliberate step it is often cheaper than a full move made two years early.

• One location, one currency, little stock

  Accounting software plus discipline is the correct tool. Do not pay for capability you cannot use.

• You are mid-audit or mid-transaction

  The same people are needed for both. Finish one, then start the other.

• No internal owner exists

  Buying software will not create one, and the project needs the decisions more than the licence.

• The pain is in one function only

  A dedicated system for that function may buy you time at a lower cost and lower risk.

Where does Wizard fit into this?

Wizard Cloud ERP is built in Lebanon by Wizard Solutions and sold mostly to trading, distribution, retail and service companies here and in the Gulf. If your books are simple and stock is not material, we would tell you to stay on what you have, because a system you do not need becomes a system you do not use.

The move tends to make sense when the reasons above are true at once: stock in more than one place, more than one currency in daily use, and a month end that has quietly become a week of manual work. Those are the situations where accounting software stops being a discipline problem and starts being a limit.

If you have not chosen a direction yet, the buying guide covers what to test in a demo and what to ask any vendor before signing. If you have already signed, the implementation guide is about the part that goes wrong after the contract, which is where most of the risk actually sits.