Running HR across more than one legal entity

Most HR software is designed for a company. Plenty of companies at twenty to two hundred people are not one company. They are a holding company and an operating company, or a home entity and a subsidiary opened when headcount in the second country outgrew an employer of record, or a main business and a small acquisition whose entity nobody has got round to collapsing.

The moment you have two, a set of things that were singular become plural, and the ones that quietly stay singular are where the problems come from. This guide sets out what changes, what to model deliberately, and which mistakes are expensive to reverse.

What goes plural

Employment itself. A person is employed by an entity, not by the group. This sounds pedantic until someone asks who the employer is on a contract, which entity a notice period runs against, or which company a tribunal claim names.

Policies. Leave entitlements, notice, working hours and probation are set by the law of the place and the practice of the entity. A single leave policy applied across a group is either generous in one place or unlawful in another.

Holiday calendars. Public holidays differ by country and often by state or region within one. A single company-wide holiday list stops being true the day you open the second entity.

Approvals. An expense approved by a manager in one entity may be a cost sitting in another entity’s accounts. Intercompany recharges are a finance problem, but the approval routing that feeds them is an HR system problem.

Payroll. Each entity has its own statutory position, its own cycle, its own cut-off and, usually, its own payroll partner or accountant. This is the thing that stays plural permanently.

Reporting. Somebody will want headcount for the group and somebody else will want headcount for one entity, sometimes as a statutory filing. Both have to be available without a reconciliation.

Permissions. Not everyone who administers HR for one entity should be able to read the records of another, particularly where an acquisition is involved or where a local finance lead has access for their own country only.

What should stay singular

The directory. One place holding every person in every entity, employees and contractors together. This is the decision everything else depends on, and it is the one most often got wrong, because separate entities feel like they should have separate systems.

They should not. Two systems means two directories, no reliable group headcount, a duplicate record for anyone who transfers, and a manual reconciliation every time somebody asks a question about the whole company. It also means twice the vendor diligence and twice the exit risk.

The policy library. Common policies written once with local annexes, rather than three handbooks drifting apart. How to write an employee handbook sets out the core-plus-annexe pattern.

The audit trail. One log of what happened across the group, filterable by entity. If the record of what was done to your data is split across systems, nobody can answer a question that spans them.

The exit. One export that contains everything, so leaving your HR vendor is one migration rather than several. Start your shortlist with the export makes the general case.

Model the entity as a first class thing

The practical test of an HR system for a multi-entity company is whether the entity is a real object in it or a text field on a person.

If it is a text field, everything downstream is a filter someone remembers to apply. If it is a real object, four things become possible without workarounds:

• A person belongs to an entity, and their employment record carries it, so the employer on a letter is generated correctly rather than typed.
• Policies attach to an entity, so leave rules, holiday calendars and probation terms can differ where they must and be shared where they can.
• Approval chains route by entity, so a request goes to the right approver in the right company.
• Reporting rolls up or filters down, so group headcount and entity headcount are both one query.

The Capstan core models entities this way: leave policy per entity, region or grade, holiday calendars applied by each person’s work location, onboarding and exit checklist templates per role or entity, and contractor engagements pointed at the paying legal entity. The Contractor Management module uses the same entities the core already holds rather than a second list of them.

Transfers between entities

This is the event that exposes whether your record-keeping is real.

An internal move from one entity to another is not an edit to a row. The employment with the first entity ends and a new employment begins, and that has consequences: service-based entitlements may or may not carry over, notice terms may change, statutory contributions start and stop in two systems, and the tax position in both places needs handling. Take local advice on the transfer itself.

What the system has to do is hold both employments in sequence with their effective dates, so that a question asked in three years about continuity of service, or about what someone earned in a particular month, has an answer. A system that overwrites the old row has destroyed the only evidence of the first employment. Capstan makes changes effective-dated for exactly this reason, and the wider argument is in an HR system is a record of the past.

Payroll stays plural, and that is correct

Each entity computes payroll under the rules of its own jurisdiction, which change at their own pace and are administered by different authorities. There is no version of this where one engine is genuinely current everywhere, which is why the honest architecture keeps the system of record and the system of computation apart. That argument is set out in why payroll should be a partner.

What a single record gives you is a single origin for the inputs. Attendance, approved leave, overtime, compensation changes, joiners, leavers and prorations all live in one place, and each entity’s partner receives them in a documented format rather than in a spreadsheet a different person assembles each month. The Payroll module compiles that export per pay group, with provenance on every line and variance flags against the previous period, and files the returned payslips and results back onto each person. It computes nothing and holds no rate, slab or formula for any country.

Practically, model pay groups per entity from the start. Retrofitting pay groups after six months of running one is a re-implementation.

Permissions, and the acquisition problem

Multi-entity permission questions are usually acquisition questions in disguise.

When you acquire a small company and keep its entity alive, three groups appear: people who should see everything, people who should see only the acquired entity, and people in the acquired entity who should see only their own. Decide this deliberately on day one, because permissions granted in a hurry during integration are permissions nobody revisits.

The same applies to a local finance or HR lead in a second country. Their legitimate need is their entity, and giving them group-wide administration because it is faster is the sort of decision that shows up in a customer’s security questionnaire two years later. How to answer an HR security questionnaire covers what reviewers ask about access.

The mistakes that are hard to undo

Starting with two systems. Reconciling two directories into one later is a migration with a data cleanup attached, and it is a much larger job than modelling entities properly at the start. If you are implementing now, entities come first in the configuration order; the HRIS implementation checklist sets out why.

Treating the entity as a label. If it is a text field, it will be inconsistent within a quarter, and every report will need a human to sanity check it.

Overwriting on transfer. Once the first employment record is gone, it is gone. Service history, old compensation, the original contract, all unavailable to the question that eventually gets asked.

One holiday calendar. Trivial to fix on day one, endlessly annoying later, because every leave balance computed against the wrong calendar has to be recomputed.

Assuming reporting will sort itself out. If somebody needs entity-level headcount for a statutory filing, that is a deadline. Check it is a query and not a project before the deadline exists.

Where to start

If you are about to become a two-entity company, do three things before the second entity has its first employee.

Model the entity in your HR system and check that policies, approvals and reporting can all differ by it. Decide the permission model, including who sees what across entities. And agree the payroll partner and the export format for the new entity before its first cut-off, rather than after.

Everything else about a second entity is administration. Those three are architecture, and architecture is the part that is expensive to change later.