Trust
Books are somebody's business. This page describes what protects them — isolation, a tamper-evident audit trail, access control and the right to take everything back — in terms you can check rather than a list of badges.
Every business gets its own Postgres schema, and every query runs inside a transaction bound to that business. A query with no business context does not fall back to a shared table — it finds nothing, which is the correct answer.
Above the application boundary sits a second one: row-level security with per-tenant database roles, so isolation does not depend on the application asking nicely.
Each audit row hashes its own contents together with the previous row's hash. Editing a row, deleting one, or re-ordering the sequence breaks the chain from that point on — which is what the MCA mandate means by tamper-evident.
There is no setting that disables it, because the Companies (Accounts) Rules do not permit one. Chain state is anchored periodically and any tamper is raised as a security event.
TOTP two-factor, automatic lockout on repeated failures, and an optional IP allowlist per business — so a firm can restrict access to its own office network.
Sign-ins, failures, lockouts, two-factor changes, password changes and blocked requests are all written to a security log you can read.
Masters, vouchers and balances export in full, at any time, in a format Tally reads. Leaving is a download, not a negotiation.
A business can be erased on request — completely, including its schema — which is what the DPDP Act's erasure right requires in practice rather than in a policy document.
Acceptance of terms and privacy is recorded as evidence, along with which version was accepted. A policy that changed after you agreed to it is not evidence of anything.
Where AI reads a document, what it produced is stored with what it read and which model produced it. Nothing posts to your books without a person confirming it.
The audit trail, in detail
A log that records changes proves nothing on its own, because whoever can write to it can usually edit it. The MCA mandate asks for something stronger: a record that shows if it has been altered.
Every audit row is hashed together with the previous row's hash, so each row binds to the one before it. Change a value in row 400 and its hash no longer matches; delete row 400 and row 401 no longer points at anything; re-order two rows and both break. The chain does not prevent tampering — nothing can — it makes tampering visible, which is the property an auditor needs.
Ask for the chain to be verified for a period. Either every row's hash reproduces, or the report names the exact rows that do not. That is a much shorter conversation than reading a log and hoping.
Chain state is anchored periodically so the sequence cannot be silently rebuilt from scratch, and a failed verification raises a security event rather than sitting in a file nobody opens.