Fifteen clients, fifteen ledgers. One console with the evidence at hand.
An accounting firm doesn't need one ERP — it needs a way to operate fifteen. cifraHQ gives you physical isolation per client, granular role-based permissions and an audit trail that survives any dispute.
The four pains of running multiple books
- Every client needs real isolation. An ERP that mixes fifteen clients' books in one database is a confidentiality risk and a problem at the next audit.
DB-per-tenantgives one SQL database per client, with independent backup and per-contract retention. The firm runs fifteen tenants; each client exists physically separate. - The senior accountant sees everything; the junior sees their scope. Giving everyone "admin" is dangerous; managing permissions client-by-client is impossible. The permission model uses named constants (
Permissions.Invoice.Approve,GL.Post,Period.Close) grouped into role clusters — the senior has one set, the junior another, the client's client a read-only third. - Disputes six months after someone touched a document. "Who changed this entry? Why?" Firms live with that question. The dual audit trail — SQL Server temporal tables plus append-only
AuditEvents— answers in seconds; reverse transitions require a minimum 20-character reason that stays forever. - Month-end close as a coordinated batch. Closing March for fifteen clients at once without losing track of which is done is the real work. The six-state period machine (
Open → Draft → PendingApproval → Closed → YearClosed → YearAudited) runs per tenant; the firm's dashboard shows every client's state on one screen.
Three concrete mechanisms
Tenant per client
<code>DB-per-tenant</code> with independent backup and retention. The isolation fuzzer in CI verifies no query crosses the boundary between clients.
Role clusters
Permissions as named constants grouped into clusters. Senior, junior, external reviewer, client-of-client — each role a set, no magic strings.
Dual audit trail
Temporal tables plus append-only <code>AuditEvents</code> with <code>DENY UPDATE/DELETE</code> at the SQL principal. Evidence that survives six months and three auditors.
From new client to year-end close
- Onboarding a new client. The firm provisions a tenant with COA template, regional config (Panama by default) and the client's white-label. The firm's organization holds the master settings; the new tenant inherits and adjusts.
- Daily operation with clear permissions. The junior posts purchase invoices; the senior approves manual entries; the client's client logs in read-only to see their statements. Every action lands in
AuditEventswith user, timestamp and reason where applicable. - Batch month-end close. The dashboard shows all fifteen clients with their period state. The firm closes client by client or in parallel; the state machine blocks skipped steps.
- Reverse-close with evidence. Error surfaces after close. Reversing requires a minimum 20-character reason text; the event logs with the user who did it. The next auditor sees exactly what happened.
- Read-only investigation console. The
readonly_investigatorSQL principal runs investigation queries in production without mutating anything — and every query lands inAuditEvents.
Talk to sales for accounting firms
We'll show you five of your clients running in parallel — onboarding, role permissions, batch close and audit — in one session.