Do you need an ERP for a small business, or three tools that talk to each other?

It arrives the same way every time. Accounting is in one place, stock is in another, jobs are in a third, and somebody spends Monday reconciling the three. You mention it to an adviser, an accountant or a peer, and they say what you need is an ERP.

Most small businesses asking that question do not need an ERP for a small business. They need three tools connected properly, which costs a fraction and can be done in weeks. There is a real point where that stops being true, and it is worth knowing exactly where it is before anyone quotes you six figures.

What an ERP for a small business actually is

Worth defining, because the word is used loosely and that vagueness is where money goes missing.

An ERP is one system holding your finance, stock, purchasing, sales and often manufacturing and payroll, in one database, so that a sale updates stock, ledgers and costs in a single motion with nothing syncing. That single database is the whole proposition, and it is genuinely valuable. Everything else about an ERP, the modules, the reporting, the workflow, exists elsewhere too.

What you buy is not features. It is the absence of reconciliation. That is what you are deciding whether to pay for.

The three-tools alternative

The alternative nobody quotes you, because it is a smaller sale: keep the tools your team already knows, and connect them so the re-typing stops.

• Accounting stays where it is. Your bookkeeper knows it, your accountant accepts it, and it works.
• The operational system is chosen for your trade, not for its finance module. A job system for a service business, a stock system for a distributor, whatever fits.
• They are connected one direction at a time, with one system named as the master for each piece of information.
• Reporting reads from both, so the questions that span them can finally be answered.

Where connected tools genuinely stop working

Being fair to the expensive option, because there is a real threshold and pretending otherwise would be dishonest.

1. When a single transaction has to touch four systems at once. A sale that must reserve stock, trigger a purchase order, book a job and post to the ledger simultaneously is where syncing starts losing to a single database.
2. When you manufacture. Bills of materials, work orders, production scheduling and costing are the case ERPs were actually built for, and connected tools handle them poorly.
3. When reconciliation has become someone's job. Not an afternoon a month. A person, most of the week. At that point the ERP is competing against a salary rather than against a subscription.
4. When you have multiple entities or currencies that must consolidate. Genuinely painful across separate systems.
5. When a customer or regulator requires traceability end to end: which batch, which supplier, which order, provable. Possible across connected tools and much harder.

Two or more of those and the ERP conversation is legitimate. None of them, and you are being sold a solution to a problem you do not have yet. Our internal tools work is usually the middle path, and custom software vs off-the-shelf has the scoring framework for the general version of this decision.

What implementation actually involves

Since implementation is the real cost and the one least often explained, here is what the money buys. Understanding this is also how you tell a serious quote from an optimistic one.

1. Discovery, and deciding whose process wins. Someone maps how you actually work, then you decide for each step whether to adopt the system's way or configure it to yours. This is the phase that determines everything after it, and rushing it is the single most expensive economy available.
2. Configuration. Chart of accounts, tax rules, product structures, warehouses, user roles, approval limits, document templates. Weeks of decisions, most of which nobody has had to make explicitly before.
3. Data migration. Customers, suppliers, products, opening balances, and how much history to bring. This is where the state of your existing data stops being a private embarrassment and becomes a line on a plan.
4. Integration. Whatever stays outside the ERP still has to talk to it: your website, your payment processor, a machine on the shop floor, a customer's ordering system.
5. Testing with real transactions. Running a genuine month through it in parallel before committing. Teams that skip this discover the tax configuration is wrong during their first real month-end.
6. Training and the first month live. Everyone learns a new way to do a job they already knew. Productivity drops before it rises, and planning for that dip is the difference between a bumpy month and a crisis.

Six phases, of which software licensing is none. That is why implementation routinely exceeds the licence, and why a quote that does not break these out is not yet a quote.

Why these projects fail

ERP implementations have an unhappy reputation and it is deserved, but the reasons are consistent enough to be avoidable.

• The licence was compared, not the implementation. The software is the small number. Configuration, data migration, integration and training are the project, and a quote that leads with the monthly fee has told you about a fraction of the cost.
• Nobody decided whether to change the process. An ERP has opinions about how a business should run. You either adopt them, which is disruptive, or customise around them, which is expensive and makes upgrades painful. Deciding this halfway through is how budgets double.
• The data was worse than anyone admitted. Years of inconsistent product codes and duplicate customers surface during migration, at the worst possible moment.
• No internal owner. These projects need someone senior whose actual job is this for six months. Where that person does not exist, the consultants make the decisions and nobody owns the result.
• Training was the line item that got cut. A system nobody can use is worse than the spreadsheet it replaced, because now it is also expensive.

The categories you will be shown

Once you start looking you will be presented with three quite different things, all called ERP, at prices that differ by an order of magnitude. Knowing which you are being shown saves a great deal of confusion.

The practical advice is to establish which category you are in before comparing anything, because a demonstration of the third will make the first look inadequate regardless of whether it would have served you perfectly well.

How to decide in an afternoon

1. Count the reconciliation. Hours a week, across everyone, spent making systems agree. Multiply by fifty. That is what you are buying out of.
2. Write down the one transaction that hurts most, and how many systems it touches. If the answer is two, connect them. Four, keep reading.
3. Price the connected version first, properly, from someone who will actually build it. You cannot judge an ERP quote without a number to compare it to.
4. Ask any ERP supplier for implementation and licence separately, in writing, with the assumptions listed. If implementation is vague, that is your answer about the whole engagement.
5. Ask who inside your business will own it, name them, and check they have the time. If nobody can be named, do not start.
6. Ask what happens to your data if you leave. The question is uncomfortable early and much worse late.

Not for you if

One question that cuts through the sales process, and it works on us as readily as on anyone else: ask a supplier what would have to be true for you not to need their ERP, and what they would recommend in that case instead. Anyone who has implemented a few has a clear answer, and it usually describes a business rather like yours.