Cloud ERP in Africa: Connectivity, Offline Mode & Data Residency
Three questions vendors answer with the wrong facts. "Is it cloud" is not about uptime, "does it work offline" is not about caching, and "where is our data" is not a yes-or-no. What to demand in a demo, what a duplicate-safe sync actually requires, and how to ask about residency so the answer is checkable.
Ask an African buyer what worries them about cloud software and you will get three answers: what happens when the power goes, what happens when the line goes, and where the data actually lives. Ask a vendor the same three questions and you will get one answer to all of them — a data centre, a service level, an availability percentage.
That answer is true and it addresses none of the questions. The vendor's data centre staying up was never the issue. Your branch, your warehouse, your field team and your regulator were the issue.
Question one: what "cloud" actually buys you
It is worth being precise, because the value is real and it is not the value usually advertised.
What cloud genuinely gives you
- No server in your building to power, cool, patch, back up or replace — which in many locations removes the single largest operational risk in the stack.
- Access from anywhere, so a branch, a site and a director travelling are looking at the same data.
- Updates that arrive without a project.
- Someone else's job to keep it running, with a contract behind it.
What cloud does not give you
- Immunity from your own connectivity. If the branch has no line, the branch has no system — hosting is irrelevant.
- Immunity from your own power. A charged device works during an outage; a desktop does not.
- A data residency position. Cloud is a delivery model, not a location.
- Lower total cost by default. It changes the shape of the spend, not necessarily the size.
The first column is a strong argument on this continent, and it is a stronger argument than most vendors make — an on-premise server in a building with unreliable power and no dedicated administrator is a genuinely bad idea, and the cloud alternative removes an entire category of failure. Just do not let it be offered as an answer to the next two questions.
Question two: offline, and what it really requires
"Works offline" is claimed widely and means at least four different things, ranging from useful to actively harmful. Here is the ladder.
What "offline" can mean, worst to best
A cached read-only view
You can look at yesterday's data. You cannot record anything. Useful for a director on a plane, useless for a storekeeper receiving goods.
Local capture with no conflict handling
You can record, and when you reconnect it overwrites whatever happened meanwhile. Worse than nothing, because it destroys data confidently.
Queued capture with duplicate protection
Each operation carries its own client-side identifier, so a retry, a double-tap or a partial sync cannot produce the same receipt twice. This is the minimum viable version.
Queued capture with conflict surfacing
When queued work collides with a change made online meanwhile, the collision is reported rather than resolved silently, and a human decides.
Administrative visibility over the fleet
Someone can see which devices are behind, how many operations are queued, what failed, what conflicted, and when each device last checked in — before month end rather than during it.
The second row is the one to test for. A system that accepts offline work and then applies it blindly on reconnection will, sooner or later, silently reverse a correction somebody made at head office. Ask the vendor what happens when two people change the same record from opposite sides of a connectivity gap, and be unsatisfied by an answer about "last write wins".
How to test it in twenty minutes
The offline demo script
- Put a device in airplane mode. Record a goods receipt, an issue and a stock count.
- While it is offline, change the same item from a second device that is online.
- Reconnect the first device. Watch the sync happen in front of you.
- Confirm nothing was recorded twice — particularly the receipt.
- Confirm the collision was reported to someone rather than silently resolved.
- Ask to see the administrator's view: which devices are behind, what is queued, what failed.
- Ask how long a device may stay offline before it must re-authenticate.
- Ask what the maximum queue size is, and what happens when it is exceeded.
A vendor who can run that script in front of you has built the thing. A vendor who describes it has not necessarily, and the gap between those two is where implementations fail in month four rather than month one.
Their uptime is not your branch's power. Ask whether a storekeeper with a charged phone can keep working, and whether the work arrives once.
Question three: data residency, without hand-waving
Data protection regimes across the continent — and there are many, at very different stages — put obligations on you rather than on your software vendor. That is the fact most vendor conversations avoid, because it makes "we are compliant" an incoherent sentence.
"Where does our data live" is also not a binary. Here is the spectrum you are actually choosing on.
Where operational data physically sits
On-premise, self-hosted
Maximum control and every consequence of it: your power, your backups, your patching, your physical security, and your administrator who resigned.
Hosted in-country
What most residency-anxious buyers assume they are getting. Available in some African markets and not others. Ask explicitly, and get the region named in the contract — an assumption is not a control.
Hosted in a regional cloud region
On the continent but not in your country. Frequently satisfies commercial concerns and may or may not satisfy a specific regulator. Your advisers decide, not your vendor.
Hosted elsewhere, with contractual safeguards
Lawful in most jurisdictions subject to conditions for cross-border transfer. Where AWRA OpsHub sits — ask us for the current region in writing before you sign.
None of these positions is automatically right or wrong, and none of them makes a vendor "compliant" with your national data protection law — those obligations attach to you as the responsible party, informed by what your provider can demonstrate. Get the hosting region, the access model, backup retention and exit terms in writing from every vendor you shortlist, including us, and have your own advisers assess them against your specific data. Nothing here is legal advice.
The four questions that produce checkable answers
Residency and exit, asked properly
Where is our data hosted today, by region?
What you will hear
Sometimes a clear answer, often a reference to a global cloud provider.
How to read it
Naming the provider is not naming the region. Ask for the region, in the contract or a signed document, and ask what notice you get if it changes.
Who at your company can read our data, and under what process?
What you will hear
A reference to encryption and access controls.
How to read it
Encryption at rest does not answer it, because support staff routinely need access to help you. Ask about the approval process, whether access is logged, and whether you can see the log.
How long are backups kept, and where?
What you will hear
A retention period.
How to read it
Then ask where the backups sit. A residency position that does not cover backups is not a residency position — and this is the question that most often surfaces a different answer from the primary one.
What exactly do we receive if we leave?
What you will hear
An export, in some format.
How to read it
Get the format, the scope and the timeframe in writing. "A database dump" and "your documents, with their links to the transactions intact" are extremely different things, and you will only care about the difference once.
The straight answer
What AWRA OpsHub does today
- Offline capture on mobile for receipts, issues, counts, transfers, asset movements, verifications and field work.
- Duplicate-safe sync — each queued operation carries a client-side identifier, so retries and partial syncs cannot record the same transaction twice.
- Conflict surfacing rather than silent resolution, including where a form's field definitions changed while a device was offline.
- A device register showing platform, version, last check-in, queued count, failed count, synced count and last error for every device.
- Trusted-offline windows with an expiry, so a device cannot stay authenticated offline indefinitely.
- Optional GPS capture — latitude, longitude, accuracy and timestamp — recorded against an operation, evidencing where the work physically happened.
- An administrator screen for offline operations, gated behind a device-trust permission.
What it does not do
- No in-country hosting option today. We host in one region and will tell you which in writing; if your regulator requires in-country data, that is a constraint you should raise before signing.
- No on-premise deployment. We do not ship a version you run on your own server.
- No offline desktop client. Offline capture is a mobile capability; the browser interface requires a connection.
- No compliance certification against national data protection laws. We can describe where data sits and who can reach it; the assessment is yours.
- No offline reporting. Queued devices capture; they do not run analysis against data they do not hold.
The residency line is the one worth pressing us on, and we would rather have that conversation before a contract than after. If in-country hosting is a hard regulatory requirement in your market, say so at the first meeting — it is a legitimate reason to choose someone else, and finding out in month three helps nobody.
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 integratedPractical measures that cost almost nothing
-
Put capture on phones, not desktops
A charged phone works through a power cut and a fibre break. A desktop in a warehouse office does not. This single decision does more for continuity than any hosting arrangement.
-
Give remote locations their own devices, not shared logins
Shared logins destroy attribution, and attribution is the entire point of a governed record. Per-person devices also make the offline device register meaningful.
-
Review the device register weekly
Ten minutes. A device that has not checked in for nine days is holding transactions nobody has seen, and you would much rather learn that on a Tuesday than at month end.
-
Get residency, access, retention and exit in writing before signing
From every vendor. The exercise takes an afternoon and it is the cheapest risk work available to you.
-
Test your exit once, early
Run the export in the first quarter, while you still have leverage and attention. An exit clause nobody has exercised is a promise, not a capability.
Where to go next
The continental buying framework is in the best ERP software for African businesses, and the operational half that depends most on offline capture is in inventory management software for Africa.
The market-specific treatments of interruption and connectivity: manufacturing around a published interruption schedule in South Africa, mining and industrial supply and humanitarian logistics in low-connectivity environments.
Our take
Refuse to let uptime answer three different questions. Cloud genuinely removes the server from your building and that is worth having. Offline is a capture capability with a specific technical requirement — an identifier per operation so nothing arrives twice, conflicts reported rather than resolved silently, and an administrator who can see the fleet — so test it with a device in airplane mode rather than accepting a description. And treat residency as four written questions about region, access, backups and exit, asked of every vendor including us, because the answer that matters is the one you can put in front of your own advisers.
See offline capture that actually syncs cleanly
Receipts, counts and field work captured without a connection, queued with their own identifiers so nothing arrives twice, conflicts surfaced to a human, and a device register that shows you who is behind.
Ask for the offline demoFrequently asked questions
What happens when the internet goes down at a branch?
Capture continues on mobile devices. Receipts, issues, transfers, counts, asset movements and field work are recorded on a phone or tablet and queued locally, syncing when the device reaches a signal. Each queued operation carries its own client-side identifier, so a retry or a partial sync cannot record the same transaction twice, and collisions with changes made online meanwhile are surfaced to an administrator rather than resolved silently. The browser interface does require a connection — offline capture is a mobile capability.
How do we know a device has not been sitting offline for a fortnight?
There is a device register that records, per device, the platform and app version, when it last checked in, how many operations are queued, how many failed, how many synced and the last error reported. Administrators with the device-trust permission see it on a dedicated screen. Reviewing it weekly takes about ten minutes and is the difference between discovering a stalled device on a Tuesday and discovering it during month-end close, when everything else is also happening.
Can a device stay logged in offline indefinitely?
No. Trusted offline access carries an expiry, so a device that has been away from a connection beyond the permitted window has to re-authenticate rather than continuing to record indefinitely. This is a deliberate trade-off between field usability and control: a lost or stolen device that never reconnects should not remain a working terminal, and a queue that has grown for weeks without anyone seeing it is a governance problem regardless of whether the data eventually arrives.
Where is our data hosted?
In a single region, which we will name in writing on request — ask before you sign, and ask the same of every vendor you shortlist. There is no in-country hosting option today and no on-premise deployment. What we will not tell you is that our product makes you compliant with your national data protection law: those obligations attach to you as the responsible party and depend on your data and your purposes. Get region, access model, backup retention and exit terms as a document, and have your own advisers assess them.
Is "cloud" cheaper than running our own server?
It changes the shape of the spend more reliably than it changes the size. What it removes is a category of risk rather than a line of cost: no server in your building to power, cool, patch, back up, secure and eventually replace, and no dependency on one administrator who understands how it was configured. In locations with unreliable power and no dedicated IT staff, that risk removal is usually the stronger argument, and it is a better reason to choose cloud than a cost comparison that depends heavily on assumptions.
What happens if two people edit the same record on either side of a connectivity gap?
The collision is detected and surfaced, not resolved silently. Queued operations arriving from a device are checked against the current state, and where the offline work conflicts — including cases where the definitions behind a form changed while the device was away — the operation is marked as a conflict for a human to resolve rather than applied over the top. This matters more than it sounds: silent last-write-wins behaviour will eventually reverse a correction somebody made deliberately, and nobody will know.
What do we get if we leave?
Ask for it in writing before you sign, and be specific about scope and format — this is the question buyers postpone and then only ask once, at the worst possible moment. There is a large practical difference between a database export and a package where documents remain linked to the transactions they belong to. Our advice, applied to us as much as anyone: run the export once in your first quarter, while you still have attention and leverage. An exit clause nobody has exercised is a promise rather than a capability.
