The earned wage access process: from time-tracking to receiving money and reconciliation

The earned wage access process begins when working time is recorded and a manager approves it. The system synchronizes the data, computes the eligible portion of already-earned wages, lets the worker submit a request, executes the payout, and then reconciles it into the pay period. Each transaction needs an identifier, a status and a complete log to avoid overpayment, double payment, wrong payroll, or difficulties when work is adjusted.

"Earned wage access" is Nhan Kiet's name for its Earned Wage Access (EWA) solution, which helps a worker access a portion of the wages corresponding to work already performed before the regular payday. This is not a way of paying the entire wage after each working day; the business's calculation and payment cycles are still maintained under the applicable policy (see further distinctions in How does a traditional wage advance differ from EWA?).

Overall diagram of the earned wage access process

The core operating life cycle has seven steps:

1. Record work.

2. Manager confirms work.

3. Synchronize data.

4. Compute the eligible already-earned wages.

5. Worker submits a money request.

6. Authenticate and pay out.

7. Reconcile into the pay period.

If the onboarding stage is included, the full process can be described as follows:

Registration/eKYC → Confirming terms or e-signing → Time-tracking → Work approval → Limit calculation → Money request → Payout → Reconciliation → Pay statement.

These two process layers do not conflict. The seven steps are the operating life cycle that repeats each period; registration and terms confirmation are the preparatory step before the worker makes their first transaction.

Step 0. Registration, authentication and establishing usage rights

Before earned wage access can be used, the worker's profile must be correctly matched to the business's data. At a minimum, the following must be determined:

• A unique employee code.

• The business or unit currently employing them.

• A valid, active employment-relationship status.

• A verified phone number or login account.

• A receiving account belonging to the correct beneficiary or handled under an approved policy.

• The version of the worker terms that has been confirmed.

• The activation time and scope of use.

If there is eKYC or e-signing, the business needs to clearly define which data is collected, the purpose of use, the retention period and how to handle failed authentication. The Law on Electronic Transactions No. 20/2023/QH15 is one of the bases the legal department should review when designing the transaction and electronic confirmation.

Controls needed

• Do not activate a profile that is not correctly matched to an employee code.

• Do not allow a transaction if a resignation or suspension status is already in effect.

• Require additional authentication when the receiving account is changed.

• Store the version of the terms and the evidence of consent.

• Separate identity data from data used only to operate the limit, where appropriate.

Step 1. Recording working time

The first data in earned wage access is not the money request, but working time. The data may come from a timeclock, an app, a client's work sheet, an HRM system or another source recognized by the business.

A work record usually needs these fields:

A single punch only proves the system received data. It does not automatically prove the shift is eligible for wage calculation.

Step 2. Manager confirms work

This is the step that determines the reliability of the limit. An authorized person checks the shift, overtime, leave and exceptions before moving the work to approved status.

Why should only approved work be used?

Unapproved work can change because of:

• A missing clock-in or clock-out.

• The wrong shift or location.

• Overtime not yet confirmed.

• A leave request not yet updated.

• Duplicate data or a wrongly entered employee code.

• The client not yet confirming the actual hours worked.

If the system computes the limit on pending work, money may be paid out before a discrepancy is detected. Recovering it afterward is usually harder than preventing a wrong transaction in the first place.

The work approver's responsibilities

• Approve the right person, the right day, the right shift and the right work type.

• Handle abnormal work within the prescribed deadline.

• Record the reason when adjusting or rejecting.

• Do not share accounts or delegate without control.

• Complete the work before the limit-synchronization cutoff.

The business should have a work-approval SLA and a dashboard showing how many people are unapproved, how many records are abnormal, and the backlog time.

Step 3. Synchronizing and checking data

After work is approved, the data is passed to the limit-calculation system. Synchronization can be by near-real-time API, a scheduled batch file, or a controlled operation during the pilot phase.

The system should not only check "whether there is data" but also check its quality:

• Does the employee code exist and is it still active?

• Is the pay period correct?

• Has the work been approved and not yet locked/withdrawn?

• Is the wage level or unit rate used as the basis already in effect?

• Has any transaction already arisen on the same portion of work?

• Is there a reserve or adjustment to include in the formula?

• Has the receiving account been verified?

The principle when data is missing

Do not guess the unit rate, shift type or work status. If a required data field is missing or contradictory, the profile should move to not eligible status with a specific reason so that HR, the manager or the worker can handle it.

Step 4. Computing the eligible already-earned wages

The limit should not equal the entire provisional wage. The system needs to keep a safety portion for adjustments that may arise at period-end.

Illustrative formula

The general formula can be expressed as follows:

Remaining available limit = (Valid already-earned wages × Safety rate) − Amount already received − Reserve/adjustment

Where:

• Valid already-earned wages: the income computed from approved work under the business's rules.

• Safety rate: the rate the business allows to be accessed, not defaulting to 100%.

• Amount already received: the total of successful transactions in the period.

• Reserve/adjustment: the portion held back for obligations and valid fluctuations that may affect the net wage received.

Illustrative example

Suppose that at the time of calculation:

• Already-earned wages from approved work: VND 4,000,000.

• Assumed safety rate: 70%.

• Amount the worker has already received early: VND 1,500,000.

• Additional reserve: VND 300,000.

Then:

Remaining limit = (4,000,000 × 70%) − 1,500,000 − 300,000 = VND 1,000,000.

All these figures only illustrate how the formula operates; they are not earned wage access policy. The real rate must be based on each business's wage structure, work stability, deductions and ability to handle discrepancies.

Conditions that can make the limit zero

• No approved work yet.

• The profile or receiving account is not yet valid.

• The worker has received the entire eligible portion.

• The work is under dispute or pending adjustment.

• The pay period is locked.

• The employment status is suspended or terminated.

• The total program limit or the funds have temporarily reached their cap.

The screen should explain the reason rather than only showing "cannot transact".

Step 5. The worker submits a money request

When there is a limit, the worker chooses the amount they want to receive. Before confirmation, the system should display:

• The current limit.

• The amount requested.

• The service fee and transfer fee, if any.

• The amount actually received.

• The total amount received in the period.

• The expected remaining wage after the transaction.

• The beneficiary account with information partly masked.

• The expected processing time.

• Important terms and the support channel.

Checks just before recording the request

The limit should be recomputed or reconfirmed to avoid a case where the worker opens the screen at one moment but the work or transaction data has changed before they press confirm.

Each request must have a unique transaction code. If the worker taps several times or the app resends due to a lost connection, the system must still create only one valid transaction.

Step 6. Authentication, control and payout

Before sending the payment instruction, the system needs a final check:

• Valid identity and login session.

• The beneficiary account was not just changed abnormally.

• The limit is still sufficient.

• The worker is still in a usage-eligible status.

• The transaction has never been processed.

• The funds and the total program cap still suffice.

• There is no fraud alert or pause order.

Suggested transaction statuses

A dangerous error is seeing a slow payment status and then automatically resending a new instruction. The correct way is to look up the old transaction by its identifier before deciding how to proceed.

Step 7. Reconciling into the pay period

Reconciliation is the step that proves the system has completed the transaction life cycle. The total amount received early cannot lie outside the payroll worksheet, the pay statement and the accounting books.

The business should perform three layers:

1. Transaction reconciliation

Compare the request in the app with the actual result from the bank or payment channel:

• Transaction code.

• Recipient.

• Amount requested and amount actually received.

• Fee.

• Time.

• Final status.

2. Payroll reconciliation

Compare the total received in the period with each employee's payroll data. The pay statement needs to present clearly the already-earned wages, the amount received early, the fee (if it belongs to a mechanism shown on the statement) and the remaining wage to be paid.

3. Accounting and funds reconciliation

Compare the app's data with statements, accounting entries and the settlement obligations between the business and the operating unit/funding unit. It must be possible to separate the money the worker receives, the service fee, the payment fee and any refunds.

Period-closing principles

• Do not close the period while there are transactions with an undetermined final status.

• Every discrepancy must have a cause, a handler and evidence.

• Adjustments after the period-lock must go through approval.

• The summary report must match the detail for each employee and each transaction.

Minimum input data needed

The principle is to use only data necessary for the defined purpose, assign permissions by the correct role and keep a complete trail. The Personal Data Protection Law No. 91/2025/QH15, in effect from 01/01/2026, is a current basis that should be reviewed for the entire data life cycle.

Roles and responsibilities of each party

The business should draw up a specific RACI for normal and exceptional situations. If an incident occurs and it cannot be determined who has the authority to stop, fix or refund, the process is not yet ready for go-live.

Mandatory controls before paying out

A transaction should only be sent when it passes all the control gates:

1. The employee is still valid and eligible.

2. The work has been approved by an authorized person.

3. Income data is valid in the period.

4. The limit is recomputed at the time of the transaction.

5. The total requested does not exceed the limit and the program cap.

6. The receiving account has been verified.

7. The transaction is not a duplicate.

8. There is no fraud alert or pause status.

9. The funds are still available.

10. The worker has seen the fee and confirmed the amount actually received.

Handling exceptional situations

Work edited after money has been received

The system needs to recompute the eligible portion, stop new transactions if needed and move the discrepancy to an approved handling process. It should not automatically create an obligation outside the process when the worker has not been notified.

The worker resigns mid-period

As soon as the resignation status takes effect, the right to create new transactions must be locked. HR, Payroll and Accounting determine the approved work, the money received, the remaining wage and the settlement plan per the applicable file.

The bank account is wrong or was just changed

A not-yet-paid transaction must be paused; a change of account requires additional authentication. If it has already been paid incorrectly, move immediately to the investigation and incident process; do not manually edit the status to make the report "match".

A failed transaction

Only restore the limit after a reliable final result. The fee policy for failed transactions must be published in advance and updated consistently across the app, reconciliation and accounting.

A transaction suspected of being a duplicate

Look it up by the old transaction code before creating a new instruction. All transaction-creating APIs need an anti-duplicate mechanism.

The time-tracking or payroll system is interrupted

When data is no longer updated within the allowed deadline, the limit needs to be temporarily locked or switched to a manual control mechanism. One should not keep paying out based on old data without approval.

What should the SLA and audit log contain?

Operating SLA

The business needs to agree on deadlines for:

• Work approval.

• Data synchronization.

• Processing money requests.

• Returning transaction results.

• Investigating transactions with an unclear status.

• Fixing work errors and recomputing the limit.

• Handling complaints.

• Refunding money or adjusting fees.

The SLA needs to distinguish the system's processing time from time that depends on the bank, the client or manual approval.

Audit log

The log needs to answer:

• Who or which system performed the action?

• When did the action occur?

• What was the data before and after the change?

• Which rule or formula version was applied?

• Who approved the exception?

• Which payment instruction corresponds to it?

• In which period was the transaction reconciled?

The operator should not be allowed to edit transaction history directly without leaving a trail.

Business checklist before connecting the process

• [ ] There is a consistent employee code across HR, time-tracking, payroll and EWA.

• [ ] Only approved work is used to compute the limit.

• [ ] There is a work-approval deadline and a substitute when the manager is absent.

• [ ] The limit formula has been approved by Payroll, Finance and Legal.

• [ ] There is a reserve portion instead of allowing the full provisional wage to be received.

• [ ] The receiving account is verified and controlled on change.

• [ ] Each transaction has a unique code and an anti-duplicate mechanism.

• [ ] There are complete failed, investigation, refund and reconciliation statuses.

• [ ] A full cycle to pay statement, accounting and statements has been tested.

• [ ] There is a near-real-time process to lock resigned employees.

• [ ] There is a scenario for when time-tracking, payroll or payment is interrupted.

• [ ] The worker clearly sees the fee and the expected remaining wage.

• [ ] There is a support point of contact and a complaint-handling SLA.

• [ ] Personal data is permission-controlled, protected and life-cycle-managed.

• [ ] A pilot has been run and at least one payroll period completed before scaling up.

Conclusion

The core value of earned wage access is not just the speed of the transfer. A reliable system must be able to prove the whole chain:

Right person → right approved work → right limit → right account → exactly once → right status → right pay period → right reconciliation ledger.

If one step cannot be traced, the business cannot yet be sure the transaction was correct. Therefore, a pilot needs to run through at least one complete payroll period, handle exceptions fully and close all material discrepancies before scaling up (see also the risks of deploying EWA).

A business wanting to assess its data and readiness to deploy can register for a demo of the earned wage access process from time-tracking to reconciliation at Earned wage access for businesses.

> Note: This article provides general information and does not replace legal, financial, accounting, security or system-design advice for a specific business.

References

• Labor Code No. 45/2019/QH14

• Law on Electronic Transactions No. 20/2023/QH15

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

• Decree 52/2024/NĐ-CP on non-cash payment

• Banking Review: The legal nature of earned wage access services and proposals for legal adjustment in Vietnam

---

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

Earned wage access consultation for businesses: Hotline 0937.022.655 · Email info@nhankiet.vn · Earned wage access for businesses