EWA for staffing and labor-leasing businesses: how do you manage attendance across many clients?

To deploy EWA in a staffing or labor-leasing business, each worker must be accurately linked to the employing legal entity, the client, the site, the contract/assignment, the pay period and the approved attendance data. The business must clearly determine which client records attendance, who has the right to approve, when attendance becomes eligible to create a limit, and which party handles disbursement, payroll and reconciliation. When a worker is transferred or ends an assignment, their EWA rights must change according to the effective date, not wait until the end of the month.

> Note: "Labor supply," "HR services," "outsourcing" and "labor leasing" are not automatically the same legal relationship. The scope of responsibility, the employing party and the pay mechanism must be determined by the contract and the applicable law. This article is a general operational–technical framework and does not replace legal advice for each specific model.

> Glossary: EWA (access to wages already earned from days worked) · payroll · assignment (a task/posting at a client) · SLA (service level agreement) · HRIS (human resource information system) · ERP (enterprise resource planning) · cutoff (the period-closing point) · pilot (a trial deployment) · UAT (user acceptance testing) · KPI (key performance indicator).

Why is the multi-client model more complex than a single factory?

In a typical manufacturing business, the worker, the timekeeping machine, the manager who approves attendance and payroll usually all belong to the same organizational system. In a staffing or labor-leasing business, a worker may:

• sign an employment relationship with one legal entity but work at a client's site;

• be scheduled and have their presence confirmed by the client;

• have their attendance aggregated, wages calculated and paid by the staffing business;

• transfer between clients or sites within the same period;

• have many allowances, overtime rules or different confirmation rules;

• end an assignment at a client but not terminate the employment relationship;

• or end both the assignment and the employment relationship at two different points in time.

EWA only calculates correctly when the system understands this entire context. The correct employee ID linked to the wrong client, the wrong assignment or the wrong period can still create an incorrect limit.

1. Clearly separate the operational models before integrating

Staffing/HR recruitment

A service business may introduce or supply a pool of candidates for the client to directly engage and manage the employment relationship. In this case, the party responsible for wages and EWA may not be the unit supplying the candidates.

Labor leasing

This is a conditional activity regulated by labor law. You must correctly identify the labor-leasing business, the hirer, the leased worker, the scope of work, the contract and each party's responsibilities.

Outsourced services that use labor

The client buys a result or a service; the provider organizes the delivery. How the work is managed, attendance is recorded and wages are paid depends on the service contract and the actual employment relationship.

Why does classification matter for EWA?

It determines:

• who the employer is;

• who determines and pays the wages;

• who holds reliable attendance data;

• who has the right to approve;

• who provides the source of funds;

• with whom transactions are settled;

• who is the data controller or processor according to their actual role;

• who resolves complaints and disputes.

You should not use a single EWA process for every contract just because they all involve workers working at a client.

2. Multi-party data architecture

(Data and integration requirements: see Integrating EWA with timekeeping, payroll and ERP.)

flowchart TD
    A["HRIS of the staffing business"] --> E["Standard data layer"]
    B["Shift schedules and attendance at the client"] --> E
    C["Supervisor confirmation"] --> E
    D["Payroll and contracts"] --> E
    E --> F["EWA limit engine"]
    F --> G["Disbursement"]
    G --> H["Reconciliation with payroll, ERP and the client"]

The single-source-of-truth principle for each domain

3. The "person – assignment – client – pay period" data model

employee_id alone is not enough. One person can have multiple assignments within the same period.

The important keys

• employee_id: the worker's ID;

• employerid or legalentity_id: the legal entity that engages the employment relationship;

• client_id: the client;

• site_id: the work site;

• assignment_id: the specific task/posting;

• contract_id: the service contract or a necessary reference;

• payroll_group: the pay rules/period group;

• payperiodid: the pay period;

• effectivefrom, effectiveto: the effective dates;

• transaction_id: the EWA transaction;

• payment_reference: the payment reference.

Why does `assignment_id` matter?

If an employee works 10 days at Client A and 12 days at Client B, the system must know which assignment each attendance record belongs to, who approved it and which rules apply. You should not keep only the current client on the employee record and then overwrite history.

Sample assignment data

{
  "employee_id": "EMP-000123",
  "employer_id": "NK-DEMO",
  "client_id": "CLIENT-DEMO-B",
  "site_id": "SITE-B02",
  "assignment_id": "ASN-2026-00871",
  "payroll_group": "MONTHLY-B",
  "effective_from": "2026-08-12",
  "effective_to": null,
  "status": "ACTIVE",
  "record_version": 3
}

This is fictional illustrative data, not an official earned wage access API structure.

4. Who records attendance and who approves it?

(Underlying concept: see What is approved attendance?.)

Three roles may be different:

1. The recorder: the timekeeping machine, the app, the attendance sheet or the on-site supervisor.

2. The confirmer of presence/work: the team leader or the client's manager.

3. The approver for payroll: an authorized person at the staffing business, per the process.

Four common approval models

EWA must use exactly the status that policy has approved. "The client has viewed it" is not automatically equal to "the attendance is approved for payroll."

5. The attendance-approval SLA must be designed together with the client

If the client confirms attendance late, the worker will not see a limit even though the platform is working normally. That is why the attendance-approval SLA must be part of the coordination process, not just an internal HR matter.

Recommended KPI

On-time attendance-approval rate (%) = Records approved before the cutoff ÷ Total records to be approved × 100%

Track by:

• client;

• site;

• shift;

• approver;

• exception type;

• the age of unapproved attendance;

• the reason for delay.

You should not report only a single system-wide rate. One slow client can be masked by many clients that are approving well.

Reminder and escalation mechanism

• reminders before and after the cutoff;

• a list of exceptions to handle;

• delegation of a substitute when the approver is away;

• escalation based on record age;

• an alert when a work site has no data;

• reporting to the client and business focal points;

• recording the reason when approval is late.

6. What fields does client-side attendance need?

If the client sends a file, add batch_id, the number of records, a checksum, the creation time and the file version.

7. Transfers between clients within the same period

This is a situation that easily creates duplicate or missing attendance.

The process you should have

1. end the old assignment with an effective date/time;

2. open the new assignment;

3. check that there is no overlap that violates the rules;

4. confirm any attendance still pending at the old client;

5. determine the new payroll group and EWA policy;

6. recalculate the limit if the rules change;

7. notify the worker if the limit is affected;

8. assign management/approval rights for the new site;

9. reconcile transactions already made against the correct pay period.

Do not overwrite the old client

The record needs a history of assignmentid. If you only change the current clientid, past reports may attribute all attendance and transactions to the new client.

8. Ending an assignment differs from resignation

A person may end at Client A but wait to transfer to Client B; or resign entirely.

The business needs at least two independent statuses:

• the employment-relationship status;

• the assignment/task status.

A reference handling matrix

The official rules must be approved by HR, Payroll and Legal. You should not automatically lock or open based solely on a single client file.

9. Multiple pay periods and policies across many clients

The staffing business may pay wages on the same period, but client data is closed on different days. Some clients have allowances, overtime, attendance bonuses or their own rounding rules.

A configuration table that needs version control

You should not hard-code policy by client name in the source code. Configuration needs effective dates, an approver and a change history.

10. Overtime and variable earnings

Overtime at a client may go through several steps: registration, execution, client confirmation, business approval and payroll lock.

Items such as shift allowances, attendance bonuses, output or bonuses may only be determined at the end of the period. The business must classify:

• the part that is certain and approved;

• the part that is provisionally calculated but likely to be adjusted;

• the part that is only determined at the end of the period;

• the part not included in EWA.

If a variable item is counted toward the limit, you need a reserve mechanism, versioning and an explanation for the worker. You should not use projected revenue from the client as a direct basis for each individual's wage rights.

11. Responsibility when a client edits attendance late

Attendance may be edited after EWA has already created a transaction. The process must answer:

1. within what time window may the client make edits;

2. who approves the change;

3. is the before/after value stored;

4. which transactions used the old version;

5. how the current limit is recalculated;

6. in which period the difference is handled;

7. who contacts the worker;

8. how the client and business reconcile;

9. how recurring errors are remediated.

You should not delete the old record. You need an adjustment event or a version so you can reconstruct the limit at the time of the transaction.

12. Source of funds and cash flow in the multi-party model

Before deployment you must determine:

• which party transfers money to the worker;

• who owns the source account;

• when a transaction is considered an obligation between the parties;

• when the staffing business and the client settle;

• which party bears the fees;

• how failed, unclear or refunded transactions are handled;

• when the client pays late, what happens to the worker's benefits and the parties' obligations;

• under which contract receivables and accounting entries are reflected.

EWA should not be designed on the assumption that the client will certainly pay on the exact date if the contract and the actual cash flow do not guarantee it. The Finance department needs to build cash-flow scenarios and program limits.

13. Five-way reconciliation

(Reconciliation details: see Reconciling EWA transactions with payroll and accounting.)

In the multi-client model, reconciliation may need five dimensions:

1. attendance that has been confirmed/approved;

2. the limit and EWA transactions;

3. the disbursement result;

4. payroll/ERP;

5. confirmation/settlement records with the client where relevant.

flowchart TD
    A["Client attendance"] --> F["Reconciliation"]
    B["EWA transaction"] --> F
    C["Disbursement result"] --> F
    D["Payroll and ERP"] --> F
    E["Client records"] --> F
    F --> G["Match or discrepancy case"]

Common discrepancies

• the client confirms but the business has not yet approved;

• attendance under the wrong assignment_id;

• a person who has transferred still has attendance at the old site;

• EWA succeeds but payroll is missing it;

• payment succeeds but EWA has not received the callback;

• a transaction posted to the wrong legal entity or period;

• the client edits attendance after the cutoff;

• the total by client matches but is wrong by employee;

• a fee or settlement item attached to the wrong contract.

14. Grant client access without exposing unnecessary data

(Security framework: see Data security and privacy when deploying EWA.)

Client-side users should only see the workers and data within the scope they need to confirm. You should not by default let the client view:

• the full history of early-wage access;

• individual transaction amounts;

• data at other clients;

• full bank account information;

• payroll records outside their scope of responsibility;

• detailed fraud alerts;

• HR data not needed for timekeeping.

Access controls

• grant access by clientid, siteid and role;

• rights that have an expiry date;

• review when a contract or focal point changes;

• MFA for approvers;

• do not use shared accounts;

• log the viewing, editing, approval and export of data;

• separate approval when downloading data in bulk;

• notify and revoke immediately when a client user leaves or changes jobs.

15. Three-party support channels

A worker should not have to guess whether a problem belongs to the client, the staffing business or the EWA provider.

Routing by issue type

A ticket needs a single code throughout and a status the worker can track. You should not require them to start over with each party.

16. KPIs for a labor-supply business

Leading KPIs

• the rate of workers with a valid assignment;

• the rate of client attendance sent on time;

• the on-time attendance-approval rate;

• the mean/median age of attendance awaiting approval;

• the rate of assignment changes updated on time;

• the freshness of limit data.

Experience and operational KPIs

• the activation rate by client;

• the transaction success rate;

• the time to receive money;

• tickets per 1,000 transactions;

• the automatic-processing rate;

• the automatic-reconciliation rate;

• discrepancies by client/cause;

• attendance adjustments after the cutoff.

HR and commercial KPIs

• the job-acceptance and early-presence rates;

• turnover by cohort;

• the workforce-fulfillment rate;

• manual advance requests;

• awareness and satisfaction levels;

• operational workload per client.

You should not conclude that EWA caused a personnel change from a before/after comparison alone. You need to consider seasonality, orders, pay level, management, site and other policies.

17. Which client should the pilot choose?

(A standard roadmap: see A 90-day EWA pilot plan for businesses.)

A suitable pilot client usually has:

• a clear need and consensus;

• an authorized focal point;

• relatively stable attendance data;

• representative shift and overtime processes;

• enough people/transactions for testing;

• a readiness to approve attendance on time;

• coordination on communication and support;

• no simultaneous replacement of a major timekeeping system.

You should not choose a client just because of a favorable relationship if their process is too different from the rest.

The scope the pilot must cover

• one round of onboarding/activation;

• regular shifts, overtime and exceptional attendance;

• an assignment transfer or ending;

• successful, failed, unclear and refunded transactions;

• daily reconciliation;

• one complete payroll cycle;

• client confirmation/settlement if within scope;

• complaints and incidents.

18. A multi-client UAT checklist

Worker and assignment

• [ ] One person with one active assignment.

• [ ] One person with two valid assignments in the period.

• [ ] A transfer between clients.

• [ ] Ending an assignment but not resigning.

• [ ] Resignation but the client file still has attendance.

• [ ] Wrong legal entity or client code.

Attendance and approval

• [ ] The client sends attendance on time.

• [ ] Attendance awaiting confirmation and approved attendance.

• [ ] Rejected attendance.

• [ ] Attendance edited after approval.

• [ ] Duplicate, missing or out-of-order files.

• [ ] The approver is away and a substitute is delegated.

Limit and transactions

• [ ] Only eligible data creates a limit.

• [ ] Assignment changes apply on the correct date.

• [ ] Resubmitting with the same key does not create a duplicate transaction.

• [ ] A timeout creates an unclear status.

• [ ] A refunded transaction is handled correctly.

Payroll and reconciliation

• [ ] Transactions post to the correct person, legal entity, client and period.

• [ ] Payroll blocks duplicate transactions.

• [ ] Reconcile each transaction, not just totals.

• [ ] Discrepancies create a case with an owner.

• [ ] Adjustments have before/after values and approval.

Permissions and security

• [ ] Client users only see their own scope.

• [ ] The client cannot view unnecessary individual EWA history.

• [ ] Rights expire and are revoked correctly.

• [ ] Data exports are logged.

• [ ] File-leak or account-takeover scenarios are rehearsed.

19. The legal framework to keep in mind

Labor Code No. 45/2019/QH14 took effect on 1 January 2021. Decree 145/2020/ND-CP took effect on 1 February 2021, detailing and guiding a number of articles of the Labor Code on working conditions and labor relations, including content related to labor leasing.

The business must correctly determine the legal model, the operating conditions, the rights and obligations of the parties, the responsibility for paying wages and the applicable records. You should not use the term "labor supply" to substitute for classifying the actual relationship.

On data, the Personal Data Protection Law No. 91/2025/QH15 and Decree 356/2025/ND-CP took effect on 1 January 2026. Data sharing among the staffing business, the client, the EWA provider and the payment partner needs to be reviewed by role, purpose, scope and actual protective measures.

Specific legal conclusions about the product, advances, settlement and deductions must be based on the contract, the rules and the actual money flow, not inferred solely from the name EWA.

Conclusion

EWA has great potential in staffing and labor-leasing businesses because it addresses the needs of a dispersed workforce and helps digitize advances. But the level of complexity is also higher: attendance data originates at the client, payroll belongs to the staffing business, transactions go through the EWA provider, and disbursement must be linked consistently.

The condition for success is managing the person – assignment – client – pay period model correctly, approving attendance on time, separating the end of an assignment from resignation, granting minimal access and reconciling down to each transaction. Explore Earned Wage Access for businesses to discuss the earned wage access model for a workforce serving multiple clients and sites.

References

• Labor Code No. 45/2019/QH14

• Decree 145/2020/ND-CP guiding the Labor Code

• Personal Data Protection Law No. 91/2025/QH15

• Decree 356/2025/ND-CP guiding the Personal Data Protection Law

---

Author: Nguyen Minh Khang — Strategy Division Specialist, Nhan Kiet Manpower Supply Co., Ltd.

Consultation on the earned wage access solution for businesses: Hotline 0937.022.655 · Email info@nhankiet.vn · Earned Wage Access for businesses