Your books, your data,
in your country
Accounting data is the most sensitive thing most businesses hold: what you earn, who you pay, what your staff take home. This page explains, in plain terms, how we protect it, so you can check it against what your auditor or your board asks for.
Where your data lives
Ledgr runs in Google Cloud's africa-south1 region — Johannesburg.
Your ledger, your documents and your uploaded files stay in South Africa. That matters for
two reasons: POPIA places conditions on sending personal information across borders, and a
database in the same country as its users responds faster.
In transit
Everything is HTTPS. The app, the API and the webhooks all refuse plain HTTP, and the browser is told to keep using TLS on subsequent visits.
At rest
The database and the file storage are encrypted at rest by the platform, with keys managed by Google Cloud rather than sitting in our configuration. Merchant credentials and 2FA seeds get a second layer on top, encrypted by Ledgr before they reach the database.
Backups — the platform's
The managed database takes automated backups with point-in-time recovery. They stay in the same region as the data they came from. These are for our own disaster recovery; for copies you control, see the two tiles below.
Uploaded files
Receipts, product photographs, signatures and logos live in private object storage, one namespace per business, never public. A file is served by a link signed for you, for that one file, that expires — there is no URL anyone can guess or share indefinitely.
Backups — yours
Ledgr keeps its own copies of your books, off your device, on every plan including the free one. Nothing to buy, nothing to switch on, and they do not count towards your storage allowance. Daily, weekly or monthly, kept for as long as you choose, and every one of them downloadable from Settings → Data. See the guide.
Putting records back
A backup is not only a file to keep — it restores. Ledgr can add back records your books no longer have, and it only ever adds: it never overwrites a live row, never deletes, and refuses anything edited since the backup was taken rather than reverting somebody's work. You see exactly what it would put back before it writes anything. See restore.
Your own copy, on demand
Settings → Data → Export all data gives you a ZIP of CSVs whenever you want one, on every plan, with no notice period and nothing to ask for — including the general ledger. Pushing a scheduled copy to storage you control is not built; the automatic backups above and this download are what exist today.
One database, strictly separated books
Ledgr is multi-tenant: many businesses share the same infrastructure, the way every cloud accounting product does. What keeps them apart is that every row of every table carries the id of the business it belongs to, and every query the application makes is scoped to the id on your signed session token.
- Your session token carries your business id — it is not something the browser can ask to change
- The database enforces it too, underneath the application. Every request made with your session runs on a database role that has your business id pinned to it for the life of that query and cannot read another business's rows even if a query were written wrongly. This is a second line of defence: the application's own filters are the first, and this one catches any mistake they would otherwise let through
- Records are soft-deleted, so a deletion is reversible and auditable rather than a hole in the ledger
- Within a business, multi-company customers get a second layer: each entity's transactions are scoped to that entity, and only the group view brings them together
- Uploaded files — receipts, logos, attachments — are namespaced per business in the same way
Who can do what, and how they prove who they are
Twelve roles, nineteen modules, six actions per module. The matrix is visible in the app, and it is the same matrix the server enforces — the UI hides what you cannot do, and the API refuses it independently.
Twelve roles
Owner, Admin, Accountant, Sales, Viewer, Payroll Manager, Tax Practitioner, External Auditor, Buyer, Production Planner, Fleet Controller and Driver — or build your own with per-module checkboxes.
Six actions per module
View, create, edit, delete, approve and export are separate permissions. Someone can see payroll without being able to approve it, or export reports without being able to change them.
Two-factor authentication
Available to every user on every plan, with adoption across your team visible to the Owner. Enrolling issues ten single-use recovery codes, shown once — a lost phone is not a lost account.
A way back in
If the codes are gone too, an Owner or Admin can reset another user's 2FA. They must confirm with their own 2FA code and cannot reset their own. The reset signs the affected user out everywhere and is recorded in the audit log as a warning.
Session management
Active sessions are listed per user and can be revoked individually. A revoked session stops working on its next request, not at some later expiry.
Scoped API keys
Keys are generated per integration with permissions per module, and can be revoked without disturbing anyone's login. See the developer hub.
Policy settings
Session timeout, password rules and lockout after repeated failures are set once for the business rather than left to each user.
Switch on 2FA for the Owner account and for anyone with payroll or banking access. Most accounting-software break-ins are not sophisticated — they start with a password reused from another site. There is more on roles and invitations in the roles and users guide.
The audit log
Every action that changes something material is written to an append-only event log with the actor, the resource, the time and a severity. Sign-ins, permission changes, invoice edits, payroll approvals, data exports, API key creation and deletions all land there.
- Filterable by severity — information, warning and error — so a review does not mean reading everything
- Kept for seven years by default, the period the Companies Act sets for company records, and then deleted — the check runs once a day. An Owner or Admin can choose a different period under Roles & Permissions → Security, never shorter than the five years the Tax Administration Act requires records to be kept
- Visible to Owner and Admin roles, and exportable for an auditor who wants it in their own working papers
- Written by the server, not the client, so it records what actually happened rather than what the interface reported
An External Auditor role exists precisely for this: read and export across the financials, no ability to change anything, no access to user administration.
Protection of Personal Information Act
Running a business means holding personal information about customers, suppliers and staff. POPIA makes you the responsible party for it. Ledgr is built to help you meet those obligations.
Scroll the table sideways to see every column.
| What POPIA expects | What Ledgr gives you |
|---|---|
| Purpose limitation | Ledgr processes your data to run your accounts. It is not sold, not shared with advertisers, and not used to train anything. |
| Security safeguards | Encryption in transit and at rest, per-business isolation enforced in the application and in the database, role-based access, 2FA with recovery codes, session revocation and lockout policies. |
| Data subject access | Every contact and employee record is viewable and printable, so a request for "what do you hold about me" can be answered from one screen rather than becoming a project. |
| Data portability | Settings → Data → Export all data — contacts, invoices and lines, expenses, bills, products and time entries as CSVs in a ZIP, on any plan. |
| Right to deletion | Records can be deleted from the app. Financial records are soft-deleted — taken out of your working views and kept with their audit trail — because SARS and the Companies Act override a deletion request for records of a transaction. |
| Records a law requires you to keep | POPIA lets a record be kept for as long as another law requires it. The audit log is kept for seven years by default, the Companies Act period, and never less than the five years the Tax Administration Act requires; after that it is deleted. |
| Retention limitation | If you stop paying, your books stay readable for one month — export anything you need. After that the account can be closed for good: every uploaded file and Ledgr's backups of the account are deleted, every user's sign-in details are erased, and nothing can be opened through Ledgr again. The records you typed in are not erased; they stay in Ledgr's database, closed off. Warnings go out at 21, 7 and 1 days naming the date, which is the earliest the account can be closed. Details in the privacy policy and the billing guide. |
| Accountability | The audit log shows who accessed and changed what, which is what an information officer needs when a complaint arrives. |
If a customer asks you to erase their personal information, you can remove marketing and contact details — but you cannot destroy the tax invoices you issued them. That is not a Ledgr limitation; it is the Tax Administration Act. Ledgr's soft-delete keeps the transaction and its audit trail while taking the record out of your working views.
People who see something without having a login
Your customer paying an invoice or asking for a quote, your employee fetching a payslip, your supplier sending you an invoice, your driver running the day's route — none of them is a user of your Ledgr account, and none of them costs you a seat. Each reaches only their own dealings with you, through a signed link, and nothing they send commits your business until somebody on your side accepts it.
Scroll the table sideways to see every column.
| Portal | What the link reaches | How you withdraw it |
|---|---|---|
| Customer | Their own open invoices and statement, paying them, and accepting or declining a quote you sent. They can also browse the products you sell, with whether each is in stock but never how many, and send you a basket — it arrives as a draft quote that commits nothing until someone on your side sends it. Not your ledger, not your other customers. | Revoke Portal Links on the customer in Contacts. Every link they hold stops working at once — the statement and ordering links and every invoice or quote link you sent them. Sending a document again gives them a fresh link. |
| Employee | Their own payslips, IRP5s and leave balance. Nobody else's. | Revoke link on the employee in Payroll. Every link they hold stops working at once, and no new one is issued until you send it. |
| Supplier | Your purchase orders and requests for quotes to them, which they can acknowledge, answer with a quote and mark as despatched; invoices they submit to you; their catalogue, offers and compliance documents; and their statement with you. An invoice they submit does not become a bill until someone on your side accepts it. | Revoke Portal Links on the supplier in Contacts, or switch their supplier portal off. Immediate, per supplier. |
| Driver | Today's trip, its stops and the proof they capture. No prices on any document on the vehicle. | Withdraw on the driver in Logistics; the app signs out on its next call. The app sends its token in a request header, and the pairing link carries it after the #, the part of an address a browser never sends — so it never lands in an access log. Treat the pairing link itself like a password until the phone is paired. |
That is deliberate, and it is what every product in this category does — a customer forwards your quote to the person who signs for it, and that person must be able to accept it without an account. What limits it is that the link is signed for one document, a quote once accepted or declined cannot be changed, and you can retire every link a customer holds at any time with Revoke Portal Links. The full picture is in the portals guide.
Payments and card data
Ledgr never sees a card number — not yours, and not your customers'.
Paying for Ledgr
Subscriptions are taken by Yoco. You are handed to their hosted checkout, they process the card, and Ledgr receives only the result and a licence key to issue. No card is kept on file — see how renewal works.
Getting paid by customers
Payment links on your invoices go to PayFast or Yoco, using your own merchant credentials — held encrypted, entered once under Settings → Payments, and never Ledgr's. The customer pays on the gateway's own page; Ledgr receives a notification that an amount arrived against a reference.
Webhook verification
An incoming payment notification is signature-checked before it is trusted — and a PayFast one is confirmed with PayFast server-to-server on top of that. A notification signed by nobody, signed with another business's secret, or replayed later is refused. Every event is visible in the webhook inbox — matched, needing review or unmatched — rather than silently applied.
Banking details
Your own banking details for EFT instructions are stored as document text, because that is what they are. They appear on the invoices you choose to put them on and nowhere else.
When the power or the line goes
South African software has a requirement most cloud products do not think about: it has to keep working when the electricity does not. Ledgr captures work locally and sends it when the line comes back.
- Invoices, expenses with their receipt photograph, mileage trips, new job cards and time entries all capture with no signal — they queue on the device and send themselves later
- Each queued item carries an ID created on your device, so a reply lost on a bad connection cannot produce the same expense twice when it retries
- Anything that moves real stock at a real cost, or assigns a document number, stays online-only on purpose — the offline guide says exactly which, and why
- The queue is visible in Settings → Sync: what is waiting, what failed and why, with a retry you control rather than one that happens silently
- The service's own status — the API and its database, checked live — is published at /health, which is the honest answer to "is it me or is it you"
Found something? Tell us before you tell anyone else
If you believe you have found a vulnerability, email security@bcmobiletech.co.za with enough detail to reproduce it. We will acknowledge your report, work on a fix, and tell you when it has been released.
- Test against your own account and your own data — never someone else's business
- Do not run load or denial-of-service tests against the production service
- Give us a reasonable window to fix it before publishing
- Tell us if you accessed data that was not yours, and stop as soon as you realise you have
Security questions that are not vulnerabilities — a due-diligence questionnaire, a client's security review, a question about where a particular field is stored — go to support.
Questions your auditor will ask
Most of them are answered above. For the ones that are not, ask — the answer is usually a screen in the app you have not opened yet.