Construction companies frequently operate more than one legal entity under a single ownership umbrella: a family of LLCs, a holding company with subsidiaries, or a general contractor that stands up a joint venture for a specific project. Today, Arcoro Payroll can only process payroll for a single legal entity (a single FEIN) per account

Multi-Entity solves this by introducing a two-level Organization-to-Business Unit hierarchy inside a single Arcoro tenant, so an organization with multiple related legal entities manages all of them under one login, with each Business Unit still processing payroll under its own FEIN.

Enhancements

How Multi-Entity Works for Payroll

The Organization and Business Unit data model

Multi-Entity introduces exactly two layers: a top-level Organization and one or more child Business Units. Deeper nesting (an Organization with subsidiaries that themselves own sub-entities) is not supported in the initla release; users with a three-layer structure need to flatten it to two layers to be onboarded.

• Every Organization, whether the user has one entity or many, has its own Business Unit record representing itself, created automatically at tenant creation with the code "Organization" and no admin action required. Single-entity users never see this and are never blocked by it; it exists purely so the data model is consistent whether or not a user ever adds a second entity.
• Each Business Unit is tied to its own FEIN and its own Check payroll company. Check has no concept of running a single payroll across multiple FEINs, so payroll and tax filing always remain scoped to one Business Unit at a time.
• All Business Units under an Organization share a single Arcoro Company ID. Multi-Entity does not create a separate identity tenant per Business Unit; a person keeps one Arcoro login across every entity they have access to, and that login is what allows a single admin or a shared employee to appear correctly in more than one Business Unit. If this changes in the future, for example splitting Business Units into their own Company IDs, that would be a Hub-led initiative, not a Payroll-driven one.
• This Organization/Business Unit pattern mirrors a design already used elsewhere in Arcoro: ATS, Talent, and Onboarding each already auto-create a default business unit at provisioning today. Multi-Entity Payroll extends that same pattern rather than inventing a new one.

Setup and provisioning

• The Organization is always deployed to Check first. It acts as the master record for pay schedules, rate codes, and locations, even for users who never adds a second Business Unit.
• Each additional Business Unit is provisioned from Hub's Business Unit page. Provisioning creates a distinct Check payroll company (and FEIN) for that Business Unit, and each Business Unit can only be provisioned once.
• When a new Business Unit is provisioned, cost codes, departments, labor classes, rate codes, pay schedules, and locations are shared automatically from the Organization down to the new Business Unit as a background operation. Ongoing changes made at the Organization level continue to propagate down afterward.
• Rate codes, pay schedules, and locations are shared down from the Organization and are read-only at the Business Unit level, showing the message "Changes to this data must be made at the Organization level." Cost code, department, and labor classification setup pages are shared master lists managed at the Organization level regardless of which Business Unit is active.
• Jobs are the one setup list that is genuinely scoped per Business Unit: the Organization view shows every job, while inside a Business Unit only jobs assigned to that Business Unit are visible. This same job-level scoping is reused for both wage determination and general ledger processing.
• The Setup > Business Units page itself is only accessible at the Organization level; it is blocked entirely (not redirected) when accessed from inside a Business Unit.
• Company Settings gains a new "Multi FEIN" settings group with two settings, General Ledger and Wage Determination, each configurable per Business Unit as either "Use Organization Level" (inherit the Organization's configuration, the default) or "Use Business Unit" (configure independently). Switching a Business Unit from "Use Business Unit" back to "Use Top" permanently deletes that Business Unit's own GL or Wage Determination mappings after a confirmation prompt; there is no way to restore them afterward, so this choice should be made deliberately during setup.
• Existing users who were on the platform before this release automatically receive a one-time backfill that creates the Organization-representing Business Unit record they were missing. No user action is required.

The Company/Business Unit selector and user experience

• A selector control sits in the Payroll banner, between the company name and the Payroll product switcher, listing only the Business Unit name for each entity, with the Organization Business Unit always pinned to the top of the list to indicate its place in the hierarchy.
• The selector only becomes an interactive dropdown for users who have access to two or more entities. A user with access to only one entity sees plain text, with no dropdown, since there is nothing to switch between.
• Selecting a different entity from the dropdown opens that entity in a new browser tab. There is no "recently used" shortcut list and no "all entities" combined view; the list always shows every entity the current user can access.
• The same expanded, multi-column entity picker is also available on the Configuration page's company selector for administrators.
• There is no consolidated, cross-entity payroll dashboard. Administrators, whether one person manages every entity or each entity has its own administrator, navigate into each Business Unit individually to run that entity's payroll. Running payroll for three Business Units is three separate visits, not one combined action.

Permission model

• Application Administrator and Application Read-Only roles see every entity in the Organization automatically.
• The four single-tenant roles (Payroll Administrator, Controller, Manager, Employee) only see the specific entities they have been explicitly granted access to. Only Application Administrator can grant access to other roles. Payroll enforces this Business Unit-level security within its own product, on top of the shared Arcoro Company ID described above; this is also what a reassignment (below) checks against, since the admin performing a reassignment must have access to both the source and destination Business Unit.

Employee and contractor assignment and reassignment

• Each person should belong to exactly one Business Unit at a time. Business Unit is an employment-level field owned by Hub/Core HR (the same as job code or location), not a field Payroll owns; Payroll consumes the assignment through sync. Core does allow more than one Business Unit. (This is called "Employer" in Core.) Because the active entity context already implies the Business Unit, the Payroll People/Demographics screen removes the Business Unit field entirely rather than showing it read-only.
• Moving a person between Business Units is treated as a new legal employer event, not a simple record edit. Year-to-date federal and state tax accumulations reset under the new FEIN, and a separate W-2 (or 1099-NEC for contractors) is issued per FEIN worked during the year. Direct deposit, W-4, and state withholding elections are re-established in the new entity.
• The destination Business Unit must already be provisioned for payroll before a reassignment can occur; there is no "pending" or "pay when ready" state in Iteration 1.
• A reassignment requires an administrator who has access to both the source and destination Business Unit.
• Whether accrued PTO transfers, is paid out, or is zeroed on reassignment, and whether a reassignment can later be reversed, are policy questions being finalized with Check and are called out under "Known Gaps" below, since no ticket in this release resolves them.

Payroll processing, reporting, and pay stubs

• Import files, the Payroll Importers, the Payroll Processing UI, and both general and payroll-processing reports are all automatically scoped to the Business Unit.
• The Pay Stub Controller aggregates a person's pay stubs across every Check payroll company they have ever been assigned to over their tenure, not just their current entity, since someone may have paystub history in more than one Business Unit after a reassignment.
• Workplaces API calls that reference only the top-level Arcoro identifier (without a specific Business Unit) resolve to the Organization/root entity, since that lookup would otherwise be ambiguous once multiple entities exist under one user.
• Aggregated or consolidated reporting across FEINs from within Arcoro is out of scope for Iteration 1. A future iteration may address this using the data warehouse (with an expected reporting delay, likely around 24 hours, rather than real time).

Integrations and sync changes

• Shared, Organization-level master lists (cost codes, departments, labor classifications, unions) sync at the shared Organization level regardless of which Business Unit a connector is scoped to; the sync's audit trail records which Business Unit triggered the sync.
• Per-entity data (time records, expenses, time-off balances, employee/contractor records) syncs scoped to whichever specific Check payroll company the connector is configured for.
• General ledger and wage determination sync automatically follow the same Organization/Business Unit resolution used by the UI and processing engine, based on each Business Unit's "Use Top" or "Use Business Unit" setting; no separate sync-side configuration is needed.
• The Core HR reader is extended to read the Employer field and map it directly to Business Unit, replacing the previous Spectrum-specific mapping that relied on the Facility 1 field or a UDFL flag. Spectrum's existing "Entities" (used for benefits sync) are unaffected and continue to sync separately from Business Unit. The Spectrum "Company Codes" setting is replaced by a "Business Units" multi-select (matched by each employer's External Employer Code); users re-select their Business Unit(s) once this ships, since prior Company Codes values do not carry forward automatically.
  • Because Core HR allows an employee to be assigned to more than one Employer while the Arcoro Employee Model supports only a single Business Unit per person, the sync enforces a single-Employer rule at the point of sync: if an employee has more than one active Employer assigned in Core HR, that employee's sync errors with the message "The employee is assigned to more than one Business Unit (employer) in Core HR. Only a single Business Unit is supported. Assign a single Business Unit to this employee in Core HR and run the sync again." Roughly 200 existing companies currently have at least one employee assigned to multiple Employers in Core HR; those specific employees will need a Core HR cleanup (a single Employer assigned) before they sync successfully once this ships.
• Time records sync from Arcoro Time to Payroll already separated by Business Unit and Employee, so once a user's Business Units are set up, incoming time data routes to the correct entity automatically.
• The Payroll connector's configuration field currently named CompanyId is renamed to OrganizationId to remove ambiguity now that multiple entities can exist under one user, with a data migration for existing production connectors.

Multi-Entity Across Other Arcoro Products

• Hub (core platform): Hub owns the canonical Business Unit record for a user (identifier, name, active status), including automatically representing every Organization with its own Business Unit. Hub's Business Unit page is where additional Business Units are provisioned. Business Unit is also shown and editable on the Employee profile and the Job profile in Hub. There is also a Business Unit list screen that is user-facing that will not allow Business Units to be provisioned.
• Core HR: Core HR's Employer field is the source for a person's Business Unit assignment, read directly by the sync layer as described above. This is scoped to Core HR (and its Spectrum connector specifically) for this release; extending the same Employer-to-Business-Unit mapping to Arcoro's other ERP connectors (CMIC, Acumatica, HCSS, Vista, Sage, and others) is a separate, broader initiative that has not yet been scoped for delivery (see "Known Gaps").
• Arcoro Time (formerly ExakTime): Supports Multi-Entity through Business Units today, using the same single-instance model as Core HR: all of a user's company data lives in one Arcoro Time account, and Business Units synced in from Sage Intacct scope that data by entity. There is no dedicated Business Unit management screen in the Arcoro Time user interface; Business Units are populated from the Intacct sync rather than created or edited directly inside Time. Time records sync from Arcoro Time to Payroll already separated by both Business Unit and Employee. As in Payroll, an employee cannot be assigned to more than one Business Unit at the same time in Arcoro Time.
• Onboarding: Administrators configure a distinct new-hire experience (welcome message, required documents, videos, Business Unit-specific information) per Business Unit, with a defined fallback: a person's Business Unit experience, then the company's default experience, then a system-generated default. Business Units in Onboarding are created during implementation through an internal system administration tool; users do not create them themselves, and they do not change often.
• ATS, Talent, LMS, and Performance: A Business Units tab in the unified Employee Management experience shows which Business Units a person administers, carried over from the legacy Talent product. Beyond that, a broader multi-entity plan for these products has not yet been scoped (see "Known Gaps").
• Advanced Analytics: Not part of this release; multi-entity/Business Unit-scoped reporting has not yet been scoped for Advanced Analytics (see "Known Gaps").

How Data Flows Between Products

Hub is the source of truth for a user's Business Unit record. Each product that needs to know a person's, job's, or location's Business Unit keeps its own local copy of that assignment, synced in from Hub or resolved from the user's source system:

• Payroll stores the assignment in its own person-to-business-unit table, populated during the normal employee and contractor sync, and enforces its own Business Unit-level access checks on top of it, as described above.
• Core HR (through the Integrations framework) resolves Business Unit from its own "Employer" field on the employee and contractor models it exchanges with other products, as described above.
• Arcoro Time receives Business Unit assignment through the Sage Intacct sync (not through a UI inside Time) and carries that assignment onto the time records it sends to Payroll, which is what lets Payroll separate incoming time data by both Business Unit and Employee.

In practice, data separates into two patterns as it moves between products once Multi-Entity is set up for a user:

• Organization-level shared data cost codes, departments, labor classifications, unions) stays at the shared Organization level no matter which Business Unit a given sync connector is scoped to.
• Per-entity data (time records, expenses, time-off balances, employee and contractor assignments, pay schedules matched by name) is read from and written to whichever specific Check payroll company (Business Unit) the connector is pointed at.

General ledger and wage determination data automatically follow whichever setting each Business Unit is configured to use ("Use Top" or "Use Business Unit"), so the sync layer needs no separate configuration for that split.

FAQs

Can an employee be paid from two entities in the same pay period?

Not in the initial release, in either Arcoro Time or Payroll. A person is active in exactly one Business Unit at a time. Moving between entities is supported, but it is treated as a new legal employer event (new W-2/1099, reset tax accumulations), not a split-pay arrangement. If this comes up with a prospect, treat it as a discovery topic rather than an automatic disqualifier, since it is a candidate for a future enhancement.

What entity types can't be onboarded?

S-corporations, partnerships, and LLCs taxed as pass-throughs cannot be processed by Check. Each entity in a user's structure is checked individually against this before committing to Multi-Entity.

What happens if an employee has more than one Employer set in Core HR?

The sync blocks that employee with an explicit error until a single Employer is assigned in Core HR. This affects a real, if small, population of existing users and should be flagged during qualification and cleaned up before go-live.

Does every Arcoro product support Multi-Entity the same way?

No, and not every product manages Business Units the same way. Payroll, Hub, Core HR (Spectrum), Arcoro Time (via Sage Intacct), and Onboarding all support Business Unit-scoped data today. Arcoro Time has no dedicated screen to manage Business Units directly; only Intacct feeds it. Advanced Analytics and the broader Talent suite are not part of this release; see "Known Gaps."

Can I see one consolidated general ledger or report across all of their entities inside Arcoro?

Not in the initla release. GL configuration and reporting are per-entity. A future iteration may use the data warehouse for cross-entity reporting, with an expected delay of roughly a day rather than real time.

How does Multi-Entity work at the identity/login level? Is each Business Unit a separate tenant?

No. All Business Units under an Organization share a single Arcoro Company ID; Multi-Entity does not introduce a separate identity tenant per Business Unit. A person has one Arcoro login across every entity they can access. Payroll itself enforces which Business Units that login can act on, rather than the entity boundary being a separate identity tenant. If the single-Company-ID model changes in the future, for example splitting Business Units into their own Company IDs, that would be a Hub-led initiative rather than a Payroll-driven one.