Three companies, three books. One organization that configures and audits.
Holdings, franchises and family groups need independent books per legal entity and central control for the group CFO. cifraHQ physically separates the books and unifies administration in a single organization.
The four pains of the multi-entity group
- Real data isolation between companies. Auditors and partners demand that subsidiary A's data does not live in the same database as subsidiary B's.
DB-per-tenantdelivers physical isolation: each company has its own SQL database with its own backup and retention policy. One tenant's schema never sees another's data. - Configure once, inherit everywhere. Invoice templates, chart of accounts, approval policies — the group CFO has no time to configure them three times. Organization-level settings cascade to child tenants; any one can be overridden locally with the override audited.
- Transactions between subsidiaries that get posted on one side and forgotten on the other. The manual says "book both sides"; reality says 60% of monthly disputes come from this.
IntercompanyPartnerdeclares the official relationship; posting an intercompany document in tenant A automatically generates aDraftin partner tenant B — ready to review and post. - One subscription, several books. Group tenants share a contract but each is an independent book. The
P4S_Licenseslicense server ties the subscription to multiple tenants, reports aggregate usage and enforces edition entitlements — without separate invoices per company.
Three concrete mechanisms
DB per tenant
Each legal entity has its own <code>DB-per-tenant</code> with its own backup and retention. An isolation fuzzer in CI verifies no query crosses the boundary.
Party hierarchy + cascade
<code>ParentPartyId</code> with explicit <code>RelationshipType</code>. Parent organization settings inherit to child tenants; local overrides stay audited.
Automatic mirror (v1)
Posting in A generates a <code>Draft</code> in B via <code>IntercompanyPartner</code>. Consolidated elimination is deferred to v1.5 — the schema is already forward-compatible.
From the intercompany purchase to the consolidated report
- A → B sale with draft mirror. Subsidiary A issues an invoice to B; the system automatically creates the draft purchase invoice in B. B's accountant reviews, adjusts if needed, and posts — no argument about whether it was booked.
- Intercompany reconciliation. The
IntercompanyReconciliationreport compares intercompany balances across group tenants. Discrepancies surface in red as part of the monthly close checklist. - Cascading settings. Invoice template, chart of accounts template, threshold approvals — configured on the organization, inherited by tenants that don't override.
- One identity, several tenants (v1.5). A user with access to all three group tenants, one login and a tenant picker. In v1 this requires one account per tenant; the unification lands in v1.5 through the license server.
- White-label per subsidiary. Logo, CSS variables and custom domain (
erp.subsidiaryX.com) configured at the organization and inheritable — or overridden when the brand differs.
Talk to sales for multi-entity groups
Bring your legal org chart; we'll show how it models as hierarchy, cascade and intercompany with your three real subsidiaries in one session.