South Africa is not a normal retail market. Between rolling blackouts, inconsistent internet coverage outside major metros and a regulatory environment that includes B-BBEE scorecards and SARS-specific tax reporting, the requirements for a point-of-sale system here look nothing like what vendors in London or New York design for. Yet many South African retailers still run decade-old on-premise software that was never built for these conditions.
Cloud POS has become a mainstream category globally, but the conversation in South Africa has a different starting point. Retailers here do not ask "should we move to the cloud?" They ask "will it still work when Eskom drops us to Stage 6?" That question, more than any feature comparison, determines which systems survive in this market.
This article breaks down what South African retailers specifically need from a cloud POS, what goes wrong when you pick a system designed for stable-grid countries, and how to evaluate your options without getting buried in vendor marketing.
The Load Shedding Problem Is a Design Problem
Most cloud POS systems assume a persistent internet connection. When connectivity drops, they either freeze entirely or switch to a degraded mode that cannot process card payments, apply promotions or look up loyalty balances. In South Africa, where load shedding can knock out connectivity for two to four hours at a time, that degraded mode becomes the normal mode.
The solution is not simply "add a UPS." Battery backup keeps the hardware alive, but if the ISP or cellular tower also loses power, the POS terminal has no route to the cloud. A system designed for this market needs a local transaction engine that runs the full business logic offline, not just a queue that holds transactions until the connection returns.
POSibolt, for example, runs a complete offline engine at the terminal level. Every product rule, pricing tier, promotion and payment method works without a connection. When connectivity returns, the system reconciles automatically. This is not a fallback mode. It is the architecture. The distinction matters because fallback modes are where bugs hide. If a vendor only tests their offline mode occasionally, you will find the problems at the worst possible time.
Connectivity Beyond the Major Metros
Retailers expanding outside Johannesburg, Cape Town and Durban face a connectivity landscape that changes dramatically from suburb to suburb, let alone province to province. Fibre coverage is growing but remains concentrated in commercial zones. Many stores rely on LTE, which is shared bandwidth and subject to congestion during peak hours.
A cloud POS that requires low-latency connections for every transaction will create checkout bottlenecks in these locations. Customers notice. A three-second delay per transaction adds up to visible queues during lunch rushes, and visible queues drive foot traffic to competitors.
The practical requirement is a system that treats the cloud connection as a synchronisation channel rather than a dependency. Transactions should complete locally in under a second regardless of what the network is doing. Stock levels, pricing updates and reporting data sync when bandwidth is available. This architecture also reduces data costs, which matter when you are running multiple stores on LTE contracts.
Local Currency, Tax and Compliance
South African retailers deal with VAT at 15 percent, a rounding regime that rounds to the nearest five cents, and SARS reporting requirements that international POS vendors rarely support natively. Many retailers also need to track B-BBEE supplier spend at the transaction level, not just in a quarterly report.
Currency handling sounds trivial until you discover that your imported POS system rounds differently from what SARS expects, or that it cannot generate the specific tax invoice format your auditor requires. These are not edge cases. They are daily operational requirements.
When evaluating a cloud POS for South Africa, ask the vendor to show you a VAT invoice generated by their system, demonstrate how they handle the five-cent rounding rule, and explain how B-BBEE data is captured and reported. If the answers involve "custom configuration" or "we can build that," you are looking at months of implementation risk.
What to Look for in a South African Cloud POS
Start with offline capability and test it properly. Do not accept a demo over a fast Wi-Fi connection. Ask the vendor to disconnect the network mid-transaction and show you what happens. Process a sale, a return, a loyalty redemption and a split payment while offline. If any of those fail, the system is not ready for this market.
Second, check the local reference base. A POS vendor with 50 stores running successfully in Gauteng tells you more than a case study from a department store in Munich. Ask for retailer names you can call. Third, look at total cost of ownership including data costs. A system that chatters constantly over the network will run up significant LTE bills across a multi-store estate.
Finally, consider the support model. When your POS goes down at 8am on a Saturday in Bloemfontein, you need a support team that understands your time zone, your load shedding schedule and your specific configuration. Offshore support desks working European hours are not going to solve that problem.