A local accounting package or an ERP: what an Algerian company actually outgrows

The accounting package is almost never the part that fails. It does the ledger, the declarations and the printouts the tax office asks for, in a form your cabinet already trusts. What a growing company outgrows is the rest: stock the package knows only as a balance, orders kept in a notebook, delivery nobody records until the invoice, an audit trail that is a folder of paper. The signal is not that the accounts are wrong — it is that nobody can explain a number without leaving the system.

Why does the local package hold up so well?

Because it was built for the job the market gave it. The accountant, not the operations manager, is the primary user, and the package was shaped around that: a chart of accounts that matches practice, the declarations in the form they are filed, printouts a cabinet reads without training.

Most companies run on one, and that is rational rather than a compromise. A company whose real need is books is served completely; an ERP would charge it for structure it does not use.

What breaks first?

Stock, then orders, then delivery — the order follows where the money is exposed.

Stock. The package holds a value — what inventory is worth at closing — not the movements that produced it. A wrong balance is fixed by a person typing a number, and the reason is lost.

Orders. A confirmed order is a promise with a date. The package records the invoice, not the promise, so "where is this order" is answered from memory.

Delivery. When goods leave, someone should say what left, with whom, against which document. A paper slip collected at month end is no record.

The audit trail. All three fail the same way: the figure can be stated, not reconstructed. That is the real loss, and it stays invisible while business is calm.

What is the signal that the pair has been outgrown?

One test settles it, and costs nothing: rebuild last month's stock from the system alone, without opening a spreadsheet or a phone. If you cannot, the movement record lives outside the system and the package is holding a conclusion rather than an account.

• Stock and cost of goods are settled at closing from a count and a spreadsheet, not from movements.
• The same document is typed more than once — order, delivery note, invoice — and the versions disagree monthly.
• Two people give different answers to "how much do we have", each right about their own source.
• Nobody can say who changed a price, or when.

Any two together mean the company runs two records of one business. That is the point of no return — not its size, or the number of invoices.

What does staying cost?

Three costs, and only the first appears on a timesheet.

Rekeying. Every document entered twice costs hours each time, rarely counted because the hours are spread across people. The error rate is not the problem; the discovery rate is. A mistyped quantity surfaces at the count, weeks later, when the trail is cold.

Month-end. The closing stops being a reading and becomes a reconciliation project: two numbers must agree before anything is signed, and whoever can make them agree becomes indispensable. That is a risk wearing the face of a skill.

Two truths. Sales quotes one number, accounting another, and each is right inside its own definition. Nobody wrote down what a sale is — the order, the delivery, the invoice. An ERP does not settle that either, but it forces the argument once instead of monthly.

The comparison, in one table

Question	Accounting package alone	Package plus an ERP
What it holds	Balances and entries	Movements, orders, deliveries, entries
Where the stock figure comes from	A count typed in at closing	Movements recorded as they happen
When a mistake is found	At the count, weeks later	At entry, or in the history
The audit question	Reconstructed from paper	Answered from the record
What to verify with the vendor	Whether movements can be imported, and what it exports	The import of opening balances, and who signs the closing

In what order should you decide?

1. Run the reconstruction test on last month, spreadsheet closed.
2. Write down what a sale is, and what a cost is. Judge both systems against that.
3. Ask whether the package can import stock movements. Some can, and that changes the answer.
4. If it can, keep the package for the ledger and add one movement record feeding it. That ends the rekeying.
5. If it cannot, take the ERP for stock and orders, and keep the package for the declarations if the accountant needs it.
6. Run both for a fixed period, with one control total that must match daily, and name who signs the closing before go-live.

Where this goes wrong

• An ERP is bought to fix a definition problem. If nobody agreed what a confirmed order is, the system records the disagreement faster.
• The ledger is migrated when only stock needed a system. The accountant loses the tool he knows, declarations are relearned under pressure, and stock improves no faster.
• The old package keeps taking manual stock adjustments after go-live. The seam returns within a month, invisible this time because the new system looks authoritative.
• The ERP's valuation method is not the one the declarations use. Two defensible methods, one set of books, an argument at closing.
• The audit trail is a feature rather than a practice. If three people share one login, the history is fiction, and an auditor will read it that way.
• Opening balances are left to the last week. They decide whether the switch is a weekend or a quarter.

When neither fits

A company whose only complaint is the monthly report does not need an ERP; it needs that report built from the records it has. And a company that has outgrown the package but has nobody to own a system will be worse off with a bigger one — the honest first step is one guarded register for stock movements, run beside the package until the definitions hold.

What this does not cover

No prices, no product names, no versions: this is about a category of software, and any figure or edition named here would mislead a reader within months. Terms change too — what a package can import, how an ERP is licensed, what an implementer commits to — so confirm it with the vendor in writing at purchase. It does not judge which local package is best, does not cover payroll, and assumes the accounts are in order.

We build the movement record and the interface that lets a package stay where it is good — the stock history, the delivery note, the closing report — and we resell no accounting package and take no commission from any vendor.