Excel or an ERP: the point where the spreadsheet stops coping

Excel is not the problem, and replacing it is not the fix. A spreadsheet stops coping at one point: when it stops being somewhere a person calculates and becomes the only place the records live — no history, no permissions, no second reader. The answer flips on that distinction, not on the size of the file or the number of tabs in it. Most companies in Algeria run on a spreadsheet and are right to; the ones that should move are the ones where the file has quietly become a system.

Why is the spreadsheet the most-used system in the country?

Because it does the hardest part instantly: it models anything in an afternoon, is already on the machine, and needs no vendor, no project, no training. A small company can run stock, invoicing and a purchasing list on one file and be profitable doing it. That is not a failure of judgement — it is the cheapest possible way to start.

The trouble arrives without an announcement. The file does not break; it acquires a second editor, then a version suffix, then a rule that only one person knows. Nobody decides to build a system. It happens between two ordinary weeks.

What are the signals that it has stopped coping?

• The file is the process. One person knows which cells to touch on Monday morning. When he takes leave, the week stops.
• The month closes by reconciling files against each other, not by reading one report: two numbers that should be one is the clearest symptom there is.
• Nobody can say what the figure was before the last edit. No author, no date, no earlier state — only the latest copy, which may not be the copy everyone else has.
• Access is "whoever has the file". A seasonal worker can see salaries, or change a price by accident, and nothing records it.
• Two people work in it at once. One saves over the other, silently, and the loser never learns.

Any two of those together means the spreadsheet is no longer a tool. It is an unsafeguarded system — and the system of record.

What does Excel still do better than an ERP?

Almost everything that involves a question rather than a record. A margin calculation for a new price, a what-if on a delivery route, a list of what to reorder before a holiday: an ERP does these slowly, if at all, and the spreadsheet does them now.

So the division is not "replace it". It is: the spreadsheet answers questions, the system holds records. A company that keeps both, with the spreadsheet reading an export instead of being typed into, gets the best of the two.

What does the move actually cost?

Not the licence. The cost is attention, in three places.

The first is the overlap: a period where the team runs both, entering twice, and nobody trusts either number yet. The second is master data — the sheet has several spellings of the same product and units that are sometimes kilos and sometimes sacks. Cleaning that is a week of arguing about names, before the import.

The third is definitions. What is a customer: the shop, the owner, or the delivery address? When does a sale exist: at the order, at the delivery, or at the settlement? A spreadsheet never had to answer, because a person did.

Which parts should move first?

Orders and stock, because that is where the silent overwrite costs money. Then invoicing, once the stock movement is trustworthy. Reporting last, and only from the system, never from a spreadsheet that still receives typing.

Keep one spreadsheet, deliberately: the analysis file, fed by an export, with a date in its name.

The comparison, in one table

Dimension	Spreadsheet	ERP
What it is for	Calculating an answer now	Holding a record over time
Who can change it	Anyone holding the file	Whoever holds the role
History	What the last copy says	Who changed what, and when
Two people at once	One overwrites the other, silently	Both are recorded
Cost of a mistake	Found at month end	Blocked at entry, or traced later
Adding a field	Type a heading	A change, with a migration
What to verify on the vendor's page	The support window of the version in use, and whether the desktop or web file is the real one	The import route for your existing data, and who is accountable for the opening balances

In what order should you move?

1. Prove the file is the problem. Try to reconstruct last month's stock from it alone, without asking anyone. The figure you cannot reconstruct is your reason.
2. Write the sheet's rules on a page: what a row represents, what the units are, which columns are calculated and which are typed.
3. Clean the master data before anything else — one product, one name, one unit.
4. Move orders and stock first; keep the spreadsheet for analysis on an export.
5. Run both for a period you define in advance, with one control total that must match every day.
6. Retire the file by permission, not request: remove editing rights on a stated date, keep a read-only archive.

Where this goes wrong

• The system is built to look like the spreadsheet. Every column becomes a field, and the new tool inherits all the exceptions with none of the flexibility.
• The spreadsheet survives as shadow truth. Reports are still made from it, and the system becomes a tax the team pays.
• Everything moves at once. The first month is spent repairing data instead of running the business.
• The person who built the sheet is the only one who can verify the migration. Have someone who never built it sign the control totals.
• The definitions are never agreed. "Customer" means the shop to sales, the owner to accounting, and the address to the courier — and three correct answers produce one wrong report.

When neither fits

Sometimes the honest requirement is one guarded register, not an ERP: a stock count several people update from their phones, or a repair ticket that follows a job from intake to invoice. Building that single thing — with a login, a history and a rule — replaces the risky part of the spreadsheet without buying a system for a company that does not need one yet. It is also the cheapest way to learn whether the definitions can be agreed, because a small build forces the argument early.

What this does not cover

Pricing is deliberately omitted, since any figure quoted here would be wrong within months, and what decides this project is the cleaning, the overlap and the training — none of which are on a price list. Nor does it choose an ERP, or cover payroll and statutory reporting. It assumes the file is in daily use; a spreadsheet kept for reference needs no migration.

We build and integrate systems around tools like these: the register that replaces the dangerous file, the import that keeps the numbers, the report the finance team can defend. We resell no ERP and take no commission from any vendor.