📜
Append-only audit log
Every transaction is logged with who did it, what changed and when. There are no edit or delete paths on posted entries — corrections are new, linked postings.
Audit trail & controls
An audit trail that cannot be edited.
Rule 11(g) asks companies to keep books in software with an audit trail that records every change and cannot be disabled. Most systems answer that with a log you can switch on. We answer it by removing the edit path entirely.
हर entry, हमेशा के लिए दर्ज।
- No credit card required
- Onboarding in Hindi & English
- Your data stays in India
Why an edit log is not the same as an audit trail
A change log records that something was altered. It is still a feature — something that can be turned off, trimmed, or quietly worked around by deleting and re-entering. When an auditor asks who changed a posted entry and when, the honest answer from many systems is a shrug and a date.
Finkitaabh takes the stricter route. Posted entries have no edit and no delete path at all. A correction is a new posting — a reversing credit note, an adjustment entry — so the original document and its correction both stand on the record, which is how double-entry was meant to work in the first place. Every action lands in an append-only audit log with who, what and when.
The controls underneath are built the same way. Each company's rows are isolated by PostgreSQL row-level security, enabled and forced at table level rather than filtered in application code. Money is stored as integer paise with largest-remainder splits, so nothing rounds away between the invoice, the ledger and the return. Identifiers are type-safe, so a company ID cannot be passed where a party ID belongs. Idempotency keys stop a network retry from posting the same transaction twice.
The controls, stated precisely
Each of these is enforced by the system, not by policy.
🗄
Row-level tenant isolation
PostgreSQL row-level security is enabled and forced per company, so isolation is a property of the database rather than a filter someone has to remember to write.
🔐
TOTP multi-factor auth
Signup and login are protected by an authenticator app with one-time backup codes for lost-device recovery, alongside optional server-verified Google sign-in.
🔄
Hardened sessions
Rotating refresh tokens with reuse detection, HttpOnly cookies, server-side logout and logout-all, brute-force lockout, and CSP, HSTS and anti-clickjacking headers.
🧮
Paise-exact money
Amounts are stored as integer paise with largest-remainder splits, so there are no floating-point rounding errors between invoice, ledger and return.
🛡
Roles and least privilege
Eight roles across 50 granular permissions checked in the service layer, owner-provisioned staff accounts, and confidential data such as fee contracts kept owner and manager only.
Two ways to answer an auditor
The question is never whether you meant well. It is what the system can prove.
| The job | The usual wayHow it tends to go | On FinkitaabhCloud + AI |
|---|---|---|
| Correcting a posted invoice | Open it, change it, save — with luck a log line is written | No edit path; a reversing credit note is posted and both stand |
| Deleting a wrong entry | Delete, re-enter, and the gap is a numbering question later | No delete path; the reversal and the reason are on the record |
| Turning the trail off | Often a setting an administrator can reach | Not a setting — there is no code path that writes an edit |
| Keeping two companies apart | Application-level filters, correct until one query forgets | Row-level security enabled and forced by the database |
| A duplicate submission on a retry | Two identical entries, found at reconciliation | Idempotency keys make the retry a no-op |
| Rounding across a tax split | Floating-point drift of a paisa here and there | Integer paise with largest-remainder allocation |
| A lost or stolen laptop | A password, and hope | TOTP MFA, rotating refresh tokens with reuse detection, logout-all |
“The usual way” describes common manual and desktop-era workflows we see in Indian businesses — not any particular product. Every Finkitaabh claim is a capability shipped today.
Frequently asked questions
Does this satisfy MCA Rule 11(g)?
The ledger is append-only with no edit or delete paths on posted entries, and every action is recorded with who, what and when — which is stricter than the edit-log approach the rule contemplates. Whether your specific filing obligations are met is a question for your auditor, and the exports they will ask for are all available in Excel and PDF.
How do I fix a genuine mistake, then?
The way accounting has always handled it: a correcting posting. Sales and purchase returns run a full flow with GST adjustment through reversing credit-note postings, so the stock movement and the tax effect stay consistent with the original document.
Who can see the audit log?
Access follows roles. Owners and managers see the most; staff roles are scoped to what they need, and confidential records such as client fee contracts are restricted to owner and manager. The eight roles span 50 granular permissions, so the line sits where your organisation needs it.
Where is the data stored?
In a managed PostgreSQL database with row-level security per company, continuous managed backups, and no local server for you to maintain. Your data stays in India.
What about the operator side — can support staff read my books?
Support access is explicit and audited: tenant access-locks, read-only impersonation and emergency access are all recorded in the audit log rather than being an invisible capability.
Demo book कीजिए — बिल्कुल freeSee your business
See your business
running on Finkitaabh.
A 30-minute personalised walkthrough with our product specialist — in Hindi or English, whatever you're comfortable with. We'll set up a sample company that looks like your business.
- 30-minute live walkthrough
- हिंदी या English में
- No payment, no obligation