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.
Entry #11829 Dec 2025
Cleaning — Apartment 2
Hash70aebdd75b12c538…
Posted. Corrections by reversal only.
Access
Who can see your books
Separation between clients lives in the database, one layer below any application code that could forget it. Every query runs inside your account's context, and the policies tell Totalhost's own accounts from clients' accounts, so a grant on an account is only ever as wide as the role behind it.
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, Sweden Central. Reads the text and figures off a receipt so we have 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: a daily one is kept for 35 days and a monthly one for seven years. While your books are with us, 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. When an agreement ends we hand your material over to you, keeping it for those periods becomes yours, and we remove it from the service 90 days after handover. The detail is in Privacy.
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 the database holds all four, so they hold on a day when everyone has forgotten them:
- Append-only. The application has no permission to update or delete a posted entry. Not “does not”, but 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 visible after the event. Every other control here forbids it. This one shows it.
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
Posting an entry, locking a period, linking a receipt, issuing an invoice: each thing anyone does to your account is recorded with who did it, when, and from where.
It is there to show what happened. Your own login shows the action, the record it touched, who did it and when, and not the values or the IP address behind it. Some actions also store a short note of what changed, and for a few of them that note holds a figure such as an amount or a total. The record is kept under the same row-level isolation as your books, so it is never a copy sitting somewhere less protected.
