Quince clientes, quince libros. Una sola consola con la evidencia a la mano.
Una firma contable no necesita un ERP, necesita una forma de operar quince de ellos. cifraHQ da aislamiento físico por cliente, permisos granulares por rol y un rastro de auditoría que sobrevive a cualquier disputa.
Los cuatro dolores de la firma que opera varios libros
- Cada cliente necesita aislamiento real. Un ERP que mezcla los libros de quince clientes en una sola base es un riesgo de confidencialidad y un problema en la próxima auditoría.
DB-per-tenantentrega una base SQL por cliente, con backup independiente y retención configurable por contrato. La firma administra quince tenants; cada cliente existe físicamente separado. - El contador senior ve todo; el auxiliar ve lo suyo. Dar un rol "admin" a todos es peligroso; gestionar permisos cliente por cliente es imposible. El modelo de permisos usa constantes nombradas (
Permissions.Invoice.Approve,GL.Post,Period.Close) agrupadas en clusters por rol — el contador senior tiene un set, el auxiliar otro, el cliente del cliente un tercero de solo lectura. - Disputas seis meses después de que alguien tocó un documento. "¿Quién cambió este asiento? ¿Por qué?" Las firmas viven con esa pregunta. El dual audit trail — temporal tables de SQL Server +
AuditEventsappend-only — responde en segundos; transiciones reversas piden un texto de razón mínimo 20 caracteres que queda para siempre. - Cierre mensual como batch coordinado. Cerrar marzo para quince clientes a la vez sin perder la pista de cuál quedó cerrado y cuál no es el trabajo real. La máquina de seis estados del periodo (
Open → Draft → PendingApproval → Closed → YearClosed → YearAudited) aplica per-tenant; el dashboard de la firma muestra el estado de cada cliente en una sola pantalla.
Tres mecanismos específicos
Tenant por cliente
<code>DB-per-tenant</code> con backup y retención independientes. El isolation fuzzer en CI verifica que ningún query cruza la barrera entre clientes.
Clusters por rol
Permisos como constantes nombradas agrupadas en clusters. Senior, auxiliar, revisor externo, cliente-cliente — cada rol un set, sin cadenas mágicas.
Dual audit trail
Temporal tables + <code>AuditEvents</code> append-only con <code>DENY UPDATE/DELETE</code> a nivel SQL. Evidencia que sobrevive seis meses y tres auditores.
Del cliente nuevo al cierre del año
- Onboarding de un cliente nuevo. La firma provisiona un tenant con plantilla de COA, configuración regional (Panamá por default) y white-label del cliente. La organización de la firma guarda los settings master; el nuevo tenant hereda y ajusta.
- Operación diaria con permisos claros. El auxiliar postea facturas de compra; el senior aprueba asientos manuales; el cliente del cliente entra en modo solo-lectura a ver su estado. Cada acción queda en
AuditEventscon usuario, timestamp y razón cuando aplica. - Cierre mensual batch. El dashboard muestra los quince clientes con su estado de periodo. La firma cierra cliente por cliente o en paralelo; la máquina de estados impide saltarse pasos.
- Reverse-close con evidencia. Descubre un error después del cierre. La reversión exige un texto de razón mínimo 20 caracteres; el evento queda logueado con el usuario que lo hizo. El auditor siguiente ve exactamente qué pasó.
- Consola de investigación de solo-lectura. El principal
readonly_investigatorcorre queries de investigación en producción sin posibilidad de mutar nada — y cada query queda enAuditEvents.
Habla con ventas para firmas contables
Le mostramos cómo se ve operar cinco de sus clientes en paralelo — onboarding, permisos por rol, cierre batch y auditoría — en una sesión.