The multi-entity problem
Indian holding-company structures are common: one group, multiple legal entities, each with its own PAN, its own EPFO establishment, its own ESIC sub-code, sometimes its own bank. Payroll must compute correctly for each entity in isolation, while the parent tenant sees a unified view for reporting.
Most HRMS platforms treat each entity as a separate tenant. That works until the parent needs cross-entity reports, or until an employee transfers between entities and the migration of data becomes a manual process.
How we model it
We use row-level isolation under a shared tenant. Every payroll-relevant record carries an entity_id. Most queries are entity-scoped by default; cross-entity queries require explicit opt-in and a permission grant. The PF, ESIC, PT, and TAN codes are stored per entity, never on the parent.
The trade-off is database complexity. We invest heavily in query performance to make sure the entity scope cost is sub-millisecond. Background ETL handles the parent-level rollups asynchronously.
The migration story
Customers move to multi-entity from one of three starting points: a single-entity setup that grew, a competitor product, or a manual spreadsheet workflow. Each migration has a different shape. The single-entity grow-out is the easiest; the competitor migration is the hardest because of data-quality variance.
Our standard migration is thirty days for a five-entity, two-thousand-employee tenant, with a parallel run in the last week. Larger migrations get scoped individually. Talk to us for a scoping conversation.
Gotchas at scale
At five thousand employees and fourteen entities, three things bite. First, EPFO downloads return larger files than the documented limit; we now stream them. Second, TDS computations across multiple PANs can produce edge cases when an employee transfers mid-year; we documented and tested twenty-three such transitions. Third, PT slabs differ by state and can change mid-cycle; we re-run the validator on every cycle.