Books that prove themselves.
Zelims is built on one idea: financial controls should be enforced by the system, not promised by it. This page lists what we claim, and — unlike most trust pages — the mechanism that makes each claim true. AI does the typing. Humans do the approving. The database enforces it.
01
The ledger never edits history
Every posting is double-entry and immutable. There is no update or delete path to a posted journal entry — mistakes are corrected by reversal, in the open, forever.
How it's enforced — Postings flow only through guarded database functions; direct writes to journal tables are refused by the database itself, and a CI invariant proves it on every change.
02
The AI can suggest, never post
Our AI reads documents, drafts bills, classifies your inbox, and answers questions — and it physically cannot post to your ledger. Every AI action is logged with the exact data it looked at.
How it's enforced — The AI's tool registry contains no posting tool to misuse. Its work becomes proposals a person accepts, crossing the same approval gates a human's work would. Session traces are append-only.
03
The close proves itself
Closing a period requires a signed close package with a cryptographic hash of the trial balance. Anyone can recompute the hash later and verify nothing drifted. Reopening a closed period requires a second person's approval — consumed once, recorded forever.
How it's enforced — Signed packages, hash verification, and maker-checker reopen requests are database constraints, not application habits.
04
Every company's books are isolated in the database
Tenant isolation is not a filter we remember to apply — it is row-level security enforced by PostgreSQL. A query without your workspace's context returns nothing at all.
How it's enforced — 99 row-security policies plus invoker-mode views, verified live: cross-tenant reads return zero rows. Continuous tests seed deliberately colliding data in two workspaces and prove neither can see the other.
05
Approvals are policy, not politeness
Amount thresholds, required roles, and ordered approval chains — each step by a different person — gate invoices, bills, and journals. The creator of a document can never approve it.
How it's enforced — Separation-of-duties rules live in database triggers and checks. Even a raw database write by the application cannot bypass them.
06
Everything is tested before it ships
Every code change replays the entire database schema from zero, then runs ledger invariants, cross-tenant isolation checks, and enforcement acceptance before it can merge.
How it's enforced — The suites are mutation-sensitive: each check documents the exact code change that would turn it red. Weaken a guard and the build fails.
Formal certification
SOC 2 readiness is underway. No report has been issued.
We use Vanta for continuous control monitoring while we work toward a SOC 2 examination. Until an auditor issues a report, we will not imply one exists. There has been no third-party penetration test either; our security assurance to date is the enforcement above, plus recurring internal adversarial review of the isolation and authorization surfaces.
Why say so — A trust page that only lists strengths tells you nothing about the ones it left out.
Questions, audits, or a walkthrough of any control: admin@zelims.com · Request a workspace