How to Choose HR Software for a Multi-Company Organization

Most multi-company HR conversations start with the same instinct: we need one system across all our entities. When this conversation surfaces, most groups already feel the strain somewhere. One entity runs payroll differently from another. HR starts reconciling reports manually between entities. An employee transfers between entities and suddenly appears twice in reporting. Someone starts asking ‘Do we need one HR system across all our entities?’  That instinct is right about half the time. The other half, the right answer is an intentional decision about what to centralize, what to localize, and whether one system is even the architectural goal.

A multi-company HRIS, sometimes called a multi-entity HRIS, is an HR system designed to manage multiple legal entities under shared ownership through a single platform, while preserving entity-specific data, payroll configuration, statutory reporting, and access control. That definition is the easy part. The harder part is deciding which version of “manage” your group actually needs, because the architectural choices behind that word are not the same for every group.

This article walks through that decision. It covers when your current setup starts to break under multi-entity complexity, the three architectural patterns most groups end up choosing between, what features actually matter, why a generic feature checklist is the wrong place to start, and when running parallel systems is actually fine. It is of particular relevance to groups operating in Indonesia, where holding company structures and PT-level statutory complexity make the architectural decision sharper than it is in markets with simpler regimes.

Multi-entity is not the same as multi-country

Before we start, there is one distinction worth drawing clearly. Multi-entity HR is about operating multiple legal entities under shared ownership, often within one country. Multi-country HR is about operating across borders, where statutory regimes change at the country line. The architectural decisions are related but not identical. We address the multi-country question in our piece on Global vs Local HR Systems. This article is about multi-entity, and especially multi-entity within Indonesia, where the dominant pattern is several PT entities under one ownership group rather than operations spread across multiple countries.

The two questions can overlap. A regional group can be both multi-entity and multi-country at once, in which case both architectural lenses apply. But the questions are distinct enough that confusing them produces decisions that fit neither situation cleanly.

When your current HRIS starts to break under multi-entity complexity

Most HR systems are designed around the assumption of one organization. Add a second legal entity and the system can usually accommodate it through configuration. Add a third, then a fourth, and frictions start to show.

That friction is rarely striking. Most of the time, nobody notices the architectural issue directly. People simply start creating workarounds around it. A spreadsheet appears to reconcile headcount between entities. Payroll teams begin keeping their own offline checks. Reports get reviewed twice because nobody fully trusts the consolidated numbers anymore. 

• Headcount reports stop reconciling because employees in shared services roles appear under different entity codes in different reports. 
• Payroll runs that used to take three days now take five, because reconciliation across entities is manual. 
• Statutory filings have to be tracked separately because each PT files its own BPJS and PPh 21, and the system was never built to handle parallel statutory calendars cleanly. 
• Compensation reviews become a copy-paste exercise across entity-specific spreadsheets.
• New employees who join through one entity but report into another sit in operational ambiguity that nobody quite owns. 

None of these are terrible on their own, but taken together they signal that the system may have reached its limitations.

In many cases, the trigger is the third or fourth entity, not the tenth. Groups with two PT entities can run an entity-blind HRIS for a long time by treating one entity’s data as the accepted version and tolerating reconciliation effort on the other. By the third or fourth entity that approach generates more friction than it saves. Recognizing the trigger before it becomes a budget conversation is much cheaper than recognizing it after.

Three architectural patterns for multi-entity HR

Once a group decides to address multi-entity HR architecturally rather than operationally, the question becomes which pattern fits. Most groups end up choosing between three.

A single platform, entity-aware

One HRIS instance hosting all entities, with employees, org structures, policies & payroll configurations tagged by entity.

• Access control is scoped by entity, meaning: HR admin for PT A sees data for PT A but not PT B.
• Reports can be filtered to one entity or rolled up across the group.
• Compliance lives centrally and is delivered per entity through configuration.
• Consolidated reporting is native: the system already holds all the data, so the group view is a query, not a build.

Separate platforms, consolidated reporting

Each entity runs its own HRIS instance, sometimes the same vendor across entities, sometimes a mix.

• A reporting layer sits on top, pulling data from each entity’s system into a group-level view.
• Each entity has operational autonomy: HR teams configure their own platform, run their own payroll cycles, manage their own compliance.
• The group sees consolidated dashboards through the reporting layer rather than through the HRIS itself.
• Compliance is per-entity by default.
• Consolidation is a separate piece of infrastructure, with its own implementation cost and ongoing maintenance.

A federated entity model

Each entity makes its own technology and process choices within shared group standards.

• The group’s holding company usually standardizes governance and reporting expectations, while subsidiaries continue operating differently day to day.
• Consolidation happens at the governance level, through standards and review cycles.
• This pattern is seen in conglomerates with distinctly different operating subsidiaries, e.g. a manufacturing arm, a financial services arm, and a property arm under one holding, where forcing technical alignment is not suitable.

None of these patterns is inherently better. Each fits a different operational reality. The mistake groups make is choosing the first pattern by default because it sounds simplest, and discovering eighteen months later that it doesn’t fit how their entities actually operate.

Why Indonesian PT structures change the architectural decision

Indonesian groups face an architectural pressure that most global articles on multi-entity HR miss entirely. The reason is structural.

A holding company structure under Indonesian law typically involves several PT entities operating with formal legal independence. Each PT files its own BPJS Kesehatan and BPJS Ketenagakerjaan. Each PT files its own PPh 21. Each PT pays its own THR cycle, on its own calendar, governed by its own employment contracts. Where one PT operates in Jakarta and another in East Java, the regional minimum wage rules are different. Where ownership structures involve multiple shareholders or family members, governance crosses entities in ways that the org chart does not always show.

A bundled HRIS platform that works cleanly for one PT can become inconvenient across several. The system has to handle parallel statutory calendars, separate filing identities, sometimes separate banking relationships. None of this is impossible to configure, but most HRIS platforms designed outside Southeast Asia underestimate the depth of the configuration required.

There is a second pressure that is harder to see. Indonesian groups often operate shared services across entities, including finance, HR, IT, sometimes legal. The organizational reality is that one team supports several entities, but the legal reality is that each employee belongs to one PT. This is where multi-entity groups often start discovering that the org chart and the legal structure are not actually the same thing. An HRIS platform has to hold both truths at once: an employee’s legal employer and their operational reporting line, which may not be in the same entity. Systems designed for simple multi-entity setups treat this as an edge case. Systems designed for groups treat it as the default.Architectural decisions made without these pressures in view tend to look reasonable on paper and break in operation. The deeper version of this argument lives in our piece on Global vs Local HR Systems, which addresses the country-level architectural pressure. The multi-entity-within-Indonesia version is its sibling.

 The master employee record question

A question that most multi-entity articles do not address directly, but that comes up in nearly every group HR conversation: when an employee moves between entities, when a person sits on the boards of multiple PTs, when a shared services team operates across several entities, what should the system do?

The answer depends on which architectural pattern is in place, which is why the question gets confusing when the pattern is not explicit.

• In a single-platform, entity-aware setup, the master record is the employee.
  The system holds one record per person, with employment history showing which entity employed them at which time. Transfers between entities update the active employment without creating a new record. A board member sitting on multiple PTs has one record with multiple appointments. This is the cleanest model operationally. It is also the model most groups assume they already have, until they discover during a transfer, promotion, or payroll cycle that the system is actually treating the employee as two different people.
• In a separate-platforms model, the master record is the entity’s record.
  Each platform holds its own version of the employee. When an employee moves, they exit one system and enter another. History fragments unless the reporting layer reconstructs it, which most reporting layers do not do well. Board members appear in multiple systems with separate records. Shared services employees often have to be duplicated or assigned to a primary entity by convention.
• In a federated model, the master record question depends on what the group standard specifies.
  Some groups treat the holding company’s record as central, with entity records flowing from it. Others treat each entity’s record as primary, with group reports built by combining them. This is a governance decision, not an architectural one. 

The practical implication is this: If your group has any meaningful movement of employees between entities, any shared services structure, or any executives sitting on multiple boards, the master record question will surface. Deciding it up front is much cheaper than discovering it during a payroll cycle.

What to actually evaluate

Most articles on multi-entity HR software give you a feature checklist with thirty or forty items and tell you to compare vendors against it. We are going to do something different, because feature checklists organized by HR module — payroll, time and attendance, leave, performance, recruitment — are exactly what makes multi-entity vendor evaluation feel exhausting and can produce decisions that don’t hold up in operation.

The features that actually matter in a multi-entity HRIS group fall cleanly into three categories that map to architectural decisions, not to HR modules. These groups are: data architecture, compliance and reporting, process and governance. When evaluating vendors, ask below questions inside each category rather than ticking a feature list. 

Data architecture. Ask these questions:

• Where does the master employee record live?
• How is entity-specific data segmented?
• How is access control scoped by entity?
• What happens when an employee moves between entities?
• Does the system support one record per employee with multiple employment histories, or does it duplicate employees across entities? 
• Can role-based access be defined so that an HR administrator for one entity sees that entity’s data and nothing else? 
• When an employee transfers, does their history follow them or fragment? 

This category determines whether the system can hold the actual operational complexity of a group, or whether HR will end up doing it manually. When this layer is weak, HR usually compensates operationally. Teams create naming conventions, manual reconciliation processes, and unofficial spreadsheet logic to bridge the gaps the system cannot handle cleanly. 

Compliance and reporting. Ask these questions:

• Is per-entity statutory configuration a native concept or a workaround?
• Does consolidated reporting allow drill-down by entity, location, function, and role? 
• Are audit trails scoped per legal entity for compliance review?
• Does document storage respect entity-level governance?
• Are parallel statutory calendars handled cleanly when one PT runs THR on a different cycle from another or when one entity is closed for audit while another is in the middle of payroll?

This is usually the category where organizations discover whether the system genuinely understands multi-entity operations, or whether HR will spend the next three years building workarounds around it.

Process and governance.  Ask these questions:

• Does workflow routing respect entity hierarchies, so an approval that should stay within an entity does not accidentally route to a group-level approver?
• Does policy management allow shared group policies plus entity-specific overrides without forking into separate documents? 
• Can approval chains be configured per entity?
• Does the system make the governance model legible, meaning which decisions are group-level, which are entity-level, and which are shared?

This category determines whether the system supports how the group actually makes decisions, or fights it. 

The questions that test whether a vendor’s system fits a multi-entity group sit deeper than the demo usually goes. Our Trade-Off Questions worksheet contains the operational-detail version of this evaluation.

When parallel systems are actually fine

For most multi-entity groups, consolidation is the right call. However, there are three exceptions where parallel systems might work better. 

Recently acquired entities that have not yet been integrated operationally are usually better served by their existing systems for a year or two while integration plans take shape. Forcing platform consolidation onto a still-undigested acquisition tends to break both the entity’s operations and the group’s deal logic. In practice, this is where many post-acquisition integrations become unnecessarily painful. The organization is still learning how the new entity operates, while simultaneously trying to standardize systems that nobody fully understands yet. 

Entities with very different operating models, for example a manufacturing PT and a fintech PT under the same group, sometimes benefit from different HR platforms because the systems they need are different. A federated model with shared standards but separate platforms can serve this situation better than forcing unification.

Small groups with low total complexity may not justify the cost of multi-entity tooling at all. Two PTs each with thirty employees, operating in similar industries with similar compensation structures, can often run two parallel instances of a simple HRIS with manual reconciliation cheaper than they can buy and configure a multi-entity platform.

The honest test is this. Does consolidation actually reduce friction in this group, or does it add a new layer of architectural complexity that the group is not equipped to maintain? If the answer is the second, parallel systems with disciplined governance may be the right architecture.

How to actually decide

The decision rarely comes down to features or vendor reputation. It comes down to three operational questions about the group.

How many entities does the group operate, and how integrated are their operations? Two distinctly separate PTs operate differently from five entities sharing a finance team and an HR team.

What does cross-entity movement look like? Are employees commonly moving between entities, do executives sit on multiple boards, are shared services common, or do entities operate as effectively independent businesses?

What is the group’s governance posture? Does the holding company drive standards across entities, or does each entity operate with significant autonomy and the holding company aggregate at a high level?

These are usually the questions that expose whether the group is operationally integrated already, even if the systems are not. The answers tell you which architectural pattern fits, and that, in turn, tells you what features to evaluate. 

A single-platform, entity-aware system evaluated by a federated group will very likely fail the operational test within eighteen months. A federated model imposed on a group with high cross-entity movement will reproduce the manual reconciliation work the group was trying to escape.

Our anchor article on choosing the right HRIS in Indonesia walks through the broader fit framework. Our piece on HRIS vs Payroll software addresses the parallel architectural decision at the systems level. The multi-company question sits inside both, and the architectural answer is sharper once both are in view.

Closing

Most groups operating multiple business arms assume they need one platform across all their entities. And that assumption is generally true — they do need HR architecture built for multi-entity complexity. The decision worth making carefully is not whether to invest. It is what to invest in. 

Because once a group reaches enough operational complexity, the question is no longer whether HR architecture matters. It is which architectural pattern to commit to, what to centralize and what to localize, and how to keep the system aligned with how the group actually operates as the group changes. Only once that is clear can the architecture help the group operate more clearly, rather than quietly creating friction underneath the surface.