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 is what we do about that, in plain terms, 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: cross-border transfer of personal information is something POPIA has an opinion
about, and a database in the same country as its users is a database that responds quickly.
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 managed database takes automated backups with point-in-time recovery. They stay in the same region as the data they came from.
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.
Your own copy
Settings → Data → Export all data gives you a ZIP of CSVs on demand, on every plan. Scheduled exports to your own storage are on the roadmap; the manual one works 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
- 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, with the group view aggregating them deliberately
- 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. It needs their own code, cannot be used on themselves, signs the affected user out everywhere and is written to 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 incidents are not clever — they are a reused password from somewhere else. 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
- Retained for seven years — comfortably beyond the five years SARS requires supporting 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 make your obligations something you can actually discharge.
| 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, role-based access, 2FA, 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" is a screen, not 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 and retained for the statutory period, because SARS and the Companies Act override a deletion request for records of a transaction. |
| Retention | Seven years of audit history, which covers the five-year retention SARS requires for the records behind a return. |
| Retention limitation | Personal information is not kept forever because it is convenient. If you stop paying, your books stay readable for one month — export anything you need — and are then deleted. Warnings go out at 21, 7 and 1 days naming the exact date. Details in the billing guide. |
| Accountability | The audit log evidences 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 detail — 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 viewing an invoice, your employee fetching a payslip, your supplier checking whether you have paid, 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 exactly one thing through a signed link.
| Portal | What the link reaches | How you withdraw it |
|---|---|---|
| Customer | One document — view it, accept or decline a quote, pay it. Not your ledger, not your other customers. | Regenerate the document's link; the old one stops working. |
| Employee | Their own payslips, IRP5s and leave balance. Nobody else's. | Bump that employee's token; every link they hold is retired at once. |
| Supplier | The bills you owe them and their payment status. | Same — per supplier, immediate. |
| Driver | Today's trip, its stops and the proof they capture. No prices on any document on the vehicle. | Same — and a driver's app token is in a request header, never in a URL, so it cannot leak through a shared link or an access log. |
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 bounds it is that the link is signed for one document, a settled question cannot be re-decided, and you can retire the link at any time. 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, using your own merchant credentials — held encrypted, entered once in Invoice Settings, and never Ledgr's. The customer pays on PayFast's page; Ledgr receives a notification that an amount arrived against a reference.
Webhook verification
An incoming payment notification is signature-checked and confirmed with PayFast server-to-server before it is trusted. 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 minted 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 mints 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 health is reported 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@ledgr.co.za with enough detail to reproduce it. We will acknowledge you, work the fix, and tell you when it has shipped.
- 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.