cifraHQ Enterprise
Multi-entity

For the group with three companies and one CFO.

Party hierarchy with <code>ParentPartyId</code>, settings cascading from the parent organization, cross-subscription via the license server, and intercompany with automatic mirroring. Built for real accounting firms, franchises and holding groups.

Request a demo See Operations cluster
The hierarchy

Party hierarchy with typed relationship

The base model is ParentPartyId with an explicit RelationshipType enum. Children are financially independent in v1 — each has its own tenant and its own general ledger. The hierarchy documents the relationship; it does not blend the accounting.

  • Subsidiary. Filial company with its own financial statements. Reports to the parent for consolidation but operates with a separate ledger, bank account and tax filings.
  • Branch. Branch of the same legal entity. The type exists for groups that operate with separately-booked branches (common in LATAM).
  • Franchise. Franchisee under contract with the parent. Usually pays royalty — the relationship is documented even though operations are independent.
  • Department. Internal division of the same company managed as a separate tenant due to scale. Less common; exists for operations with volume that justifies technical isolation.
  • Other. The catch-all for atypical relationships — joint ventures, alliances, structures that don't fit the other four.

The schema is forward-compatible with multi-level consolidated AR/AP and consolidated financials — functionality deferred to v1.5/v2. The structure exists today; the financial aggregation ships later.

Cascading settings

One place to configure the group

  • Organization as settings node. An organization groups tenants. Settings configured at the organization cascade by default to child tenants — document templates, approval policies, COA templates, report configurations.
  • Override per tenant. Any setting can be overridden at the child tenant. The cascade is default, not mandatory. Auditors can see what was inherited and what was modified locally.
  • Inheritable white-label branding. Logo, CSS variables and custom domain (erp.acmecorp.com) configure at the organization and inherit — or override per subsidiary when the brand differs.
  • Versioned document templates. If the organization updates its invoice layout, child tenants inherit the new version. Those that overrode locally keep their version — no silent regressions.
Cross-subscription

The license server ties the group

  • One subscription, many tenants. The license server (P4S_Licenses) lets one Stripe subscription cover multiple tenants. Aggregated billing to the group, not per-tenant.
  • Edition-driven entitlements. Feature flags and concurrent-user caps travel from license to tenant at login time. The organization admin sees aggregated usage and available limits.
  • Cross-tenant identity (v1.5). One user with access to three tenants in the group — one login, tenant picker on entry. Solved at the license layer in v1.5; in v1 requires one account per tenant.
  • Weighted feature voting. Enterprise subscriptions have 3× weight on the feature request board — the multi-entity group accumulates voice proportional to business size.
Intercompany

Transactions between tenants in the same group

When subsidiary A sells to subsidiary B, the accountant's manual says "record in both books." In practice, 60% of monthly disputes come from one recording it and the other not.

  • IntercompanyPartner per tenant. Each tenant declares which other tenants in the group are official partners. Explicit mapping — intercompany does not post with any tenant, only with authorized ones.
  • Automatic mirroring. When an intercompany document posts in tenant A, the system automatically generates a Draft document in partner tenant B. B's accountant reviews, adjusts if needed, and posts.
  • Draft preserves autonomy. The mirror does not post automatically — B remains owner of its ledger. But no more "did they record it or not?" — the draft is waiting.
  • Intercompany reconciliation. The IntercompanyReconciliation report compares intercompany balances between group tenants. Discrepancies show in red; part of the monthly close checklist.
  • Consolidated elimination (v1.5). Elimination journal entries for consolidated statements are deferred to v1.5. In v1 the group generates the view; formal elimination happens outside the system or in the next release.
What v1 ships vs. v1.5

Roadmap clarity

v1 (today)

Hierarchy + cascade + manual intercompany

ParentPartyId with typed relationships, cascading settings, inheritable white-label, intercompany with automatic draft mirror, reconciliation report.

v1.5

Cross-tenant identity + elimination

One login across group tenants and consolidated elimination journal entries. Design begins when core modules close.

v1.5/v2

Consolidated AR/AP

Multi-level AR and AP consolidation. The schema is already forward-compatible; financial aggregation ships later.

Multi-entity demo with your real structure

Bring your legal org chart; we show how it models as hierarchy, settings and intercompany in one session.

Schedule demo