Key points
- An ERP records a system; it does not create one. If the documentary cycle does not exist on paper, the software will not invent it.
- The three symptoms that justify an ERP are all about volume and reconciliation, not about ambition.
- The real cost is four line items: licence, implementation, data entry and training — and the last two are usually the largest.
- Coding, opening balances and approval authorities must exist before implementation starts, or the project stalls at data migration.
- A company with one store, one bank account and clean spreadsheets rarely needs an ERP yet.
An ERP system is worth buying when a documentary cycle already exists and the volume of it has outgrown the tools you are recording it with. If that cycle does not exist, an ERP will not create it — it will record the same undocumented movements faster, in a more expensive place.
Which three symptoms mean a spreadsheet has stopped working?
A spreadsheet has stopped working when the same figure exists in more than one place, when a month cannot be closed without one specific person, and when a stock or bank difference can no longer be traced to the document that caused it. Each of those is a volume problem, and volume is what software solves.
- The same number lives in two files. Sales are in one sheet, stock issues in another, and the two disagree by an amount nobody can explain. Reconciling them is now a monthly job in itself.
- One person is the system. The month cannot be closed while they are on leave, because the logic of how the files fit together is in their head rather than in a procedure.
- A difference cannot be traced. You can see that stock is short, or that the bank does not match, but not which movement caused it — so the difference is absorbed rather than investigated.
Which three symptoms do not justify an ERP?
Three common reasons for buying an ERP do not survive examination: that a competitor has one, that reports are late, and that the accountant asked for one. None of the three is caused by the absence of software, and buying software will not remove any of them.
- “A competitor has one.” A competitor with four branches and a warehouse team has a different problem from a single-store business, and the same licence solves neither by itself.
- “The reports are late.” Reports are usually late because the source documents arrive late. Software cannot record a delivery note that nobody wrote.
- “The accountant asked for one.” Sometimes correct — but ask what specifically cannot be done today, and whether the answer is a missing procedure rather than a missing feature.
What does an ERP not fix?
An ERP does not fix a missing documentary cycle, undefined approval authorities, or an absence of separation of duties. Those are decisions about how the company works, and they have to be made before the software is configured — because the software will ask you to encode them on its first day.
The most expensive ERP failures are not technical. They are companies that bought a system to replace a decision they had not yet made.
What must exist before implementation starts?
Five things must exist on paper before an implementation begins: an item coding scheme, a chart of accounts, opening balances that have been counted rather than estimated, written approval authorities, and one named person inside the company who owns the project. Implementations stall at data migration when one of these is missing, and the delay is charged to you.
What does an ERP really cost?
The licence is rarely the largest line. Budget for four separate costs, and expect the last two to exceed the first: the licence or subscription, the implementation and configuration work, the data entry needed to bring history and balances in, and the training that makes the team actually use it.
| Cost line | Paid to | Usually underestimated because |
|---|---|---|
| Licence or subscription | The software owner | It is the only figure quoted up front, so it becomes the whole budget. |
| Implementation and configuration | The implementer | Scope grows once the company sees what has to be decided. |
| Data entry of history and balances | The company itself | It is staff time, so it does not appear on any invoice. |
| Training and the first months of correction | Both | Everyone assumes the team will learn it on the job. |
How should a company choose between systems?
Choose on three questions, in this order: can it produce the specific reports you make decisions from, can your current team operate it without a permanent consultant, and can you get your own data out of it if you leave. Feature lists are long and mostly irrelevant; those three questions decide whether the system is still useful in year three.
A readiness checklist you can run this week
If you can tick every line below, an ERP will pay for itself. If you cannot, the missing lines are the project — and they cost far less than the licence.
- Every item that leaves a store has a document and a named person responsible.
- Every item has one code, used in exactly one way, everywhere.
- A chart of accounts exists that separates revenue and cost the way you make decisions.
- Opening balances for stock, cash, customers and suppliers have been counted or confirmed, not estimated.
- Approval authorities are written down, with limits.
- One person inside the company owns the project and can approve decisions.
Should you migrate history, or start clean?
Migrate balances, not history. What the new system needs to be useful is a correct opening position — stock quantities and values, cash, customer and supplier balances, and the fixed asset register — not five years of transactions whose accuracy nobody can vouch for.
Migrating unverified history has two costs. The first is the data entry itself, which is charged by the hour or absorbed by your own staff. The second is worse: once wrong figures are inside the new system, every report it produces inherits them, and the company loses the one clean starting point it was paying for. Keep the old records accessible for reference and reconstruct only what a decision or a filing actually needs.
What goes wrong in the first month after go-live?
In the first month the team runs the old process and the new system side by side, and that is where an implementation is usually lost. The symptom is a parallel record — a notebook, a spreadsheet, a chat group — kept because the new screen is slower or because nobody was told what to do with an exception.
- Decide the cut-over date in writing and stop the old method on it. Running both indefinitely guarantees two versions of the truth.
- Write down how each exception is handled — a return, a damaged item, a price correction, a transfer — before go-live, not after the first argument about one.
- Reconcile the first month deliberately: stock, bank, customers and suppliers, against the migrated opening balances.
- Expect a correction period and budget for it. A system that produced no corrections in month one is a system nobody used.
What to do if the checklist fails
If the checklist fails, build the cycle first and buy the software second. That is exactly what the Foundation Package does: the documentary cycle, the chart of accounts, written authorities and counted opening balances — the six things an implementer will ask you for on day one. The seven-question self-check will tell you in two minutes which of them are missing.