Trust by design
Every rupee, reviewed. Every action, on the record.
Ganav was built controls-first. Governance, auditability, and data protection aren’t features bolted onto the side — they’re enforced in the database itself, so the rules hold even against a direct API call. Here’s exactly how.
Maker–Checker–Approver, as a reusable engine
No financially significant action executes on one person’s say-so. The person who prepares a transaction is not the person who approves it, and the system — not a human — performs the final commit.
- One governance engine, every module. GL journals, master data, period close/reopen, fixed-asset creation and disposal, payroll runs, leave — all governed by the same policy-driven engine, without per-module hardcoding.
- A coverage board, not a rules dump. Admins see every governable action, grouped by module, each showing its live state — Governed, Runs straight through, Partially covered, Always requires approval — with an inline prompt to add a policy or choose who approves.
- Amount-threshold bands. Policies can carry a base-currency band, so (for example) journals at or above ₹50,000 route for approval while smaller ones post straight through. Bands can’t overlap, and voucher-specific overrides beat company-wide rules.
- A governed-action cataloga single source of truth of every governable entity/action pair, with a declared default (fail-open or fail-closed). You can’t configure a policy for an action the engine can’t actually govern.
- Bypass is auditable, never silent. Where an authorized bypass applies, the system auto-approves — but still writes a work item and an “auto-approved by policy” event, preserving the actor’s identity. Bypass skips the approval step only — never validation, SoD, locks, or the audit trail.
Segregation of Duties — and it always wins
The same person can’t both create and approve the same transaction — and no role grant or workflow policy can override that. SoD is enforced at role-assignment time and at execution time, evaluated first, before maker-checker and before any bypass. A conflict blocks the operation with an explicit reason — never a silent resolution.
Capability-based roles, with health checks
- Roles are built from a dependency-closed, SoD-aware library of named capabilities — a guided wizard lets an admin pick capabilities and see a server-computed preview before the role is created.
- Role health continuously scans for problems — unusable screens, invisible grants, disabled modules, SoD conflicts, capability drift — and each finding carries a one-click fix. The server never trusts a client-supplied permission code.
The 11 locked rules — what they mean for you
These are non-negotiable, owner-locked rules, each independently audited as conforming in the live system:
- Every mutation is branch-authorized at runtimere-checked both at the API and inside the posting procedure. A direct API call can’t bypass it.
- Posting re-validates 7 gates atomically at commitcompany, branch, fiscal year, period, voucher type, accounts, and subledgers must all be valid, in the same transaction as the post. Approval doesn’t exempt an entry from the gates.
- Idempotent postinga retried or double-submitted post returns the existing voucher number, adds no balances, and draws no new number. Network retries can’t double-count or leave gaps.
- Approval isn’t a human “post” buttononce approved, the system posts. Re-approving a decided item returns a conflict, so nothing executes twice.
- Counterparty integritya vendor can’t be posted to a receivables control account, or vice-versa.
- Correct FX sequencingsettlements finalize before revaluation, and settled items are excluded — structurally preventing the double-counting of exchange gain/loss.
- Chart-of-accounts integrityevery journal is pinned to the active COA version and re-validated at post.
- Archived data is read-onlyit can never re-enter live ledgers, workflows, or corrections.
- Permissions can’t go stalechanging a role or deactivating a user invalidates that user’s access immediately.
Immutable audit trail
- Insert-only audit log — records are never updated or deleted. Every secured action is captured with user, company, branch, action, entity, correlation ID, timestamp, and payload — even when the action is denied or bypassed.
- Insert-only workflow event log — every submit / verify / approve / reject / auto-approve is recorded and never mutated, giving a complete governance trace for any transaction.
- Correlation IDs end-to-end — every request is traceable across API, database, and audit log, and every error response carries its correlation ID.
Part 2 — Security & data protection
- Tenant isolation (on every plan)each firm (or business) runs in its own separate tenant: a dedicated database and its own encryption keys, never a shared table with a “firm ID” column. There is no query path from one tenant to another, and backups run per tenant. Smaller firms share only the VM (the machine) — never the data; large firms take a dedicated Azure VM, or one in an Azure subscription in their own name, for hard compute isolation. (See Tenancy & Architecture.)
- JWT auth with real token revocationrole/permission changes and deactivation bump a per-user token stamp; stale tokens are rejected on the next request. Not just expiry — genuine revocation.
- Standards-based 2FA (TOTP)RFC 6238 authenticator-app verification, enforceable at login. (Recovery is via admin reset; there are no self-service recovery codes yet.)
- Optimistic concurrencyconcurrent edits conflict rather than silently overwriting.
- Soft-deactivation over hard delete, fully audited, across every admin surface.
- AI PII maskinggovernment IDs (GSTIN, PAN, Aadhaar, TAN, CIN, IFSC/IBAN, card numbers) are reversibly tokenized before any AI provider sees them, restored byte-exactly in the answer, through a single choke point that fails closed. (Text IDs are masked; image pixels in vision OCR are a disclosed, accepted exposure.)
- Encrypted secrets storeall application secrets (AI keys, JWT signing key, comms keys) live AES-256-GCM-encrypted in the database, with the master key held outside the DB and the store write-only by design (no read-back path). Fails closed on a bad key.
- Encrypted employee PII at restpayroll sensitive fields stored as ciphertext, masked by default, with an audited reveal permission (see Payroll & HR).
- Runtime Posture — every operational switch on one screen. Masking mode, AI provider enablement, workflow fail-closed state, magic links, swagger — each shown with its expected value, and a red banner on every AI screen if an unmasked AI path is ever live. Governance that is configured but not running is loud, never silent: a workflow policy that cannot resolve fails closed, and coverage gaps are named.
- Upgrades that cannot brick you. A new build must pass a startup check before it replaces the running one; the previous binaries are snapshotted for a one-command rollback; a configuration doctor proves the instance matches the release; the exact build is visible in the account menu.
- Errors report themselves — with an ID, not your ledger. A server error is captured with its correlation ID, message and stack and reported to Ganav support automatically.
Part 3 — Built for India
India-first by design: INR base currency, DD-MM-YYYY dates everywhere (one shared date component — no native browser pickers), IST-pinned scheduling, and multi-company / multi-branch / multi-state structure throughout.
GST — including reverse charge
Tax-on-posting with CGST / SGST / IGST splits, versioned tax rates, registration-status honesty, and a returns lifecycle with drill-down to the underlying tax transactions. Reverse charge done properly: a CA-reviewed applicability master, RCM liability and input credit posted in the same voucher, the self-invoice under Section 31(3)(f), the GSTR-3B reverse-charge split, ITC eligibility on every purchase line (17(5) blocked credits visible), and foreign suppliers recognised by country. GSTR-2B reconciliation included. (GSTR-3B and GSTR-2B are named outputs; confirm GSTR-1 before printing it.)
TDS — the whole suite, not just salaries
Eight seeded sections (192, 194A, 194C, 194H, 194I-A/B, 194J, 194Q), TDS on vendor bills posted in one governed voucher, Section 197 lower-deduction certificates applied automatically, Section 206AA 20% where PAN is missing — as a warning the user can overrule, never a silent override — challans, 26Q and 24Q returns with FVU export, Form 16A and Form 16, a running TDS register, TDS credit received and Form 26AS reconciliation. Salary TDS under Section 192 is computed per employee at pay-run posting and mirrored into the same register; 24Q (all quarters, Annexure I & II) and Form 16 Part B come from a frozen year-end snapshot. Challans link on the deduction month, not the filing month — the correctness detail that trips up manual filers.
Payroll statutory
PF/EPF (EPS ceiling, EDLI, EPFO v2 ECR export), ESI (with contribution-period continuation), Professional Tax across 5 states, LWF, old-vs-new regime with standard deduction / HRA / Chapter VI-A / marginal relief.
Multi-state, multi-company, multi-branch
One platform, many companies, branch-level authorization enforced end to end, INR base with FX handling for foreign exposure.
For CA firms
Articleship registration and milestone tracking with per-institute scheme parameters for ICAI / ICSI / ICMAI, plus reminders.
For audit practices
Ganav Audit applies the same doctrine to the statutory audit itself: an independence wall enforced by architecture (the audit app never opens the accounting database — data arrives as a signed snapshot), Section 144 evaluated by the system, SA-by-SA gates, a 46-check quality gate before issuance, and the 60-day SA 230 archive clock with post-lock guards. (See Ganav Audit.)