Built for the trust
behind your books.
Company-level encryption, clear limits on AI and accounting rules that check every entry.
Data protection
01Per-company keys
Sensitive fields, including names and amounts tied to identity, are encrypted individually with authenticated AES-256 using a key unique to each company. Keys are stored separately from the data. A database copy alone should not reveal those fields in plain text. Access to both the data and keys changes that risk, so application, key and account access still need protection.
Account isolation
Data is partitioned by company. Each request is scoped to the signed-in company on the server, and reads are bound to that company’s keys. The browser cannot select another company’s account by changing a request. Our privacy notice describes processing locations and retention.
Backups
Backups of your company’s records are held apart from the live database, in Google Cloud Storage, in Google’s Hong Kong region (asia-east2). Archives are encrypted before they leave Suma, and Google never holds a key that opens them. Each backup is kept 30 days, and the most recent one is always kept so there is something to restore from.
Payment and ledger controls
02Ordinary code matches incoming payments against company rules. Uncertain matches wait for confirmation. Before a proposed entry is stored, the engine checks that debits equal credits, the account exists and the period remains open. The store independently checks balance again on each write, and statements are derived from the ledger.
Randomized accounting tests check that trial balances hold, assets equal liabilities plus equity, and cash-flow statements reconcile.
Entries record their source and reason. Closed periods resist silent edits, and the audit record is retained for seven years.These controls make alteration harder to hide; account and server access still require protection and review.
AI boundaries
03The assistant is optional. It can answer questions and draft suggestions, but has no direct authority to post to the ledger. A model suggestion becomes a structured proposal that must pass the accounting rules before any entry is written.
Personal fields
Before model calls, names are replaced with stable placeholders. A second server filter removes recognisable personal fields such as email addresses, phone numbers, and ID or card numbers. The mapping back stays with Suma; amounts and dates pass through because they are needed to answer accounting questions.
Provider access
Model access runs through our backend, so no provider key is held in browser code. Google Vertex AI runs inference under terms that prohibit training on your data. We can tell your IT reviewer which region it runs in. If a provider were breached, we would investigate the content sent and notify affected clients as required. The provider has no ledger write authority.
Technical questions
04We welcome questions from your accountant or IT reviewer about data access, model boundaries and accounting controls. Contact the engineers who built the system.