Knowledge graphs for multi-entity and holding companies

In this article

• Why multi-entity reporting breaks flat data models
• Separate charts of accounts per entity
• Intercompany transactions and eliminations
• Shared customers across entities
• Roll-up and drill-down as graph traversal
• Currency across entities
• Per-entity access boundaries
• Consolidation without a data warehouse
• Where SIGNLD fits
• FAQ

Why multi-entity reporting breaks flat data models

A holding company or a group with multiple subsidiaries runs into a structural problem that single-entity businesses never face: the same question, "what is our revenue," has to be answerable at the entity level, at the roll-up level, and often at intermediate groupings such as a region or a business line, all from the same underlying data. A flat data model, one big table of transactions with an entity code column, can technically hold this data, but every roll-up, every elimination, and every drill-down has to be rebuilt as a new query or a new report, and the logic for which entities eliminate against which others tends to live in someone's spreadsheet rather than in the data itself.

For the wider context, see our knowledge graph glossary of 40 terms.

A knowledge graph handles this differently by modeling entities as first-class nodes connected by explicit relationships: ownership percentages, intercompany trading relationships, shared customer records, and reporting hierarchies. Because these relationships are edges rather than query logic, a roll-up is a traversal of the ownership hierarchy and an elimination is a traversal of the intercompany edges, both reusable for any question asked later, not rebuilt each time.

Separate charts of accounts per entity

Subsidiaries acquired at different times, or operating in different countries, rarely share an identical chart of accounts. One entity might book "freight" as a cost of goods sold line, another as an operating expense, and a third might not separate freight out at all. In a graph model, each entity keeps its own chart of accounts as its own node structure, and a mapping layer, itself made of edges, links each entity's accounts to a normalized group-level account taxonomy.

This separation avoids the common failure mode of forcing every subsidiary onto one standardized chart before consolidated reporting can happen, a project that can stall for a long time on entities that were never designed to fit a shared structure. The mapping edges let each entity keep its native accounts while still supporting a consistent group view, and a wrong mapping can be corrected without touching any other entity's structure.

Intercompany transactions and eliminations

Intercompany transactions, one subsidiary invoicing another, a management fee charged between entities, inventory transferred at a markup, have to be identified and eliminated before a consolidated number is accurate, otherwise revenue and expense get double counted across the group. In a graph model, intercompany transactions are represented as edges directly between two entity nodes rather than as two independent transactions that happen to reference each other, which makes the pairing explicit instead of inferred after the fact by matching amounts and dates.

Elimination logic then becomes a traversal rule: when computing a consolidated figure, any edge marked as intercompany between two entities included in the consolidation scope is excluded from the total. This is meaningfully different from elimination in a traditional consolidation tool, where eliminating entries are usually manual journal entries created during the close process. In a graph, the elimination is a property of the relationship between the two transactions, so it is reusable the next time the same question is asked, and it does not depend on someone remembering to book the same elimination entry again next period.

Shared customers across entities

Many multi-entity groups sell to the same customer through more than one subsidiary, a customer that buys a core product from one entity and a service contract from another, for example. Answering "what is our total relationship with this customer across the group" requires recognizing that records in two different entities' CRMs or billing systems refer to the same underlying customer, which is the entity resolution problem applied across entity boundaries rather than within one system.

Once a shared customer is resolved to a single node connected to records in each entity, questions that were previously answered entity by entity, requiring someone to manually combine spreadsheets from each subsidiary, become a single traversal: sum every order and invoice edge connected to that customer node, regardless of which entity originated it. This also surfaces risk that a holding company genuinely cares about, such as a customer that looks profitable in one entity but is a net risk once an unpaid balance in a different entity is included.

Roll-up and drill-down as graph traversal

A group hierarchy, entities rolling up into regions, regions rolling up into the parent, is naturally represented as ownership edges between entity nodes. A roll-up query starts at the parent and traverses down through every owned entity, summing whatever metric is being asked about, weighted by ownership percentage where a subsidiary is not wholly owned. A drill-down is the same traversal run in reverse: starting from a consolidated number and expanding into the entities and transactions that produced it.

Because both directions use the same edges, a group can answer "why did consolidated gross margin drop this quarter" by drilling from the consolidated figure through regions, into entities, and down to the specific transactions responsible, without switching tools at any step. This also makes irregular hierarchies easier to handle, a subsidiary reporting into two different regional groupings can be modeled with two separate roll-up edges rather than one rigid hierarchy.

Currency across entities

Subsidiaries operating in different countries transact in different functional currencies, and a consolidated figure has to convert each entity's numbers into a single reporting currency using an appropriate rate, typically an average rate for the period for income statement items and a period-end rate for balance sheet items. In a graph model, currency is a property carried on each transaction and account node, and the conversion is applied during traversal rather than by rewriting the underlying transaction, which preserves the original entity-level figures for local reporting and audit while still producing an accurate consolidated view.

This matters for reconstructing a number later: the graph retains the original local-currency transaction and the rate applied, rather than only the converted total, so the calculation can be verified rather than trusted on faith.

Per-entity access boundaries

A holding company frequently needs to give a subsidiary's own finance team access to that entity's data without exposing sibling entities' figures, while a group controller needs visibility across everything. This is the same permission problem covered in row-level permissions across systems, applied to entity boundaries: access rules attached to entity nodes determine what a given user can traverse, so a subsidiary controller's queries are scoped to their own entity while a group-level user's queries traverse the full structure.

Because these boundaries live on the graph itself, the same model supports both the entity-level and group-level user without maintaining two parallel systems.

Consolidation without a data warehouse

Traditional multi-entity consolidation usually assumes a project to get every subsidiary's ERP data into a common warehouse schema before consolidated reporting can run, which is a heavier lift the more subsidiaries were acquired rather than built, since acquired entities often run on different ERPs entirely. A graph approach connects to each entity's system as it is, keeps each entity's native structure intact, and builds the group-level view through the ownership, intercompany, and mapping edges described above, rather than through a physical merge of every entity's data into one warehouse schema.

This does not eliminate the real work of defining ownership percentages, intercompany relationships, and account mappings, but a newly acquired entity can be included in group reporting once its mapping is defined, rather than waiting on a warehouse migration project.

Comparison: flat multi-entity spreadsheet vs. traditional consolidation tool vs. graph-based model

Aspect	Flat spreadsheet rollup	Traditional consolidation tool	Graph-based model
Per-entity chart of accounts	Manually reconciled each period	Supported, with mapping setup	Supported natively via mapping edges
Intercompany eliminations	Manual journal entries	Manual journal entries during close	Modeled as edges, reusable automatically
Shared customer view across entities	Rarely attempted	Not typically supported	Supported via entity resolution
Drill-down from consolidated to transaction	Difficult, often impossible	Supported within the tool's own data	Supported as reverse traversal
Requires a data warehouse	No, but breaks at scale	Often, for source data	Not required
New entity onboarding	Rebuild spreadsheet logic	New ERP integration project	Connect source, define mapping edges

Where SIGNLD fits

SIGNLD builds a private knowledge graph across the systems a company connects, which extends naturally to multi-entity structures: each subsidiary's ERP, CRM, or spreadsheet can be connected as its own source, with ownership, intercompany, and shared-customer relationships modeled as edges rather than resolved in a separate consolidation step. Connections are read-only across 800+ integrations, spreadsheets are treated as first-class sources for entities still running on them, and answers are returned as Decision Briefs, the finding, evidence linked back to the originating entity's source records, a confidence score, and a recommended action, so a group controller can drill from a consolidated figure down to the specific subsidiary transaction behind it.

Related reading in this series: Knowledge graph maintenance: what it actually takes to keep one current and Knowledge graph security: row-level permissions across systems.

Key takeaways

• Subsidiaries acquired at different times, or operating in different countries, rarely share an identical chart of accounts.
• Many multi-entity groups sell to the same customer through more than one subsidiary, a customer that buys a core product from one entity and a service contract from another, for example.
• A holding company frequently needs to give a subsidiary's own finance team access to that entity's data without exposing sibling entities' figures, while a group controller needs visibility across everything.
• Traditional multi-entity consolidation usually assumes a project to get every subsidiary's ERP data into a common warehouse schema before consolidated reporting can run, which is a heavier lift the more subsidiaries were acquired rather than built, since acquired entities often run on different ERPs entirely.
• The new entity's systems are connected as new sources, its chart of accounts is mapped to the group taxonomy, and ownership and intercompany edges are defined connecting it to the rest of the structure.

FAQ

Does a knowledge graph replace our consolidation software?

Not necessarily. A knowledge graph can model the entity relationships needed to answer roll-up, drill-down, and cross-entity questions directly, but many groups keep dedicated consolidation software for statutory close and audited financial statement production, and use the graph for faster operational and analytical questions in between formal close cycles.

How does the graph know which transactions are intercompany?

Intercompany transactions are identified either from flags already present in source systems, such as an intercompany customer or vendor code, or by matching characteristics like amount, date, and counterparties across two entities' records, similar to the entity resolution process used for shared customers. Once identified, the relationship is stored as an edge between the two transactions.

Can this handle partially owned subsidiaries?

Yes. Ownership percentage is stored as a property on the ownership edge between the parent and the subsidiary, and roll-up traversals apply that percentage when computing consolidated figures, which supports minority interest calculations without a separate manual step.

What happens when we acquire a new entity?

The new entity's systems are connected as new sources, its chart of accounts is mapped to the group taxonomy, and ownership and intercompany edges are defined connecting it to the rest of the structure. Once that mapping work is done, the entity is included in existing roll-up and drill-down queries without those queries needing to be rewritten.

Does each subsidiary need to standardize its chart of accounts first?

No. Each entity keeps its native chart of accounts, and a mapping layer connects it to a normalized group-level taxonomy. This avoids forcing a standardization project before consolidated reporting can happen, though a cleaner shared chart does make mapping less work over time.

Try SIGNLD free to connect your subsidiaries' systems as they are, or see how it works. Related terms are defined in the knowledge graph glossary.