Built to hold a company's books.
Financial data deserves more than a checkbox. Suma is engineered so that even in the worst case, a stolen database or a leaked key, your numbers stay yours. Here's plainly how, and what we'd say to your IT reviewer.
Encrypted at rest, per client
Sensitive fields (customer and supplier names, amounts tied to identity) are encrypted individually with a key unique to your company, using authenticated AES-256. A dump of the database is ciphertext: no readable names, no readable relationships. The key that unlocks it is held separately from the data itself, so leaking one without the other reveals nothing.
What actually happens when a payment arrives
Worth walking through, because it is the whole design. A payment lands in your bank feed. Ordinary code, not AI, reads it, matches it against your company's rules, and where the match is certain it writes a balanced double-entry line. Where it isn't certain, it stops and asks you, once, with a yes or no. Your statements are then recalculated from the ledger itself, never typed. At no point in that sequence does a model decide anything, which is why your books would stay correct even if every AI on earth went offline tomorrow.
Where the assistant fits, and what it isn't allowed to do
Every Suma app comes with an assistant, unless you would rather it didn't: say so and we ship without it. It is there to answer questions about your own books in plain language (“what did we spend on freight last quarter?”) and to draft the tedious things, like a payment reminder.
What it cannot do is post to your ledger. It reads, and it suggests. A suggestion then goes through exactly the same checks as everything else (does it balance, is the period still open, does the account exist) and the checks decide, not the model. So the worst a mistaken suggestion can produce is a proposal you decline. It cannot quietly put a wrong number in your accounts, because it was never holding the pen.
Your customers' names never reach the AI
Before a question leaves your environment, a pseudonymization gate swaps real names for stable placeholders: the model sees “CLIENT_3” and “VENDOR_1”, never who they are, and the mapping back never travels with the question. A second filter on our own server strips anything else personal that is recognisable by shape (email addresses, phone numbers, ID and card numbers) so a bug in the first gate still cannot leak them. Amounts and dates pass through untouched, because those are the actual question.
Every model call goes through our backend, so there is no API key sitting in your browser to steal. That path does not exist in the code. Inference runs on Google Cloud under enterprise terms that forbid training on your data, and we will tell your IT reviewer exactly which region it runs in.
The model proposes; rules decide
Nothing posts to your ledger because an AI “felt confident.” Any automated step produces a structured, checkable proposal; deterministic accounting rules validate it (debits equal credits, the period isn't locked, the account exists) before a single entry is written. This is why the books stay correct, and why the compliance claims are real rather than marketing.
Tested like it's money
The ledger engine is exercised by a property-based test gauntlet: hundreds of randomized sets of books, each asserting that the trial balance holds, assets equal liabilities plus equity, and the cash-flow statement reconciles, on every run, before any change ships. The server re-checks the balance invariant independently on every write it stores. If an invariant can break, we want it to break in our test suite, not in your accounts.
An immutable, IRD-ready trail
Every entry records its source and reason and is retained for seven years, with an audit trail designed to satisfy Hong Kong record-keeping requirements. Your accountant gets records they can sign off on, not a black box they have to take on faith.
One tenant can never see another
Data is partitioned per company at every layer. Each request is scoped to your account on the server, never trusting anything the browser sends, and every read is bound to your company's keys. There is no path by which one client's books can surface in another's.
Assume it goes wrong. Then what?
“Your database leaks.”
The attacker holds ciphertext. Names and identifying fields are encrypted per client with authenticated AES-256; the key that unwraps them lives separately from the data. Neither artefact alone reads as anything.
“A model provider is breached.”
There is nothing of yours worth finding. The only text that ever travelled was pseudonymized (“VENDOR_1”, never the name behind it), with contact details stripped by a second filter. And because the model never had authority to post, a compromised provider still could not alter a single entry in your books.
“Someone tampers with the books.”
Every entry carries its source and reason, closed months are locked against silent edits, and the store re-checks the balance invariant on every write it accepts. Tampering doesn't blend in — it breaks loudly.
Put a technical reviewer on us.
The strongest thing we can offer is scrutiny. Send your accountant or IT reviewer with their hardest questions: get in touch and the engineers who built this will answer them directly.