Your books, isolated and recoverable
Database-enforced tenancy, an immutable ledger, drilled backups.
A bookkeeping platform holds the most sensitive data a business has. LedgerIQ's security is built where it cannot be bypassed by a forgotten line of code — and its backup story has been tested by actually restoring, not just by checking that backups exist.
Tenant isolation, enforced by the database
- Row-level security on every tenant table — Accounts, journal entries and lines, documents, users, chat, clarifications, AI-usage logs, org membership and invitations — each carries a Postgres row-level-security policy. Isolation is enforced by the database engine, not by an application filter a new query might omit.
- Admin access is scoped — The cross-tenant bypass path is available only to explicit LedgerIQ admin roles, and only on routes gated for them.
- Frozen tenants are refused immediately — If a tenant is set to frozen, the very next API request is rejected — access is cut in-band, not on a schedule.
- Verified, not assumed — The isolation model is re-tested with a three-way check (wrong tenant / no context / correct tenant) using the least-privilege application role, not a superuser.
An audit trail that holds up
- Immutable posted entries — Once an entry posts, it cannot be edited or deleted. Every correction is a new entry, so the ledger history is the real history.
- Derived balances — Balances are computed from double-entry journal lines on read — there is no stored balance to drift out of sync.
- Reviewed before posted — Alerts, reports and exports are built only from posted, accountant-reviewed entries — never from an unreviewed draft.
Backups and continuity
| Layer | What runs |
|---|---|
| Daily full backup | A complete database dump every day with generational (daily / weekly / monthly / yearly) retention. Running unbroken since May 2026. |
| Off-site replication | The entire backup tree is synced to off-site cloud storage daily. |
| Continuous log archiving | Transaction-log archiving with a 30-minute ceiling — bounding worst-case data loss to roughly half an hour. |
| Tested restore path | A scripted restore that rebuilds roles, replays schema migrations, and re-proves tenant isolation after the restore. |
On 25 August 2026 the latest daily backup was restored into a disposable database — never touching production — and checked the way an accounting system must be checked: total debits against total credits across every posted entry. They matched to the cent ($426,365.74 = $426,365.74). The backup is proven restorable, not just theoretically sound.
Point-in-time recovery — replaying the transaction log to any chosen moment — is being layered on top of the daily off-site backups. Same-day, full-database recovery with a tested restore is in place today.
Platform hygiene
- No process runs as root — Every container runs as a dedicated non-root user.
- No secrets in code — Configuration and credentials live in environment files kept out of source control.
- Least-privilege database roles — The application connects as a limited role, never as a database superuser.
- OAuth state is signed — Third-party connection callbacks carry an HMAC-signed state parameter, so a redirect cannot be forged into someone else's books.
Data ownership
The books are the business's. Posted entries export to QuickBooks Online's native format on demand, the chart of accounts exports to CSV, and the business can invite its own outside accountant into the live data at any time. There is no lock-in on the ledger itself.