A cloud POS suits you if you run several sites across provinces and your internet has real redundancy behind it. An SQL-backed on-premise POS suits you if you trade through load shedding, want your customer database in your own hands for POPIA, and would rather pay once in rand than carry a monthly subscription that reprices every time the exchange rate moves. For most single-site and small-cluster South African retailers and restaurants, the SQL-backed system wins on the two things that actually cost money here: staying open during an outage, and what you have spent by year three.
Where the sale gets written
The question is where a sale gets committed while a customer is standing in front of you with a basket.
A pure cloud POS writes that transaction to a remote database over the internet. The till is a browser or a thin client, so no connection means no sale. An SQL-backed POS such as TimeWorks writes it to a Microsoft SQL Server database on a machine on your premises, and the only network involved is your own LAN. Internet still does the work you would expect of it, including reporting, backup and pulling branches together, but it plays no part in ringing up bread and milk.
Offline resilience, POPIA control, data portability and cost all follow from where that write lands.
What load shedding actually breaks
A UPS keeps your tills alive. It does nothing for the path to a remote database.
During load shedding, fibre exchange equipment and street cabinets usually stay up on their own batteries for a while, but those batteries drain over successive stages. LTE fallback then contends with every other backup router in the suburb switching over at the same moment. What you actually get is a till that boots, shows a spinner, and will not close the sale.
South Africa recorded load shedding on 329 days in 2023, the worst year on record, and outages have continued intermittently since.
Source: Council for Scientific and Industrial Research (CSIR), Statistics of Utility-Scale Power Generation in South Africa 2023.
An SQL-backed till carries on trading. The sale writes to the local SQL Server instance, the slip prints and the drawer opens. When the connection returns, cloud reporting and off-site backup catch up on their own. Our guide to how a SQL Server POS protects data during busy trading covers the transactions, logging and backups behind this.
Put this to any cloud vendor during the demo: pull the internet cable, then complete a sale, process a refund and run an end-of-day cash-up. Ask what happens to the offline-queued transactions if the till reboots before the connection comes back.
Cloud POS and SQL-backed POS on the criteria that decide it
| Criterion | Cloud POS | SQL-backed POS (TimeWorks) |
|---|---|---|
| Where a sale is committed | Remote database over the internet | Microsoft SQL Server on your premises, over your LAN |
| Trading during a total internet outage | Degraded or stopped, depending on offline mode | Full trading, unaffected |
| Dependency during load shedding | UPS plus a working fibre or LTE path | UPS for the till and server only |
| Who holds the database | Vendor, often in an offshore data centre | You, on hardware you own |
| POPIA operator relationship | Vendor is an operator; needs a written agreement under section 21 | Fewer third-party operators in the chain |
| Data portability if you leave | Whatever export the vendor provides | Full SQL backup file, restorable anywhere |
| Cost model | Recurring subscription per till or per site | Once-off licence plus optional annual support |
| Currency exposure | Often USD-linked, reprices with the rand | Priced and quoted in rand |
| Multi-site live visibility | Native and immediate | Via branch consolidation and cloud reporting add-ons |
| Support when a till is down at 17:00 on a Friday | Ticket queue, often offshore time zones | Cape Town team, same-day on-site attendance in the metro |
POPIA: who carries the risk
Both models can be POPIA-compliant. Where they differ is your position when something goes wrong.
Under POPIA you remain the responsible party for your customers' personal information no matter who hosts it. A cloud POS vendor is your operator, and section 21 requires a written contract obliging them to maintain the security safeguards in section 19. Section 22 requires you to notify the Information Regulator and the affected data subjects where there are reasonable grounds to believe personal information has been accessed by an unauthorised person. With a cloud POS you find out about that breach when the vendor decides to tell you.
Source: Protection of Personal Information Act 4 of 2013, sections 19, 21 and 22.
Section 72 permits transfer of personal information outside South Africa only where conditions are met, such as an adequate level of protection in the recipient country, the data subject's consent, or contractual safeguards. If your vendor's servers sit in Europe or the United States, get that answered in writing before you sign, rather than during an audit.
Source: Protection of Personal Information Act 4 of 2013, section 72.
With an SQL-backed system the customer database sits on your server. You decide who has credentials, where backups go and how long records are kept. When you eventually change POS vendor, your data leaves with you as a standard SQL Server backup file, not as whatever CSV export a departing vendor feels like producing.
SARS, VAT and getting records back
Whichever model you pick, the tax obligations are identical and they are not optional. A tax invoice must contain the particulars set out in section 20(4) of the VAT Act: the words "tax invoice", "VAT invoice" or "invoice", the supplier's name, address and VAT registration number, an individual serialised number, and the date of issue. Records must be kept for five years.
Source: Value-Added Tax Act 89 of 1991, section 20(4); Tax Administration Act 28 of 2011, section 29.
The difference shows up at retrieval. When SARS queries a transaction from three years ago, an SQL-backed system lets your accountant or our support team query the database directly and produce the record. On a cloud system your access to historical data typically ends when your subscription does, while your retention obligation runs the full five years either way. Ask any cloud vendor what happens to five years of tax records if you stop paying.
What it costs by year three
Cloud pricing looks cheaper because the comparison usually gets made against the first month rather than the fifth year. Model it properly across three years and include every recurring line: subscription per till, subscription per site, payment gateway fees, hardware refresh cycles, and the backup connectivity you now need because the system cannot trade without internet.
Two rand-specific factors get left out of imported comparison articles. Subscription pricing from international vendors is frequently USD-denominated or USD-indexed, so a weakening rand raises your POS bill without anything changing on your side. A once-off licence quoted in rand holds its price. And a once-off purchase is a capital item you own, where a subscription is an operating cost that never converts into an asset and never stops.
We do not publish generic price ranges here, because the honest number depends on your till count, sites, integrations and hardware. Ask us for a written three-year total cost of ownership on your actual configuration, and ask your cloud shortlist for the same thing on theirs. Compare those two documents rather than two monthly figures.
Payments and integrations
Your POS has to talk to the card machines and gateways that actually operate in this market. That means integrated card acquiring through the major local banks and independent providers, and support for the payment methods your customers already use.
Verify integration by name with every vendor you shortlist. Then confirm which kind it is: true till-to-terminal communication, where the amount is pushed to the card machine and the result returns to the sale, or a manual tender type where a cashier keys the amount a second time and can key it wrong. That one distinction decides whether your cash-up balances at the end of the day.
Which one is right for you
Go cloud if you operate multiple sites in different provinces and need consolidated numbers within minutes rather than at end of day, your connectivity has genuine automatic failover, and you would rather carry a monthly operating cost than a capital one. You should also be comfortable with your customer database living in a data centre you do not control.
Go SQL-backed if a fibre break or a Stage 6 evening cannot be allowed to stop you trading. The same applies if you want direct control of customer data and a clean POPIA position, if you need five years of tax records accessible on your own terms, or if you plan to run the system for five years or more, which is the point where a once-off rand licence overtakes an escalating subscription.
TimeWorks is built on the second model with the useful part of the first. Transactions commit locally against Microsoft SQL Server, so you trade through anything, and cloud reporting and off-site backup are available as add-ons when you want the dashboard on your phone.
Why a Cape Town supplier matters at 17:00 on a Friday
TimeWorks has supplied and supported point-of-sale systems from Cape Town since 1999. When a till stops during month-end trading, the gap between a local supplier and an offshore support queue gets measured in hours of lost revenue. We answer during South African business hours, we know what a Stage 6 schedule does to a retail floor, and we can be on site in the Cape Town metro the same day. A ticket answered at 02:00 does not get your till trading again on Friday afternoon.
Common questions
Partly, and only if you pay for the redundancy. You need a UPS or inverter for the tills, router and switch, plus an internet path that survives the outage, usually fibre on a backed-up exchange with an LTE failover SIM. Even then, LTE congests when every backup router in the suburb fails over at the same moment. Some cloud systems offer an offline mode that queues sales locally. Before you rely on it, test three things during the demo with the connection pulled: can you complete a sale, can you process a refund, and do queued transactions survive a till reboot before reconnection. An SQL-backed system removes the question, because the sale never needed the internet.
It can be, but you carry the responsibility either way. You remain the responsible party under POPIA; the vendor is your operator, and section 21 requires a written contract binding them to the security safeguards in section 19. Get four things in writing before you sign: which country the servers sit in and how section 72 cross-border transfer is satisfied, how fast they notify you of a breach so you can meet your own section 22 obligation to the Information Regulator, what personal information they keep after termination, and exactly what export format you receive on the way out. With an on-premise SQL database you control access, backups and retention directly, and the export question never comes up.
TimeWorks is an SQL-backed on-premise POS with cloud-connected reporting and backup available as add-ons. Transactions process locally against Microsoft SQL Server, so trading continues through a power or connectivity failure, while cloud reporting dashboards and off-site backup synchronisation give you remote visibility when the link is up. That hybrid shape is the practical answer for most South African businesses: local reliability where a failure costs you sales, cloud convenience where it only costs you a refresh.
Ask this before you sign, because it is the clause most often skipped. Cloud vendors typically cut access at the end of the paid period, with a limited grace window to export. Your SARS obligation to keep records for five years under section 29 of the Tax Administration Act carries on regardless of whether your subscription lapsed. Ask, in writing, how long data is retained after cancellation, what format the export takes, and whether historical reports stay accessible. With an SQL-backed system the database is already yours: a standard SQL Server backup restores anywhere, with or without a relationship with the vendor.
Usually yes, though the effort depends entirely on what your current vendor will export. Product catalogue, stock levels, supplier records and customer data are normally exportable in CSV and can be imported into a new system. Full transaction history is the harder part, and it is often only available as reports rather than raw data, which is why we recommend exporting and archiving your history before you cancel. Talk to us before you give notice, because the migration is far cleaner while you still have live access to the old system.
See TimeWorks running offline, on purpose
Book a free demo and ask us to pull the internet connection mid-sale. We will walk you through the features that matter to your business, answer your comparison questions honestly, including where a cloud system would genuinely suit you better, and give you a no-obligation quote in rand with full three-year cost of ownership figures.