How do Settlement and Reconciliation differ in EWA?
Settlement and Reconciliation are related layers with different purposes. In an EWA architecture, Settlement completes and records the financial outcome of a transaction or settlement period; Reconciliation compares independent sources to confirm that work records, bank transactions and payroll all record the same outcome.
First: both involve money but answer different questions
The terms are often used interchangeably because both appear after a transaction is created.
They can, however, be separated clearly:
- Settlement: “How is this financial obligation ultimately completed and recorded?”
- Reconciliation: “Do independent systems record the same outcome?”
If the two are merged, the system may assume that a recorded result is correct even though no independent reconciliation has taken place.
What does Settlement mean in this article?
The term “settlement” can be used differently by banks, payment gateways and payroll systems.
Here, Settlement means the step that establishes the final financial outcome of a transaction or operating period.
For an EWA transaction, for example:
- a request is created;
- the bank confirms the result;
- the system determines what amount was actually paid;
- the transaction ledger records the amount received;
- the remaining pay is updated.
At pay-period level, Settlement also involves:
- aggregating confirmed EWA payments;
- posting the correct total to payroll;
- determining the remaining amount payable in the period;
- closing obligations that have been completed.
Settlement therefore focuses on completing a financial obligation.
What does Reconciliation mean?
Reconciliation is the process of comparing two or more independent data sources to determine whether they match.
For example:
- the EWA ledger records a payment of VND 500,000;
- the bank statement should contain the corresponding transaction;
- end-of-period payroll should reflect the amount already received;
- the payslip should not deduct it twice.
If the sources match, the transaction or period is considered reconciled.
If they do not match, the difference must enter an exception queue.
Reconciliation does not create transactions and should not change figures merely to make reports match.
Settlement and Reconciliation compared
| Criterion | Settlement | Reconciliation |
|---|---|---|
| Main question | How was the financial obligation completed? | Do the ledgers match? |
| Timing | During/after the transaction lifecycle or at period end | After data is available from several sources |
| Main data | Transaction status, amount, period | EWA ledger, bank, payroll |
| Outcome | Amount paid/settled/remaining | Match or exception |
| Creates a transaction? | May be involved in completing a transaction | No |
| Finds differences? | Possibly, but not its primary purpose | Yes, this is its primary purpose |
| Closes a period? | May help close obligations | Confirms data before closure |
| When unclear | Retain an appropriate status | Send to exception/investigation |
The two layers must connect, but cannot replace one another.
How does a transaction pass through Settlement?
A typical flow may be:
- the request meets the conditions;
- Payment Orchestration creates a transaction;
- the bank processes it;
- the final status is determined;
- a successful transaction is posted to the “received” ledger;
- the related value is locked against reuse;
- the transaction obligation is considered complete.
If the bank status is uncertain, Settlement should not reach its own conclusion.
This is where the fail-closed principle applies: if the result is unclear, do not close it as either successful or failed.
How does a transaction pass through Reconciliation?
Once independent data is available, the system compares:
- internal transaction ID;
- bank code or reference;
- amount;
- recipient;
- time;
- status;
- pay period;
- amount posted to payroll.
If everything matches, the transaction can be marked as successfully reconciled.
If one field differs, the system creates an exception.
The key point is that Reconciliation uses an independent source to verify the result recorded by the system.
Why is an API response not enough to count as reconciliation?
A banking API may return “success” during processing.
That is an important signal, but a financial system should still perform an independent reconciliation afterward.
Reasons include:
- a real-time response may be lost or erroneous;
- the internal system may record the wrong status;
- a transaction may be recorded twice;
- a bank statement may contain a transaction missing internally;
- payroll may use the wrong period.
Reconciliation provides the final verification.
How does period-end Settlement differ from transaction Settlement?
There can be two levels.
Transaction level
Determine whether a specific payment was made, for what amount, and record it in the transaction ledger.
Pay-period level
Aggregate all transactions in the period and determine:
- the total already received;
- refunds or adjustments;
- the amount to reflect in payroll;
- the remaining pay.
Both levels require traceable data.
Why not “reconcile by changing the number until it matches”?
A dangerous error occurs when two ledgers differ and an operator manually changes one side so the totals match.
That destroys evidence of the cause.
The correct process is to:
- preserve source data;
- create an exception;
- identify the cause;
- determine which ledger is wrong;
- make a traceable business adjustment;
- obtain approval;
- reconcile again.
Every adjustment needs an audit trail.
Common exceptions between Settlement and Reconciliation
The system records success but the bank statement does not
Investigate the transaction and banking evidence.
The statement shows money paid out but the system says pending
The API response may have been lost. Do not submit a new payment order.
The transaction succeeded but payroll does not reflect it
The amount already received could be paid again at period end.
Payroll deducts the amount but the transaction failed
The worker's pay could be reduced despite not receiving the money.
The transaction belongs to the wrong period
Check the cut-off rule and the relevant pay period.
A duplicate transaction exists
Retain both records, identify the cause and handle it through the proper process.
Who should own these two layers?
They need not be owned by the same team.
Responsibilities can be divided as follows:
- Payment Operations: monitor transaction-level Settlement;
- Accounting/Reconciliation: reconcile with the bank;
- Payroll: period-end Settlement and reconciliation;
- Engineering: ensure status handling, idempotency and logs;
- Product Operations: coordinate exceptions.
Responsibility must be clear whenever a difference arises.
What data connects the two layers?
At minimum, retain:
- transaction ID;
- worker ID;
- receiving account;
- amount;
- time;
- client;
- pay period;
- transaction status;
- bank reference;
- amount posted to payroll.
Reconciliation should not rely primarily on names or free-form transfer descriptions.
When can a period be considered “closed”?
A period should not be closed merely because payroll has run.
Before closure, the employer should know that:
- work records have final statuses;
- successful transactions have been aggregated;
- pending transactions have a handling plan;
- bank and internal ledgers have been reconciled;
- payroll reflects the correct amount;
- remaining exceptions have owners;
- the bridge report has been retained.
Not every exception must disappear immediately, but every open exception must be identified and controlled.
KPIs to track separately for Settlement and Reconciliation
Settlement
- time to determine final status;
- number of pending transactions;
- percentage of transactions needing intervention;
- number of retried transactions;
- number of duplicate transactions.
Reconciliation
- automatic match rate;
- number of exceptions;
- exception age;
- number of bank differences;
- number of payroll differences;
- time to close reconciliation.
If these are combined into one KPI, the employer cannot easily tell whether the problem is transaction processing or ledger comparison.
Conclusion
Settlement and Reconciliation are different links in the same control chain. Settlement completes and records a financial obligation; Reconciliation uses independent sources to prove that the result is consistent. Separating the layers makes pending transactions, differences, cut-offs and payroll easier to manage while preserving traceability from transaction to payslip.
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
FAQ
Is Settlement the same as Reconciliation?
No. Settlement establishes and records the financial outcome; Reconciliation checks whether that outcome matches across sources.
If the API reports success, should the transaction still be reconciled?
Yes. An independent reconciliation should confirm that the internal ledger, bank and payroll match.
Can a pending transaction be settled?
It should not be treated as final when its status is not sufficiently certain.
May Reconciliation change source data automatically?
It should not. Reconciliation identifies differences; corrections should follow a controlled, auditable adjustment process.