Most organisations do not outgrow spreadsheets because spreadsheets are bad. They outgrow them because the organisation has become a system of people, locations, approvals, stock movements, customer promises, and financial obligations that a workbook was never designed to govern.
That distinction matters in Africa, where a growing business may coordinate a Kampala head office, a warehouse in Jinja, field agents travelling with phones, mobile-money collections, and a finance team preparing reports for management or a donor. The issue is not whether Excel can calculate a figure. The issue is whether the organisation can prove where that figure came from, who changed it, and what should happen next.
The spreadsheet is usually the first useful system
A spreadsheet is often the right beginning. A founder can record customers, compare supplier prices, prepare a cash forecast, or model a crop-buying plan without waiting for a software project. That low starting cost is a genuine advantage.
The risk appears when the workbook becomes the place where the business operates rather than a place where someone analyses a controlled data set. The ICAEW principles for good spreadsheet practice explicitly distinguish between a spreadsheet and a database or dedicated bookkeeping system. They also call for controls, review, documentation, and clear ownership. Those are governance needs, not merely formatting preferences.
The World Bank describes cloud computing as a way for African businesses to access enterprise technology without first building and maintaining all the computing infrastructure themselves. Its 2024 digital opportunities report places enterprise resource planning among the business solutions that can run in the cloud. The practical implication is modest but important: a growing organisation can acquire a shared operating system as a service, instead of turning its finance manager into the custodian of a fragile workbook estate.
Five signs the workbook has become an operating risk
1. One number has several versions
The sales team updates a workbook on a shared drive. A branch downloads it before travelling into a low-connectivity area. Finance receives an attachment with a different filename. At month-end, three people are discussing which version is the “latest”.
The arithmetic may be correct in each file. The control has failed because there is no authoritative transaction history. The ICAEW review guidance identifies data integrity, formula, and process errors as separate risks. Version confusion is a process error, even when every formula is technically sound.
2. A branch cannot see stock that another branch has already promised
The head office stock sheet says 420 bags are available. The warehouse sheet shows 180 reserved for a distributor. A field agent has committed another 60 after a phone call. The spreadsheet has recorded quantities, but it has not modelled reservations, transfers, or the moment at which stock becomes available again.
An ERP changes the unit of control. A sales order, stock reservation, transfer, receipt, and dispatch become linked records rather than separate notes. That does not make poor process disappear; it makes the process visible enough to improve.
3. Approval is a message, not a record
A procurement officer emails a quotation. A director replies “approved”. The purchase order is typed into another file, and the invoice arrives weeks later. If an auditor asks why the purchase was made, the evidence is spread across email, paper, and spreadsheets.
The replacement is not a complicated approval theatre. It is a recorded workflow: request, review, approval, order, receipt, invoice, payment. Each stage should retain the actor, time, amount, and supporting document.
4. The model is understood by one person
When the person who built the workbook is away, nobody knows which cells are inputs, which formulas are protected, or why a hidden sheet changes the total. Panko’s research on spreadsheet errors is useful here because it separates the low probability of an error in a single cell from the much larger risk in a large, interdependent spreadsheet. His central warning is about detection: people are often overconfident about errors they cannot see.
That is a succession risk. A business process should be teachable through its screens, permissions, and records, not held in one employee’s memory.
5. Mobile work is an exception process
The field officer captures a sale on paper, sends a mobile-money message, and updates the workbook at the end of the week. By then, the customer balance, stock position, and cash collection may each be out of date. A phone is not a smaller desktop computer; field work needs a deliberate path for capture, confirmation, synchronisation, and exception handling.
GSMA’s 2026 Africa report records the expanding economic role of mobile technology while also reporting a large gap between network coverage and actual mobile-internet use. That is a useful design warning: cloud ERP should support mobile work and constrained connectivity, but it must not assume that every user has continuous high-speed access.
What cloud ERP changes
Cloud ERP is not simply “moving the spreadsheet online”. The useful change is shared transaction structure.
- One record per business event: a sale, receipt, transfer, payment, leave request, or journal entry has a defined status and owner.
- Controlled permissions: a cashier, storekeeper, approver, accountant, and administrator do not need the same ability to create, approve, edit, or reverse a transaction.
- Linked modules: the sale can affect receivables and stock; a purchase can affect payables and inventory; payroll can post to the ledger.
- A usable audit trail: the organisation can investigate a change without asking a single person to reconstruct it from memory.
- Access across locations: staff can work from a branch, office, or field device within the limits of the network and their permission.
None of these benefits removes the need for reconciliations, physical counts, review, backups, or responsible people. A poor process can be automated into a faster poor process. The correct question is therefore not “Which ERP has the most features?” but “Which records and decisions must become shared, controlled, and recoverable?”
When should an organisation migrate?
Do not wait for a perfect moment. Use an operational trigger. Migration is justified when at least two of the following are true:
- Management cannot agree on the current sales, stock, debtor, or cash position without manual reconciliation.
- More than one branch, warehouse, project, or legal entity depends on the same operating data.
- Approvals, corrections, or reversals cannot be reconstructed reliably.
- Month-end reporting depends on copying figures between workbooks.
- A critical process stops when one spreadsheet owner is unavailable.
- Field teams need to work away from the office and return information to a shared ledger.
The migration does not need to begin with every module. Start with the highest-risk flow, document the opening balances and master data, and agree how exceptions will be handled. A manufacturer may start with inventory, procurement, and production costing. A trading business may start with sales, stock, receivables, and mobile-money reconciliation. An NGO may start with restricted budgets, procurement, and donor reporting.
What to expect from a sensible implementation
The first deliverable is not a dashboard. It is a clean operating agreement: which organisation, branches, users, products, customers, suppliers, currencies, approval levels, and reporting periods are in scope.
The second is controlled migration. Clean the chart of accounts, item master, customer balances, supplier balances, opening stock, and outstanding documents before importing them. Keep an exception register. If a figure cannot be proved, label it as an opening-balance decision rather than silently treating it as fact.
The third is adoption. Staff should practise the real flows: receiving stock, making a sale, issuing a credit note, approving a purchase, recording a payment, and closing a period. The measure is not how many screens were configured. It is whether the people who own the work can complete it and know how to recover from an error.
Kraal Code is built around that practical transition: a modular cloud ERP for organisations that need shared finance, inventory, sales, procurement, manufacturing, HR, projects, and reporting without beginning with an on-premise installation. The right next step is still an assessment of the organisation’s processes and evidence, not a promise that software alone will fix them.
The decision
Keep spreadsheets where they are good: analysis, scenarios, one-off working papers, and controlled exports. Move the transactions and approvals that the organisation must share, protect, reconcile, and explain into a system designed for that job.
If your business is at the point where two people can produce two defensible versions of the same number, map that process before buying anything. Then compare the cost of continuing the workaround with the cost of making the record authoritative. You can explore Kraal Code capabilities or request a guided demonstration focused on the specific flow that is becoming difficult to govern.
What changes after migration
The first benefit is not a new dashboard. It is a shared sequence. A customer order can reserve stock, create the next fulfilment task, produce an invoice, and leave a receivable that the finance team can follow. A purchase can move from request to approval to receipt, with the document and responsible person attached at each stage. A manager can inspect the exception queue instead of asking every team for a separate status update.
That sequence only works when the business agrees its definitions. What counts as a received item? When does a branch transfer become available? Which user may approve a credit note? What is the source of truth for the cash balance? These are operating decisions that should be documented before software configuration.
For a manufacturing business, the useful test may be the relationship between a purchase receipt, a bill of materials, a production issue, finished stock, and the sale. For a trader, it may be landed cost, multi-location stock, customer credit, and a mobile-money collection. For an NGO, it may be donor dimensions, approvals, supporting documents, and a report that ties expenditure to a grant budget. For an agricultural organisation, it may be harvest records, inventory, sales, and the evidence needed for the relevant accounting treatment. Explore Kraal Code’s inventory capability, accounting capability, and agriculture sector context against the organisation’s own workflow.
When not to migrate yet
Do not rush into a platform project when the owner, reporting basis, chart of accounts, or approval responsibilities are unknown. A new system will record an unclear process more consistently, but it will not decide the process for you. Stabilise the master data, name an implementation owner, agree the first pilot, and define how the team will recover if the cutover is delayed.
The most credible migration plan is modest. Start with a bounded set of master data and transactions, run it alongside the existing process for an agreed period, reconcile the outputs, and record every unresolved difference. Expand only when the business can explain the result to a reviewer who was not in the implementation room.
