ERP implementation and customisation

What this actually solves

A distributor keeps the accounts in one package, the stock in a register, and the orders in a spreadsheet. Every month the three disagree. Sometimes the difference is small and sometimes it is a month's margin, and nobody can say where it appeared — in a van, in the warehouse, in a return, or on a delivery slip that went missing between the shop and the office. The owner has changed staff twice over it. The difference keeps appearing, because the problem was never the person. Stock is being recorded in three unconnected places, and three records that cannot be reconciled will always drift.

Underneath that sits a harder question the owner cannot answer. Which brand actually makes money after discounts and returns. How much credit is genuinely outstanding and how old it is. What is really in the warehouse right now, as opposed to what the register says was there last Thursday. An ERP is bought for exactly one reason — the business needs one version of the truth instead of several, and it needs that truth to be current enough to make a purchasing decision on. Everything else in the project is in service of that.

This is also the point where an honest warning belongs. This is the heaviest system a business ever installs, and if the accounting inside it is wrong, the consequences are not cosmetic — tax filings and bank reporting are built on those numbers. Most of the work below exists to prevent that.

How the work runs

1. Discovery and process mapping, department by department. Finance, purchasing, warehouse and sales are mapped separately, because they describe the same transaction differently and the gaps between their accounts are where the project's real risks live. Each department's current process is written out with every stall and every manual re-keying marked. Four to eight weeks.
2. The accounting decisions. Chart of accounts, inventory valuation, tax handling and document numbering, agreed with your accountant and, where relevant, your auditor. These are decided before configuration because they are extremely expensive to change afterwards — they determine what every future report can say. Two to four weeks, running alongside the mapping.
3. Master data cleanup. The SKU list, the customer list, the supplier list. This is routinely the single longest task and the one nobody budgets for — the same item exists under three codes because three departments named it, units of measure are inconsistent, and discontinued lines have never been retired. Decisions about what does not come across are made here and recorded. Three to eight weeks.
4. Configuration and customisation. Modules switched on in the order the business needs them, workflows and approvals built, documents and reports laid out, integrations to the webshop, bank or existing systems connected. Each area is demonstrated to the department that owns it while it is still cheap to change. Six to sixteen weeks.
5. Migration rehearsals and opening balances. The full migration is run end to end at least twice, on a copy, before it is run for real — every count reconciled back to source, every difference explained rather than absorbed. Opening balances are prepared for the exact go-live date, per account and per item. Two to four weeks.
6. Testing with your own staff on real transactions. The people who will use it each process genuine work — a real purchase order, a real dispatch, a real invoice, a real month-end — and report where they got stuck. Findings are split into blocking, fix after launch, and next phase. Two to four weeks.
7. Cutover, training and hypercare. Training is given per role on that role's own data, recorded, and backed by short printed sheets. Go-live is timed to a period boundary, never a Friday, and the old system is left read-only. Then daily support through the first close. Two to three months of hypercare after go-live.

What moves the price

The range is $8,000–$150,000 and it is genuinely that wide, for three reasons.

How many parts of the business come in. Finance and inventory alone is one project. Adding production planning, multi-warehouse handling, quality control and field sales is several, and each new module brings its own master data, its own approvals and its own month-end behaviour.

How much customisation the business genuinely requires. Standard configuration is comparatively cheap. Custom documents, custom approval logic and custom reports each need building, testing and re-testing after every platform upgrade, so they carry a cost that continues after the project ends. Part of this work is arguing you out of customisations that only exist because of a habit nobody has questioned.

The state of the master data and the number of connections. A clean product catalogue and one integration is a different job from forty thousand inconsistent SKUs plus links to a webshop, a bank feed and a legacy accounting package that has to keep running until year end.

What usually goes wrong

The chart of accounts is drawn up by whoever is configuring the system. It looks sensible, everyone approves it in a meeting, and it is wrong in ways that only appear at year end — costs that cannot be split by product line, a stock account that does not reconcile to the ledger, VAT or sales tax reported at the wrong level. Restructuring it after a year of transactions is a project of its own. Your accountant belongs in that decision on day one, not at the first audit.

Migration gets rehearsed once, or not at all. Because the individual imports succeed, the team concludes the migration works. Then go-live arrives and opening stock is out on a few hundred items, or supplier balances land without their ageing, and the business spends its first month unable to trust any number it sees. Two full rehearsals with every total reconciled to source is what separates a controlled cutover from a bad quarter.

The old spreadsheets are quietly kept alive. A department is nervous, so they keep their own sheet "just for now". Within two months the ERP and the sheet disagree, people trust the sheet, and the company has paid for a system while still running on the problem it bought the system to remove. A parallel period is fine and sometimes necessary — but it needs a written end date, and any sheet that survives past it is evidence of a real gap that has to be found and closed.