Offline-first till
The catalogue is cached on the machine, so a barcode lookup is instant with no connection at all. Every sale is written to local storage before anything else can fail, then synced oldest-first when the line returns.
Product — built, not yet in a live shop
Prospra IQ. A till that keeps trading when the line drops.
Multi-tenant point of sale and light ERP for South African retail. One installation serves many independent businesses, each seeing only its own data — with a till that sells through a dead internet connection and books every cent correctly when it comes back.
The problem
Retail software assumes a connection that South African shops do not have.
Load-shedding takes the router. The fibre goes down for an afternoon. The line at a rural counter was never reliable to begin with. Most tills stop selling, and the shop reaches for a receipt book.
What comes back from that receipt book is a day of stock movements nobody recorded, VAT figures reconstructed from memory, and a gap in the invoice sequence that SARS will ask about.
Prospra IQ is built the other way round. The connection is treated as optional, not assumed — and the arithmetic is treated as the thing that must never be wrong.
Built for
- Grocers, general dealers and forecourt shops
- Hardware, agri and building supply counters
- Pharmacies and anywhere batch and expiry matter
- Multi-branch operators needing stock per location
The till
Fast enough for a queue.
Scan, tender, print, next customer. The screen a cashier actually looks at for eight hours — not a dashboard.
Prospra IQ · Till 2 · Working offline — 3 sales queued
Sale in progress
Cashier: T. Mahlangu · Branch: Main
| Item | Qty | Price | Line |
|---|---|---|---|
| Maize meal 12.5kg | 2 | R 189.99 | R 379.98 |
| Cooking oil 2L | 1 | R 79.95 | R 79.95 |
| Beef mince (0.842 kg) | 0.842 | R 129.00/kg | R 108.62 |
| Bread, white | 3 | R 21.50 | R 64.50 |
- Subtotal excl.
- R 550.48
- VAT at 15%
- R 82.57
- Total
- R 633.05
- Change
- R 66.95
Design preview of work in progress. Prospra IQ has not been commercially released and this is not a screenshot of a live installation.
What is in it
Twelve parts, one record.
A sale at the counter moves stock, posts to the ledger, allocates a tax invoice number and lands in the day’s Z-report — in one transaction that either completes entirely or not at all.
Safe replays
Each sale carries a unique id. Syncing the same sale twice returns the original — one sale, one invoice number, one stock movement. Tested including a replay carrying a different basket, which cannot overwrite what was booked.
Barcode scanning
Hardware scanners act as fast keyboards; the till tells a scan from typing by the gap between keystrokes. Fractional quantities to three decimals for weighed goods.
Payments
Cash, card, EFT, account, voucher and split. Change is calculated automatically, and a cash sale tendered below the total is refused rather than rounded.
Receipts & hardware
ESC/POS thermal printing, USB printers through the Windows spooler in RAW mode, and serial RS-232 with configurable baud — still common in South African retail. Cash drawer kick via the printer’s DK port.
Products & variants
A product can have many sellable variants — size, colour — each with its own SKU, barcode and price. Stock is held per branch, not per business.
Batch & expiry
Lot tracking with FEFO picking: the batch expiring first is sold first. Anything within 30 days of expiry is flagged before it becomes a write-off.
Goods received
GRV with weighted average cost recalculated to four decimal places on every receipt — two decimals accumulate drift across thousands of receipts. Cost is snapshotted at the moment of sale so margin reporting stays honest.
Inter-branch transfers
Dispatch and receive as separate steps, so stock in transit is visible instead of vanishing between two locations.
Customers & credit
Credit limits enforced at the point of sale. An account sale that would breach the limit rolls the entire sale back rather than letting it through.
Debtors ledger
Append-only. Invoices, payments and credit notes each carry a running balance snapshot, and no entry can be edited or deleted by anyone through any route.
Z-reports
The cashier declares the counted cash before seeing what was expected — a blind count is the only kind worth taking. Variance is a generated column nobody can edit, and closing the day locks it against voids and refunds.
How it is kept safe
A till on a counter is not a trusted machine.
It sits in a shop, runs on hardware you do not control, and is operated by whoever is on shift. The security model starts from that assumption rather than hoping otherwise.
Row-level security is the tenant boundary. Database functions are the integrity boundary.
Row-level security decides which rows you can see. It has no opinion on what values you write — which is why nothing stops a cashier recording a R199.99 sale as one cent unless something else does.
Tills cannot write financial records
Sales, stock movements and invoice numbers are created by a single database function that prices everything itself. The till sends what was sold and how much of it — nothing more.
Identity comes from the database
Never from the app, a request header or a token claim. A cashier who forges a header claiming to be an owner is still a cashier. A demoted staff member loses access immediately, not when their session expires.
A sale is all-or-nothing
Header, lines, stock and invoice number commit together or not at all. There is no state in which a completed tax invoice exists with no items on it.
Completed sales are immutable
Totals, timestamps, staff attribution and invoice numbers cannot be altered by anyone through any route. Corrections happen by void or refund, both audited — never by editing history.
Money is not a floating-point number
South African shelf prices are VAT-inclusive, so VAT is extracted rather than added. All money is handled as exact integers or database numerics, never floats.
The same arithmetic is implemented in the database and in the till, and the system checks the two against each other on every single sale — refusing to save one where they disagree. An on-screen total and a stored total cannot drift apart.
- 212 automated tests, with every database test running as a genuine restricted user — an administrator bypasses the very controls being tested.
- 11 deployment gates that refuse the rollout if the security model has drifted.
- Negative stock is allowed on purpose — an offline till can legitimately sell goods the server has not seen received, and it reconciles on the next delivery.
- Gap-free sequential tax invoice numbers per merchant, allocated at completion — never at cart creation, which would burn a number on every abandoned basket.
- VAT201 report producing the real return fields: standard-rated and zero-rated supplies, output tax, input tax, net VAT payable.
- Built-in reconciliation — every recorded VAT total is cross-checked against a recalculation from the underlying lines, and sequence gaps are reported.
- Five-year retention of tax records.
- POPIA erasure register with the statutory 30-day clock. Erasure pseudonymises rather than deletes, because five-year retention and the right to erasure genuinely conflict.
- No personal data in logs or URLs, and rate-limit identifiers are hashed — an IP address is personal information.
Compliance
The parts SARS and the Regulator actually ask about.
Not a compliance module bolted on at the end. Sequential numbering, retention and erasure are properties of the data model, which is the only place they can be enforced rather than promised.
The erasure-versus-retention position is the standard resolution of a real legal conflict, and is worth a lawyer’s confirmation before you rely on it.
Plans
Three tiers. Pricing not yet set.
What sits in each tier is decided; what it costs is not. Early access merchants get preferential terms at launch.
| Feature | Starter | Professional | Enterprise |
|---|---|---|---|
| Branches | 1 | 3 | Unlimited |
| Users | 3 | 15 | Unlimited |
| POS, offline sync, receipts, Z-reports, basic stock | ✓ | ✓ | ✓ |
| Batch & expiry tracking | — | ✓ | ✓ |
| GRV & weighted average costing | — | ✓ | ✓ |
| Debtors ledger | — | ✓ | ✓ |
| Multi-branch | — | ✓ | ✓ |
| Advanced reports | — | ✓ | ✓ |
| Inter-branch transfers | — | — | ✓ |
| Accounting package sync | — | — | ✓ |
| Online store sync | — | — | ✓ |
| API access | — | — | ✓ |
Status, honestly
What is proven, and what is not.
Everything proven so far is proven at the layer below the screen. The next milestone is not more code — it is one real transaction, start to finish.
| Component | State |
|---|---|
| Database schema and security model | ✓ Built and adversarially tested |
| Business logic — VAT, costing, FEFO, ledger, Z-reports | ✓ Built and tested |
| Web back-office | ✓ Builds cleanly |
| Desktop till | ✓ Compiles, unit tests pass |
| Receipt printing | ⚠ Written and type-checked — never printed to real hardware |
| Integrations | ⚠ Built — never run against a live provider account |
| Used by a person in a real shop | ✗ Never. No sale has been made through the interface |
Before any merchant runs their shop on it, we complete point-in-time database recovery, a tested backup restore, secrets in a managed store, a code-signing certificate so the installer does not warn you, and legal confirmation of the erasure position.
We will tell you when those are done. We will not tell you they are done before they are.
Questions
What merchants ask us.
Including the answers that cost us the sale. A till is not something you find out the truth about in month three.
Can I run my shop on it today?
No. The database, the business logic and the security model are built and tested. The web back-office builds and the desktop till compiles. But no sale has been made through the interface by a person — not one. We are looking for a first merchant to run it alongside their existing till, not instead of it.
What actually happens when the internet goes down?
The till keeps selling. The product catalogue lives on the machine, so scanning is instant with no connection. Every sale is written to local storage before anything else can fail, and syncs when the line comes back — oldest first, backing off if the server is struggling.
The replay window is seven days by default and can be set up to thirty. Syncing the same sale twice is safe: it returns the original rather than creating a second one.
Can a cashier change a price or edit a past sale?
No, and not by tampering with the app either. The till never decides prices, VAT, totals or invoice numbers — it sends what was sold and how much of it, and the server prices everything from the catalogue. Local storage is editable from a browser’s developer tools, so nothing financial is trusted from it.
Role comes from the database on every operation, not from the app or a token. Voids and refunds are manager-and-above, need a written reason, and write an audit record that cannot be edited or deleted.
Will it work with my existing receipt printer?
It is written for ESC/POS thermal printers over USB and serial RS-232, including the older serial units still common in South African shops. Honest caveat: the printing code is written and type-checked but has never printed to real hardware. Getting it onto a real printer at a real counter is exactly what the first pilot is for.
Does it produce SARS-compliant tax invoices and VAT201?
Yes. Invoice numbers are gap-free and sequential per merchant, allocated when a sale completes rather than when a cart opens — opening a cart and abandoning it would otherwise burn a number, and a missing number is an audit finding.
The VAT201 report produces the actual return fields, and cross-checks every recorded VAT total against a recalculation from the underlying lines, reporting any gaps in the sequence.
Can I issue a credit note?
Partial refunds work as a mechanism — you return specific quantities of specific lines, priced at what the customer originally paid rather than the current shelf price, and cumulative refunds can never exceed what was sold.
It is not yet a SARS credit note. Credit notes have specific serial-number and invoice-reference requirements, and we are not printing something and calling it a credit note until an accountant has signed it off.
Does it sync to my accounting package or online store?
Connectors for the major accounting packages and online store platforms are built — inbound stock webhooks with signature verification and replay protection, journal mapping for accounting, and credentials encrypted with AES-256-GCM behind a key that never reaches the database or the browser.
None of them has been run against a live provider account. Treat them as ready to test, not as proven. Tell us which one you use and it goes to the front of the queue.
What will it cost?
Pricing is not finalised. The plan structure below shows what is in each tier. Early access merchants get preferential terms in exchange for real feedback from a real counter — which is worth considerably more to us right now than the subscription.
Next step
We are looking for one shop to go first.
Run it beside your existing till, not instead of it. You get the system at preferential terms for as long as you use it; we get the thing no amount of testing produces — a real counter, a real queue, and a real month-end.