Using spreadsheets does not mean you need an ERP. Neither does hiring your twentieth employee, opening a second location or discovering that finance closes the month with several manual files.
Those things tell you that the current setup deserves attention. They do not tell you what should replace it.
An ERP earns its cost when several parts of the business must agree on the same transactions: what was sold, what is in stock, what must be purchased, what was delivered, what is owed and which legal entity owns the result. Before that point, a full implementation can turn a manageable process problem into an expensive software project.
For many businesses, the honest answer is: not yet.
Start with ownership, not software
Untidy work is often blamed on the tool. Sometimes the deeper problem is that nobody has agreed who owns the outcome, what that person may decide or which information they should trust.
The sales team believes finance owns the customer record. Finance believes sales does. Operations maintains another copy because neither version contains the delivery details it needs. Every team is working, but nobody owns the record from beginning to end.
Installing an ERP before resolving that disagreement will not create ownership. It will encode one version of the disagreement into the new system.
The reverse also matters. A company may have well-defined responsibilities, yet employees still spend their time searching for information, repeating entries and chasing colleagues. In that case, the system has become the constraint.
A system cannot create ownership by itself. It can make ownership possible—or make it unnecessarily difficult.
What employees need to own their work
Giving somebody responsibility is not the same as giving them operational control.
An employee may be told to “own the order” but have no view of available stock. A purchaser may be accountable for replenishment but learn about demand through messages from sales. A project manager may own delivery while having to ask finance whether the client has paid.
The names are clear. The work is not.
Employees need three things before they can genuinely own an outcome:
- Visibility: they can see the present state of the work.
- Authority: they know which decisions they may make without asking.
- Feedback: they can see whether their action produced the intended result.
A suitable system connects those three. It shows the owner, the next action, the information behind the decision and the consequence of completing it. It also exposes a blocked handoff before somebody has to ask why nothing moved.
This is how systems improve efficiency without simply demanding that people work faster. They remove the time spent reconstructing context, checking several versions and asking for status.
What an ownership-enabling system should provide
An employee should be able to answer the following questions without arranging a meeting or searching through old messages.
| Employee’s question | What the system should provide |
|---|---|
| What belongs to me now? | A visible queue of owned actions, not a general list containing everybody’s work |
| What should I do next? | A defined state and next action |
| Which information is correct? | One identified source of truth |
| May I make this decision? | Clear permissions and approval limits |
| What is blocking me? | A named dependency with its own owner |
| Has my work produced the result? | Confirmation that the transaction advanced or closed |
| What happens if I am absent? | A visible history and a reassignment path |
The objective is not to monitor every movement. It is to reduce ambiguity.
A badly designed system does the opposite. It asks employees to enter data that does not help them, hides the wider transaction and sends every exception upward. People become operators of somebody else’s reporting process. They remain accountable for the result while lacking the authority or information to influence it.
That is not ownership. It is traceable dependency.
A working threshold, not a universal rule
No headcount or transaction count can decide the question alone. A ten-person distributor holding serialised stock may need ERP earlier than a sixty-person consultancy.
The following bands are a diagnostic rubric, not published market benchmarks. They help expose where complexity sits. The case for ERP becomes stronger when several factors land in the right-hand column and the same transaction crosses finance, sales, purchasing and operations.
| Operating factor | Accounting software may still be enough | Investigate the gap | ERP is worth evaluating seriously |
|---|---|---|---|
| People involved in operations | Fewer than 20, with clear ownership | 20–50, with repeated handoffs | More than 50, or many people changing the same records |
| Operational transactions per month | Fewer than 500 | 500–2,000 | More than 2,000, especially across departments |
| Legal entities | One | Two with shared operations | Three or more, or intercompany transactions |
| Locations | One operating location | Two locations sharing stock or staff | Several locations requiring common controls |
| Currencies | One main operating currency | A second currency handled regularly | Several currencies affecting purchasing, sales and reporting |
| Stock | None, or a small catalogue counted simply | Multiple stores, frequent adjustments or replenishment | Lots, serial numbers, expiry dates, manufacturing or complex fulfilment |
| Reporting | Finance can reconcile it without rebuilding the month | Reports require recurring exports and manual joins | Different teams produce materially different answers from the same activity |
| Ownership and handoffs | One person can complete most transactions | Ownership changes once or twice and requires manual follow-up | Transactions repeatedly cross departments, with unclear state or duplicated records |
Complexity matters more than company size. Transaction volume matters because it multiplies small inefficiencies, but a lower volume can still justify ERP when each transaction carries stock, compliance, intercompany or multi-location consequences.
Follow one customer order
A useful test is to trace what happens after one real customer order arrives.
If one person records the sale, sends the invoice and updates a simple delivery list, accounting software may cover the transaction well enough. Adding ERP would introduce more configuration, training and administration without necessarily improving the result.
Now consider an order that reserves stock, triggers purchasing, changes a delivery plan, creates work for another location, updates a commission and posts into more than one company.
The person responsible for the customer cannot own that outcome if each consequence lives in a different file. They can coordinate it manually, but coordination becomes the job: checking whether stock was reserved, asking whether purchasing acted and confirming that finance saw the change.
ERP can give that chain one controlled transactional record.
The difference is not whether spreadsheets exist. It is how many operational consequences must remain consistent after somebody changes one value—and whether the person accountable for the result can see them.
Three possible answers
The decision is not simply “keep the spreadsheet” or “buy ERP.” There is a useful middle layer.
| Your situation | Best next layer | What it fixes | What it will not fix |
|---|---|---|---|
| Finance is the main structured function; operations remain simple | Accounting software plus disciplined processes | Invoicing, expenses, tax records and financial reporting | Cross-department operations |
| Work needs ownership, shared information and light workflows, but not deep transactions | A lighter operating setup | Projects, responsibilities, documents, requests and repeatable workflows | Inventory, accounting, payroll and transactional control |
| Finance, sales, purchasing, stock and delivery must act on one record | ERP implementation | Shared transactions, controls, handoffs and operational reporting | An undecided or badly designed process |
Accounting software can give finance clear ownership of invoices, expenses and financial records. It does not usually give operations one view of everything that happened before the accounting entry.
A lighter operating system can clarify who owns a project, request, document or recurring workflow. It works when employees mainly need context, coordination and a reliable next action.
ERP becomes valuable when ownership crosses transactional boundaries. The employee responsible for an order can see its stock, purchasing, delivery and financial consequences in one chain. The system does not replace judgement; it stops each department from owning a different version of the same transaction.
When the answer is “not yet”
Do not buy an ERP merely because a process is untidy.
Choose one recurring process and write down:
- the outcome that matters;
- the person who owns that outcome;
- the decisions they may make;
- the information they require;
- the people who own each dependency;
- the condition that means the work is finished.
Remove duplicate approvals. Decide where the authoritative customer, product and price records live. Stop asking several teams to maintain their own copy of the same list.
Then observe what remains difficult.
If the process becomes manageable once those decisions are made, the business did not have an ERP problem. It had an ownership problem. That is cheaper to solve, and it must be solved before any implementation anyway.
A lighter layer may then be sufficient. Projects, requests, documents and approvals can be structured without pretending that the tool is an accounting or inventory system.
There is no virtue in implementing more software than the operation needs.
When the system becomes the constraint
The opposite conclusion is also possible.
Suppose the owner and decision rules are already clear, but employees cannot act without rebuilding the transaction from several sources. They know what they are responsible for, yet the system withholds the context needed to carry it.
Orders wait while somebody reconciles two files. Stock appears available but is not in the location that promised it. Purchasing works from an old forecast. Finance discovers an operational change after the month closes. Managers stop trusting reports and ask staff for private versions.
The cost is not spreadsheet licence fees. It is delay, repeated checking and decisions made from records describing different moments.
At that point, the workaround is controlling the business. Replacing it is no longer a matter of tidiness.
What ERP will not repair
An ERP does not decide:
- who may approve a discount;
- when a sales order becomes a delivery commitment;
- which product record is authoritative;
- how exceptions should be handled;
- which employee owns a stalled handoff;
- what managers need to review each week.
The implementation will force those questions into the open. If the business refuses to answer them, the system will preserve the disagreement in a more expensive form.
It may also centralise decisions that employees previously handled well. Excessive permissions, unnecessary approvals and workflows built for every imaginable exception can make ownership worse. Employees start serving the system rather than using it to run the work.
A good implementation gives people enough structure to act consistently and enough authority to act without avoidable escalation.
Test three transactions before choosing anything
Take three transactions from the previous month:
- one normal transaction;
- one exception;
- one that crossed several teams, entities or locations.
Trace each from the first request to the final accounting entry. Record every re-entry, private spreadsheet, approval, correction and unresolved ownership question.
Then ask:
- Did the employee responsible for the outcome see its full state?
- Could they make the necessary decisions?
- Did every dependency have a named owner?
- Did completing one step update the people who depended on it?
- Could another employee understand the history without a verbal handover?
If the problems cluster inside one team, improve that process or tool first. If they appear at the handoffs between finance, sales, purchasing, stock and delivery, an ERP evaluation is justified.
The objective is not to become “ERP-ready.” It is to find the lightest system that allows employees to own their work and keeps the operation together.
Sometimes that is ERP. Sometimes it is accounting software with clearer ownership. Sometimes it is a lighter operating layer between them.
Buying the larger answer before you have the larger problem is not preparation. It is overhead.
