Security & your data

Where your books are kept

On a dedicated server in Frankfurt, Germany, run on Akamai Cloud (Linode) — inside the European Economic Area, and well placed for customers across Pakistan, the Gulf and Europe. Not shared hosting, and not a machine running anybody else's application.

Every connection is encrypted. The server does not offer an unencrypted one to fall back to: a request that arrives over plain http is redirected to https before it reaches the application, and browsers are told to refuse the insecure address in future.

The disks the database sits on are encrypted where they lie, so a disk that ever leaves the data centre — replaced, decommissioned or thrown away — carries nothing readable off it. Inside the running server your figures are of course readable, because adding up a trial balance requires it; that is true of every accounting product, and one telling you otherwise is selling you something.

The whole server is backed up daily — and the restore is exercised rather than assumed. On 17 August 2026 a full database dump was loaded into an empty database and its contents counted back. A backup nobody has ever restored is a hope, not a backup. Separately from all of it, you can take your own copy whenever you like — see getting your data out.

One company cannot see another’s books

This is the thing that matters most in multi-company accounting software, so here is exactly how it works rather than an assurance that it does.

• Every record names its company. Not as a label the software checks afterwards — as a column the database itself refuses to leave empty, pointing at a real company row. A voucher, a product, a customer or a ledger entry that belongs to nobody cannot be written at all.
• Which company you are reading comes from your signed-in session, never from anything in the address bar. Editing a number in a URL does not move you into another company’s books; it produces a “not found”, because the lookup was never asking the whole table in the first place.
• It is held in place by tests, not by memory. Isolation has its own automated tests that try to reach one company’s data while signed in to another and fail the build if they ever succeed. They run on every change.

Signing in

• Your password is not stored. What we keep is a bcrypt hash of it, which cannot be turned back into the password — not by us, and not by somebody who obtained a copy of the database.
• Email addresses are confirmed before a new account can be used, so somebody cannot open an account on your address.
• Guessing gets locked out. After 10 wrong passwords the account locks for 1 hour. You can unlock it immediately from a link we email you.
• We never confirm whether an address has an account. A wrong password and an unknown email give the same answer, so the sign-in page cannot be used to work out who your staff are or whether your company is a customer.
• Or sign in with Google, in which case there is no password for anyone to steal, and we never see one.
• One place at a time. An account can only be signed in once — signing in somewhere new ends the other session. A shared password stops being convenient and starts being obvious, which is the point.
• You can see every sign-in — when, from what browser, and which city — and end any session you do not recognise. The city is worked out on our own server from a lookup file stored there, so producing it sends nothing about you anywhere.

One thing worth doing at your end: your password is the key to your books, so make it long and use it nowhere else — and protect the email account behind it just as carefully, because a reset link goes there.

Who inside your company sees what

Inviting a member of staff does not hand them the books. You grant each person the areas of the software they need and no others, so somebody who raises invoices is never given the accounting area at all. You can also confine a member to particular warehouses, which is how a branch storekeeper sees their own stock and not the rest of the company’s.

A few things stay with the account owner alone: backups, restoring a backup, deleting a company, and anything to do with billing.

Every change is attributed. The activity log records who altered what and when, within that company, so a disagreement about a figure is a question with an answer rather than an argument.

And when someone leaves, you disable their access rather than erase them: they can no longer sign in to that company, and they stop occupying one of your plan’s staff seats, but everything they recorded stays attributed to them. Removing a person must never quietly rewrite who entered what.

The books cannot be quietly altered

Most of what protects financial records is not security software — it is the accounting design underneath. Three deliberate choices matter more here than anything else on this page.

• A posted voucher is never edited. Correcting one reverses the original and posts a replacement, and both remain. The mistake and the fix are both visible, which is what makes the trail worth auditing.
• No balance is stored. Every figure on every report is summed from the posted entries behind it, each time it is shown. There is no stored total anybody could edit into agreement, and any figure can be followed back to the vouchers that produced it.
• Both sides land together or not at all. A voucher’s debits, its credits and any stock movement are written inside a single database transaction. An interruption halfway through leaves no half-posted entry — the books were never out of balance, even for an instant.

Card details never reach us

When you pay for a plan, the card is entered on the payment provider’s own page, on their systems. No card number, expiry or security code is ever sent to our server, so none can be taken from it. What we keep is what you bought, when, and what it cost.

What the support assistant is told

The help chat is answered first by a language model, which means something you type leaves our server. What it is given is the message itself, the help articles it answers from, and which plan and screen you are on.

No financial data is ever included — no balances, no invoice totals, no customer or supplier amounts, no stock figures. That limit is enforced in the code and pinned by an automated test, so it does not depend on anyone remembering it.

Getting your data out — and having it deleted

• Export whenever you want, on any plan, including one that has lapsed. Leaving is not something you have to ask permission for, and your books are not held hostage to a renewal.
• Keep your own copies. Connect your own Google Drive and backups land there nightly, in your account, under your control. The permission you give us to write there is stored encrypted, with a key held apart from the database, and withdrawing it in your Google account is enough to cut us off.
• Deleting a company is deliberate. It takes a code we email you, then the company is frozen for seven days before it is permanently erased — long enough to change your mind, and impossible to do by accident. After that it is genuinely gone, including from our side.

Found a problem? Tell us

If you find a security flaw, email osama@caprastacks.com and it reaches the person who wrote the code. We will reply, and we will tell you when it is fixed.

If you are researching in good faith — testing only your own account, not degrading the service for anyone else, and not taking other people’s data — we will not pursue you for it, and we will credit you if you would like us to. Please give us a reasonable chance to fix the issue before publishing it.