Trust
What holds this together
You are handing someone else your books. This page is the case for why that is safe, made from how the system is actually built — including the parts we have not done yet.
The ledger
Nothing that has posted can be quietly changed
A bookkeeping system is only worth anything if the history cannot be rewritten after the fact. Four properties enforce that, and they are enforced by the database rather than by everyone remembering the rules:
- Append-only. The application has no permission to update or delete a posted entry. Not “does not” — cannot: the grant does not exist.
- Gapless voucher numbers. Every entry is numbered in sequence, with the counter advanced inside the entry's own transaction. Numbers are never skipped and never reused, so a missing entry is visible as a missing number.
- Reversal-only corrections. A mistake is fixed by posting an entry that cancels the old one. Both stay visible. You can always see that something was corrected, and what it was before.
- A SHA-256 hash chain. Each entry carries a hash of the one before it. Altering an entry after the fact breaks every hash that follows it, which is what makes tampering detectable rather than merely forbidden.
A posted entry carries its own hash and the hash of the entry before it; both are visible on the entry itself, and there is a screenshot of one on the month page.
The record
Every action is written down
Each thing anyone does to your account — posting an entry, locking a period, linking a receipt, issuing an invoice — is recorded with who did it, when, and from where.
The record deliberately stores which fields changed and never the values they changed to or from. It is there to show what happened, not to become a second copy of your financial data sitting in a less protected place.
Access
Who can see your books
Separation between clients is enforced in the database, not in application code that might forget. Every query runs inside your account's context, and the policies distinguish a bookkeeper from a client rather than treating everyone with a grant as equal.
That distinction matters in one specific way worth spelling out: you hold a grant on your own account, so account-based rules alone would have let you read our internal assessment of you — the risk rating and the screening findings we are required by law to keep. Those are restricted to us at the policy level. The audit record shows that such a field changed, never what it says.
Where it runs
In the EU, on named services
- Amazon Web Services, Frankfurt (eu-central-1). The application, the database, your stored receipt files, the address receipts are emailed to, and sign-in.
- Microsoft Azure Document Intelligence, EU region. Reads the text and figures off a receipt so a bookkeeper has something to check against the file.
- Cloudflare. Serves this website, and counts visits to it without cookies. No client data passes through it.
Client data is not transferred outside the EU/EEA. Backups run automatically and are kept for fourteen days. Accounting material is held for the six and ten year periods the Accounting Act sets, and identification records for five years after a client relationship ends — the detail is in Privacy.
The other half
What we have not done
A trust page that lists only strengths is an advertisement. These are the things a careful buyer would ask about and would not otherwise be told:
- No external security audit or penetration test. The controls above are real and testable, but no independent party has tried to break them.
- No ISO 27001, no SOC 2. We hold no security certification of any kind.
- No uptime commitment. We do not publish an availability figure, and there is no service level agreement behind one.
- We are two people. That is the honest scale of the company, and it cuts both ways: you will always reach someone who knows your account, and there is no overnight support desk.
Each of these changes this page the day it changes in fact, not before.