How are time and pay separated when one worker serves multiple workplaces?

EWA should keep one unified worker identity while separating operational data by workplace. Timekeeping ID, work, rate, approval, available amount and transactions must be tied to the correct client and period so work from A is never combined with B's rate or policy.

One person, multiple work contexts

A worker may move from client A to B, work at several sites, use different timekeeping IDs, shifts and rates, and report to different teams.

Without a workplace-context layer, one person record can mix unrelated data.

Separate shared identity from workplace data

Layer 1 — Worker identity

Shared name, ID/identity key, worker profile, verified receiving account and overall user status.

Layer 2 — Client or workplace assignment

Separate company_id, timekeeping ID, effective dates, shift, work, rate, policy, approver and payroll period.

One identity does not mean one combined pool of work data.

Why must a timekeeping ID include client context?

One worker can be 00125 at A and EMP778 at B; the same 00125 may also identify different people at two clients.

The key should therefore be:

client/workplace + timekeeping ID → worker profile

In EWA, a national ID can identify the person, company_id identifies the client, and the timekeeping ID is managed per client.

Work records must be separated by workplace

Each record must retain workplace, date, shift, approver, version and status. Do not store only “Worker A — 20 days”; retain “12 days at A and 8 at B” with separate evidence and approvals.

Rates must match the correct workplace and effective time

Rates may differ by workplace and effective date. The Earned Wage Engine should evaluate:

worker + workplace + date/shift + effective policy

before calculating value. Applying B's rate to A's work produces wrong pay even when total days are correct.

Should available pay be calculated separately or combined?

Calculate each source separately first: eligible value, related withdrawals, reserve and status for A and B. Aggregate only when policy allows.

This preserves explainability when one workplace later changes its work data.

The formula needs workplace context

General rule:

Available pay = (approved days × daily rate) − amount received in the period − employer reserve.

For multiple workplaces:

Available A = work A × rate A − received A − reserve A

Available B = work B × rate B − received B − reserve B

The Eligibility Engine then determines the total usable scope under policy.

Transactions must identify the source of earned value

A generic “received VND 500,000” is insufficient when A and B have different payrolls or periods.

Link transactions to period, workplace, covered work/value and cumulative withdrawals. If one transaction draws from several workplaces, retain an explicit internal allocation table.

Separate first, aggregate later.

When a worker moves from A to B mid-period

Use clear effective dates, for example A through 15 September and B from 16 September. Prevent later work from being assigned to A, old IDs from receiving data, A's rate from applying to B, or A's manager from approving B. The transfer is an auditable event.

What if a worker serves two workplaces simultaneously?

Do not assume only one active workplace. Each concurrent assignment needs date range, status, workplace, timekeeping ID, schedule, policy and payroll source.

Whether the user sees one combined amount is a product decision; source data remains separate.

How should approval rights be assigned?

A's approver should see and approve only A's work. B's approver should not view, edit or approve A's details or unrelated transactions without a business need.

What if A's work is edited after money was received?

1. preserve transaction history;
2. return A's record for reapproval;
3. leave B unchanged;
4. recalculate A only;
5. determine the difference;
6. reconcile the relevant A payroll and period.

This is a direct benefit of separating data from the start.

How should period-end reconciliation be separated?

Field	Meaning
Worker	Shared identity
Client/workplace	Work source
Pay period	Settlement scope
Approved work	Input data
Work value	Workplace value
Allocated withdrawals	Amount paid
Difference	Exception
Target payroll	Settlement destination

If a transaction is allocated across two workplaces, allocation rows must total the original transaction.

Common multi-workplace errors

Typical errors include one timekeeping ID for all sites, mixed client work, wrong rates, cross-client visibility, old assignments remaining active, transactions without workplace/period, unclear payroll ownership, duplicates across sources and deleting assignments instead of closing effective dates.

Each system can appear healthy while money is still wrong.

KPIs to monitor

Track workers with multiple assignments, unmatched IDs, work attached to the wrong site, unallocated transactions, transfer differences, assignments without dates, wrong rate sources and multi-workplace complaints.

These measures expose data-model defects, not merely transaction failures.

Conclusion

For multi-workplace workers, sound architecture keeps one identity with multiple separate assignments. Work, timekeeping IDs, rates, approvals, availability and payroll must match workplace and effective time. “Separate first, calculate correctly, then aggregate” prevents mixed work, wrong policies and incorrect period settlement.

Author: Do Huy Le — General Director, Nhan Kiet Manpower Supply Co., Ltd.

EWA advice for employers: Hotline 0937.022.655 · Email info@nhankiet.vn · Learn about EWA for employers