Tres empresas, tres libros. Una sola organización que configura y audita.
Holdings, franquicias y grupos familiares necesitan libros independientes por ente legal y control central para el CFO del grupo. cifraHQ separa físicamente los libros y une la administración en una sola organización.
Los cuatro dolores del grupo con varias entidades
- Aislamiento real de datos entre empresas. Los auditores y los socios exigen que la información de la subsidiaria A no viva en la misma base que la subsidiaria B.
DB-per-tenantentrega aislamiento físico: cada empresa tiene su propia base SQL, con su propio backup y su propia política de retención. El esquema de un tenant nunca ve datos de otro. - Configurar una vez, heredar en todas. Plantillas de factura, cuentas contables, políticas de aprobación — el CFO del grupo no tiene tiempo para configurarlas tres veces. Los settings en la organización propagan en cascada a los tenants hijos; cualquiera se puede sobrescribir localmente con auditoría del override.
- Transacciones entre subsidiarias que se registran una vez y se pierden en la otra. El manual dice "registrar en ambos libros", la realidad dice que el 60% de las disputas mensuales vienen de eso.
IntercompanyPartnerdeclara la relación oficial; al postear un documento intercompany en el tenant A se genera automáticamente unDraften el tenant partner B — listo para revisar y postear. - Una suscripción, varios libros. Los tenants del grupo comparten contrato, pero cada uno es un libro independiente. El servidor de licencias
P4S_Licensesamarra la suscripción a múltiples tenants, reporta uso agregado, y aplica entitlements por edición — sin facturas separadas por cada empresa.
Tres mecanismos específicos
Base por tenant
Cada ente legal tiene su <code>DB-per-tenant</code> con su propio backup y retención. Un isolation fuzzer en CI verifica que ningún query cruza la barrera.
Party hierarchy + cascada
<code>ParentPartyId</code> con <code>RelationshipType</code> explícito. Settings de la organización padre heredan a los tenants hijos; overrides locales quedan auditados.
Mirror automático (v1)
Postear en A genera <code>Draft</code> en B con <code>IntercompanyPartner</code>. Eliminación consolidada diferida a v1.5 — el esquema ya es forward-compatible.
De la compra intercompany al reporte consolidado
- Venta A → B con mirror draft. La subsidiaria A emite factura a B; el sistema crea automáticamente el
Draftde factura de compra en B. El contador de B revisa, ajusta si necesita, y postea — sin discusión sobre si ya se había registrado. - Reconciliación intercompany. El reporte
IntercompanyReconciliationcompara balances intercompany entre tenants del grupo. Discrepancias salen en rojo como parte del checklist de cierre mensual. - Settings en cascada. Plantilla de factura, plan de cuentas template, aprobaciones por umbral — configurado en la organización, heredado por los tenants que no sobrescriban.
- Una identidad, varios tenants (v1.5). Un usuario con acceso a los tres tenants del grupo, un solo login y picker de tenant al entrar. En v1 requiere una cuenta por tenant; la unificación llega en v1.5 vía el servidor de licencias.
- White-label por subsidiaria. Logo, CSS variables y dominio custom (
erp.subsidiariaX.com) configurados a nivel de organización y heredables, o overridables cuando la marca difiere.
Habla con ventas para grupos multi-entidad
Traiga su organigrama legal; le mostramos cómo se modela en jerarquía, cascada e intercompany con sus tres subsidiarias reales en una sesión.