How does an Earned Wage Engine calculate earned pay?

An Earned Wage Engine is the calculation layer that converts approved workdays into eligible earned pay that can be received during a pay period. It does more than multiply workdays by a daily rate: it must identify the right worker, workplace and period, subtract amounts already received, and apply the employer's reserve rule before returning a result.

What does an Earned Wage Engine actually do?

In an EWA system, the worker interface merely displays the result. The more important work happens on the server: the engine must collect authoritative data and recalculate the amount when the worker views it or submits a request.

The engine's core role is to produce an explainable number. If today's amount differs from yesterday's, the system must be able to trace the change to work records, the pay rate, amounts already received or the reserve rule.

The engine should not trust a number sent directly by a phone or browser. A user's device may be holding stale data. Before creating a transaction, the server must recalculate from current data.

What components make up the basic formula?

For Nhan Kiet's earned wage access service, the calculation principle is:

Available amount = (approved workdays × daily pay rate) − amount already received in the period − reserve required by the employer.

Component	Data source	Role
Approved workdays	Accepted work-record source	Establishes the work already performed
Daily pay rate	Effective payroll record or policy	Converts work into monetary value
Amount received in the period	Confirmed transaction ledger	Prevents the same value from being used again
Reserve	Employer policy	Provides a buffer for end-of-period adjustments
Pay period	Payroll	Limits the scope of additions, deductions and settlement

The engine does not create new data. It calculates only from data confirmed by source systems.

Pending work should not yet enter the calculation. If a transaction has an uncertain status, the engine should not assume it failed and make that amount available again.

Why are approved workdays the starting point?

A timekeeping event and an approved work record are different states.

A QR scan, GPS record, timesheet entry or app record only shows that timekeeping data exists. Before it becomes a financial input, the employer needs a confirmation step under its process.

Cases that require control include:

• a missing clock-in or clock-out time;
• an incorrect shift;
• an overnight shift;
• unconfirmed overtime;
• leave that has not been updated;
• duplicate work records;
• an approved record that was later edited.

Clearly separating recorded data → approved data → data eligible for pay calculation prevents the engine from turning a temporary record into financial value too early.

How does the engine handle changing data?

A reliable payroll system must accept that data can change.

For example:

• an approved work record is edited;
• a pay rate changes from its effective date;
• a worker moves to another workplace;
• a transaction changes from pending to successful after investigation.

The engine therefore needs to associate each calculation with a data version and calculation time.

When a component changes, the result should be recalculated from the latest source instead of directly editing the final number.

The ability to recalculate and explain results is an important part of payroll integrity.

The engine must prevent reuse of the same work value

One important risk is the same value of work being used more than once.

For example, a worker may already have received part of their earned pay during the period, but the system fails to subtract it from the next calculation.

Another case is a workday linked to a successful transaction being added again after data is synchronized.

To limit this risk, the engine must consider together:

• approved workdays;
• the total amount already received;
• pending transactions;
• successful transactions;
• workdays or values already used;
• the relevant payroll period.

The amount received during the period must be deducted from the calculation. Workdays included in transactions need a clear enough trail for payroll to identify at period end which portion was paid early.

How does an Earned Wage Engine differ from an Eligibility Engine?

The two layers answer different questions.

Earned Wage Engine:
“Based on current work data, how much earned pay has been generated?”

Eligibility Engine:
“Under the current circumstances, is this person eligible to use the service, and how much may they receive?”

The Earned Wage Engine focuses on:

• work records;
• pay rates;
• the pay period;
• amounts already received;
• the reserve.

The Eligibility Engine focuses on:

• profile status;
• whether the client has enabled the feature;
• whether the account has been verified;
• policy conditions;
• usage limits;
• other controls.

Separating the two layers allows eligibility policies to change without distorting the history of earned pay.

Why recalculate on the server before a transaction?

Suppose the app displays VND 1,000,000 at 10:00.

By 10:05:

• a workday has been edited;
• another transaction has just succeeded;
• a related policy has changed.

If the app sends VND 1,000,000 back and the server accepts it without checking, the system may create an incorrect payment order.

Therefore, before payment, the server should:

1. retrieve the latest work records;
2. check approval status;
3. retrieve the latest amount already received;
4. retrieve the effective policy;
5. recalculate;
6. validate the requested amount;
7. only then pass the request to the transaction layer.

The interface should only display information and submit requests; it should not determine the final amount.

How should the engine explain its result?

A good result is more than a single number.

The system should be able to explain:

• how many workdays were approved;
• which pay rate applies;
• the total value of approved work;
• the total received during the period;
• the reserve;
• the remaining available amount;
• the period being calculated.

When the amount changes, the audit trail should show which component changed.

This supports:

• worker assistance;
• complaint handling;
• payroll reconciliation;
• error investigation;
• internal audit.

When should the engine return zero or prevent use?

Possible situations include:

• no approved workdays;
• the amount already received has exhausted the eligible value;
• important data is awaiting verification;
• a work record was just edited and has not been approved again;
• the worker is not in the open pay period;
• other program conditions have not been met.

However, when the result is zero, the interface should provide an appropriate reason rather than displaying only “VND 0”.

Technical and operational KPIs to monitor

Employers can monitor:

• the percentage of calculations that are fully explainable;
• how often the available amount changes because work records are edited;
• differences between the engine and payroll;
• duplicate use of work records;
• recalculations required after a transaction;
• exceptions caused by an incorrect period;
• complaints about the available amount;
• exception handling time.

A good engine does more than run quickly; it produces correct, traceable results.

Conclusion

An Earned Wage Engine turns approved work data into an explainable and traceable financial result. It must use the correct source data, subtract amounts already received, apply the reserve, recalculate when data changes, and prevent the same work value from being used more than once. Clearly separating the Earned Wage Engine from the Eligibility Engine and transaction layer makes an EWA system easier to control, reconcile and scale.

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

Earned wage access advice for employers: Hotline 0937.022.655 · Email info@nhankiet.vn · Earned wage access for employers