Why African SMEs Are Leaving Spreadsheets for Integrated Operations
Spreadsheets are not the problem, and businesses that move because someone told them to usually move badly. Five triggers that genuinely mean it is time, the two that look like triggers and are not, and what to do in the six weeks before you shortlist anything.
There is a genre of business writing that treats spreadsheets as a moral failing. It is wrong, and it makes buyers defensive about a tool that has probably served them extremely well. A spreadsheet is fast, free, universally understood, and infinitely flexible — which is precisely why it is the right answer for a very long time and the wrong answer suddenly.
The useful question is not whether spreadsheets are bad. It is what changed in your business, because businesses that move for a reason succeed and businesses that move because a vendor or a board member said so tend to end up with an expensive system that people export to a spreadsheet.
What a spreadsheet is actually good at
Worth stating honestly, because it explains what you lose as well as what you gain.
- Flexibility with no permission required. A new column exists the moment somebody needs it. No configuration, no consultant, no release.
- Everybody can already use it. The training cost is genuinely zero, which is not true of anything you will replace it with.
- It fits the business exactly, because it grew out of the business rather than being imposed on it.
- It is fast for one person. For a single competent user, nothing beats it.
Notice that every one of those strengths is about a single user in a single moment. That is the fault line. Spreadsheets do not break because they are spreadsheets — they break at the point where the business needs more than one person to be right at the same time.
Spreadsheets do not fail at a size. They fail at the moment two people need to be right simultaneously.
The five triggers
These are the ones that actually mean it. Each is a specific, observable event rather than a growth milestone.
Trigger one
A second location
Two stock positions, one business. From the day the second store, branch or warehouse opens, somebody is maintaining a copy and somebody is reconciling. Every month you delay makes the eventual opening balance harder to establish, because the two records diverge quietly and neither is provably right.
Trigger two
Money moving without a decision
Goods received against no order, payments made against no invoice, purchases nobody remembers approving. A spreadsheet cannot refuse anything — it records what it is told. Once spend needs to be prevented rather than reported, you have crossed out of what a spreadsheet can do at all.
Trigger three
Somebody external starts asking
A lender, a donor, an auditor, a large customer running due diligence, or a revenue authority. The question is always the same in substance: show me the evidence behind this. If assembling it takes a fortnight, you now have a business problem rather than an administrative one.
Trigger four
The person who knows it is a risk
One individual understands the workbook. They are competent, indispensable, and cannot take leave. This is a genuine business continuity exposure and it is usually the trigger owners recognise last, because the person in question is doing an excellent job.
Trigger five
Fiscalisation or a compliance deadline
Your revenue authority now requires invoices in a particular form, transmitted, or with a fiscal reference. This is the trigger with a date attached and it is the one most likely to force a rushed decision — which is why it is worth watching for before it becomes urgent.
Two things that look like triggers and are not
Both cause bad purchases, and both are common enough on this continent to be worth naming.
| Looks like a trigger | Why it is not | What to do instead |
|---|---|---|
| "We have grown, so we need a system" | Headcount and revenue do not create the failure. Two locations, unenforced spend, external scrutiny and key-person risk do. Plenty of large single-site businesses run perfectly well on disciplined spreadsheets, and plenty of small multi-site ones cannot | Check yourself against the five triggers. If none apply, spend the money on something that will move revenue |
| "Our competitor bought one" | You do not know whether it worked for them, and the failure rate in this category is not small. What you can see is the purchase; what you cannot see is whether people use it | Ask them, in detail and privately, what they would do differently. The answer is usually more useful than any vendor reference |
Why the move fails when it fails
Implementations rarely fail technically. They fail in a small number of recognisable ways, all of them avoidable and all of them decided before go-live.
- The opening balance was soft. Nobody counted properly, so every number afterwards is measured from a guess, and within a quarter people trust the spreadsheet more than the system — correctly.
- Capture stayed where it was. Transactions still get written on paper and keyed in the afternoon. The system now holds the same delayed data as the spreadsheet, at greater cost.
- The controls were not switched on. Approvals set to notify rather than refuse, because refusing was inconvenient in week two. The business bought a record-keeping tool and believed it bought governance.
- Everything was attempted at once. Nine modules in one quarter, no one owns any of them, and the project becomes something people survive rather than adopt.
- The spreadsheet stayed. Somebody still maintains it, "just to check". This is the surest single predictor of failure, and it is a symptom rather than a cause — it means somebody does not trust the system, and they are usually right about why.
The six weeks before you shortlist
Everything here is free, does not commit you to any vendor, and makes any eventual implementation dramatically more likely to work. Several businesses do this and discover they did not need to buy anything for another year, which is a good outcome.
-
Count everything, properly, once
A real physical count per location, reconciled and signed off. This is the single highest-value week of work available to you and it is worth doing whether or not you buy software.
-
Write down who may approve what
Four value bands, named approvers, and an emergency path. Two pages. If you cannot write it, no system can enforce it — and the writing usually surfaces disagreements that had been comfortably implicit.
-
Put every supplier in one list with one identifier each
Deduplicated, with tax identifiers, bank details and document expiry dates. Master data is the part of a migration that goes wrong, and it goes wrong because nobody owned it.
-
Run the reconstruction test
Pick a purchase from a year ago and try to assemble the requisition, approval, quotes, order, delivery note, invoice and payment. Time it. This number is your baseline and your business case.
-
Name one person who owns the outcome
Not a committee, and not the vendor. Implementations with an owner succeed at a visibly different rate from implementations with a steering group.
What you should expect to gain, and not
What AWRA OpsHub does today
- Stock that is a record rather than an estimate, because every sale and issue moves it at the moment it happens.
- Spend that can be refused, not merely reported — approval thresholds that block a transaction rather than notify someone about it.
- Evidence attached to the transaction, so the reconstruction test takes an afternoon.
- One version of a supplier, a customer, an item and an asset, rather than one per workbook.
- Cost that includes freight, duty and clearing, so pricing sits on a real floor.
- Continuity, because the business no longer depends on one person's understanding of one file.
- Capture where the work happens, including offline on a phone at a branch with no line.
What it does not do
- Not a strategy. A system reports what is happening; it does not decide what should.
- Not a replacement for discipline. A system with approvals switched to "notify" is a more expensive spreadsheet.
- Not instant. The first quarter is slower than the spreadsheet was. Anyone who tells you otherwise has not run one of these.
- Not a compliance guarantee. Outside Kenya we transmit nothing to any revenue authority and maintain no statutory payroll engine, so local specialists remain part of the arrangement.
- Not flexible in the way a spreadsheet is. A new column is a configuration decision rather than a keystroke. That constraint is most of the value, and it will still annoy people in month two.
The last line deserves emphasis because it is the honest trade. You are exchanging flexibility for agreement. A spreadsheet lets one person be right instantly; a system makes several people right at the same time, at the cost of some of that speed. If your business does not need the second thing yet, you should not pay for it.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a revenue authority pipeline, a bank or mobile money feed, a statutory return format or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax and e-invoicing pipelines
Electronic invoicing against your revenue authority's published interface, with the parts vendors gloss over — retries, a failure queue and a daily report of sales carrying no fiscal reference.
Banks, payments and mobile money
Statement feeds, payment gateways, bulk-payment files and collection accounts wired into the Payments Register so money in and out reconciles without re-keying.
Payroll and statutory returns
Payroll and social security schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedWhere to go next
The cost comparison itself — what running on spreadsheets actually costs, arithmetically — is in the true cost of spreadsheets, and the practical sequence in the ERP implementation checklist.
When you are ready to compare: the best ERP software for African businesses for the decision framework, what to budget by country for the money, and inventory management software for Africa for the module most businesses fix first.
Our take
Do not leave spreadsheets because someone said you should. Leave when a second location makes one stock position impossible, when spend needs to be prevented rather than reported, when an external party starts demanding evidence, when one person's knowledge has become a continuity risk, or when a compliance deadline arrives with a date on it. If none of those apply, keep the spreadsheet and spend the money elsewhere — and do the six weeks of counting, threshold-writing and master data work anyway, because it is free and it is the part that decides whether the eventual move works.
See what changes when records stop being estimates
One stock position across locations, approvals that refuse rather than notify, evidence attached at the point of entry, and capture that works at a branch with no connection.
Talk to us about your triggersFrequently asked questions
At what size should a business leave spreadsheets?
There is no size, and answering with a headcount or a revenue figure is how bad purchases get made. Plenty of large single-site businesses run well on disciplined spreadsheets, and plenty of small multi-site ones cannot. The move is triggered by specific events: a second location making one stock position impossible, spend that needs to be prevented rather than reported, an external party demanding evidence, one person's knowledge becoming a continuity risk, or a compliance deadline. If none of those has happened, the money is better spent elsewhere.
What is the single biggest cause of failed implementations?
A soft opening balance. If nobody counted properly before go-live, every number afterwards is measured from a guess, variance reports are meaningless, and within a quarter people trust the spreadsheet more than the system — which is a rational response to a system that is wrong. The count is a week of unglamorous work that nobody wants to schedule, it is free, and it is worth doing whether or not you ever buy software. Everything else in an implementation is recoverable; this one is not.
Should we keep the spreadsheet running in parallel for a while?
For a defined, short parallel run during cutover, yes — that is normal and prudent. Indefinitely, no, and if somebody is still maintaining it six months later "just to check", treat that as the most important signal in the project. It means somebody does not trust the system, they usually have a specific reason, and the reason is fixable if you go and ask. A permanent shadow spreadsheet is not a safety net; it is a symptom that quietly guarantees the system will never be relied on.
Will the business be faster immediately?
No, and anyone who says otherwise has not run one of these. The first quarter is slower: people are learning, capture is more disciplined than it was, and controls that used to be verbal now take an action. What changes in the second and third quarter is that the questions get easier — what stock do we have, what did that cost, who approved this, where is that asset — and those questions were previously being answered by a person, slowly, from memory and a file. Budget for the dip honestly.
What if we only have one location?
Then check yourself against the other four triggers before spending anything. Unenforced spend is the most common one for single-site businesses: goods arriving against no order, payments against no invoice, purchases nobody recalls approving. A spreadsheet fundamentally cannot refuse a transaction, so once the requirement is prevention rather than reporting, no amount of workbook discipline reaches it. External scrutiny and key-person risk are the other two that regularly apply to single-site businesses.
How much of this is specific to African businesses?
The triggers are universal; two of them just arrive earlier and harder here. Fiscalisation deadlines have moved faster across parts of the continent than in many mature markets, so compliance forces the decision more often and with less notice. And external scrutiny arrives sooner, because lenders and donors are a larger share of the funding base for growing businesses and both ask evidence questions that a spreadsheet answers slowly. The rest — locations, spend control, key-person risk — is the same everywhere.
What should we do first if we are not ready to buy?
Count everything properly, once, per location. Write down who may approve what in four value bands with a named emergency path. Deduplicate your supplier list into one record each with tax identifiers, bank details and document expiry dates. Then run the reconstruction test on a purchase from a year ago and time it. That is roughly six weeks, it costs nothing, it commits you to no vendor, and it is exactly the work that separates implementations that succeed from implementations that get survived.
