Earned Wage Access: Real-Time Net Pay Without a Separate Engine

The EWA Problem

Earned Wage Access — also called on-demand pay — lets employees withdraw a portion of already-earned wages before payday. The market is growing fast: DailyPay, Wagestream, Rain, and dozens of regional players serve millions of workers. But almost all of them share the same architectural flaw.

They don’t run payroll. They estimate it.

A typical EWA provider takes gross hours worked (from a time system) and applies a flat withholding estimate — often a single percentage — to approximate the net amount available. This fails in every jurisdiction where payroll is non-linear:

• Progressive tax brackets: An employee earning EUR 4,500/month is in a different marginal bracket than the flat-rate estimate assumes. The EWA overpays or underpays depending on where the estimate lands.
• Social security ceilings: In Germany, once annual earnings exceed the BBG (Beitragsbemessungsgrenze), contributions stop. An EWA advance in November might be calculated with contributions that no longer apply — or worse, an advance in September might ignore that the ceiling hasn’t been reached yet.
• YTD-dependent deductions: UK student loan repayments, Dutch arbeidskorting phase-outs, Belgian bijzondere bijdrage brackets — all depend on cumulative year-to-date earnings that a simplified model doesn’t track.
• Mid-month changes: A salary change on the 15th means the first and second half of the month have different gross values, different tax calculations, and different contribution bases. A flat estimate cannot handle this.
• Retro corrections: If last month’s salary was corrected retroactively, this month’s net changes. An EWA system that doesn’t know about the retro delta will offer the wrong available amount.

The industry workaround is conservative caps: “You can access up to 50% of estimated net earnings.” This safety margin absorbs the estimation error — but it also means the employee never gets access to what they’ve actually earned. The cap exists because the EWA provider cannot calculate the real number.

Architecture: No New Engine Required

Payroll Engine solves EWA without building a separate estimation layer. The same engine that produces the legal monthly payslip also produces the on-demand net calculation. The building blocks already exist:

No new calculation engine. No estimation model. No compliance gap between “what we think the employee earned” and “what the payslip actually says.”

The Forecast Job

The core of EWA is the forecast job. When an employee requests an advance, the system creates a forecast job for the current period. The calculation executes immediately — and from status Draft onward, the results are available.

Job types and status lifecycle

PE knows two job types:

The legal job follows a process-driven status lifecycle:

Draft → Release → Process → Complete

The key properties:

• Calculation happens at the beginning (job creation). Results are available from Draft.
• Status transitions after Draft are process-driven — approval workflows, checks, sign-offs.
• Draft, Release, and Process have no restrictions on count or parallelism.
• Only Complete is restricted: one per cycle. This is the definitive payslip.

For EWA, this means: forecast jobs can be created at any time, in any quantity, without blocking or interfering with the legal payrun. The employee requests an advance at 2 PM on a Tuesday — a forecast job runs in milliseconds, the exact net is known, and the advance can be disbursed.

What the forecast calculates

The forecast job runs the complete payroll calculation for the current period:

• Gross salary (prorated to days worked so far, if configured)
• Income tax via the country’s actual algorithm (PAP in DE, PAS in FR, PAYE in UK, IRPF in ES)
• Social security contributions against actual ceilings and YTD accumulators
• All deductions: pension, benefits, garnishments, prior EWA advances
• Net result: the exact amount the employee would receive if payday were today

This is not an estimate. It’s the same calculation that produces the legal payslip — run at a different point in time.

Tracking Advances

Every EWA disbursement is recorded as a Case in PE’s case model. The case captures the advance as a point-in-time event:

{
  "name": "EwaAdvance",
  "caseType": "Employee",
  "caseFields": [
    {
      "name": "EwaAmount",
      "valueType": "Money",
      "timeType": "Moment"
    },
    {
      "name": "EwaDate",
      "valueType": "Date",
      "timeType": "Moment"
    },
    {
      "name": "EwaReference",
      "valueType": "String",
      "timeType": "Moment"
    }
  ]
}

timeType: Moment is the correct choice here. An EWA advance is a discrete event — it happens once, at a specific point in time. It’s not a recurring value (like salary) and it doesn’t span a period (like employment status). The Moment type stores the event without any period-based time segmentation.

Why not a deduction case?

A common design mistake is modelling EWA as a recurring deduction. This fails because:

• Advances happen irregularly (0, 1, or 5 times per month)
• Each advance has a different amount
• The deduction in the legal payrun is the sum of all advances in the period — not a fixed monthly value
• The tracking must survive retro corrections: if the legal payrun for March is re-run in April, the March advances must still be correctly deducted

By recording each advance as a separate Moment case value, the deduction wage type can query all advances within the current period and sum them dynamically.

Guardrails and Policies

EWA without limits is a liability. The system must enforce policies that prevent over-disbursement while remaining flexible enough for different provider configurations. PE handles this through its existing validation and lookup infrastructure:

All policies are configurable per tenant. A provider serving multiple companies can set different EWA rules per employer — one allows 75% access with no fee, another caps at 40% with a EUR 3 charge. The policies live in lookups and regulation layers, not in application code.

Validation flow

When an advance is requested, the CaseValidateAction executes before the case is persisted:

1. Run a forecast job for the current period (or read the most recent one)
2. Read the net result from the forecast
3. Sum all existing EwaAdvance case values in the current period
4. Check: requested amount + existing advances ≤ net × max percentage
5. Check: net − (existing advances + requested amount) ≥ minimum remaining
6. Check: frequency and cooling period constraints
7. If all checks pass: persist the case. If not: return a validation error with the specific constraint that was violated.

The validation runs server-side, inside the engine. The EWA frontend receives either a success (advance recorded) or a structured error (“Maximum 50% exceeded — available: EUR 312.40”). No business logic in the frontend.

The Legal Payrun Settles

At month-end, the legal payrun processes as usual. A dedicated wage type handles the EWA deduction:

WT 3500  EwaDeduction
         collectors: [NetPay]
         valueActions:
           - sum of all EwaAmount case values in the current period
           - negate (deduction from net)

The wage type queries all EwaAdvance cases with a Moment timestamp within the current payroll period, sums the amounts, and applies them as a net deduction. The result: the employee’s final net pay on the payslip equals the full calculated net minus all advances already received.

The math is exact

Because the forecast used the same engine as the legal payrun, there is no “true-up” problem. The forecast said: “Net this month will be EUR 2,847.” The employee took EUR 1,000 in two advances. The legal payslip shows:

No surprise. No negative net. No reconciliation run. The advances were based on the real calculation, so the final payslip matches exactly.

Retro-safe by design

If a retro correction changes a prior month’s net (salary adjustment discovered after advances were taken), the system handles it naturally. The retro delta flows into the current period’s legal payrun. The EWA deduction is unaffected — it always deducts what was actually disbursed. If the retro reduces the current net below the sum of advances, the result is a reduced payout (or in extreme cases, a net obligation carried forward). The guardrail policies prevent this from happening under normal circumstances by maintaining a minimum remaining buffer.

API Integration

The EWA frontend — whether a mobile app, an employee portal, or a third-party FinTech integration — communicates with PE through the REST API. The integration requires three endpoints:

1. Check available amount

POST /api/tenants/{tenantId}/payrolls/{payrollId}/payruns/{payrunId}/jobs
Content-Type: application/json

{
  "jobType": "Forecast",
  "employees": ["{employeeId}"]
}

Creates a forecast job. The calculation runs immediately. The response includes the job ID. The net result is available from status Draft:

GET /api/tenants/{tenantId}/payruns/{payrunId}/jobs/{jobId}/results
    ?employeeId={employeeId}&wageTypeNumber=9000

Returns the net pay result. The EWA frontend subtracts existing advances (queried separately) to display the available amount.

2. Record an advance

POST /api/tenants/{tenantId}/employees/{employeeId}/cases
Content-Type: application/json

{
  "caseName": "XX.EwaAdvance",
  "values": [
    { "caseFieldName": "XX.EwaAmount", "value": "600.00" },
    { "caseFieldName": "XX.EwaDate", "value": "2026-05-08" },
    { "caseFieldName": "XX.EwaReference", "value": "TXN-2026-0508-001" }
  ]
}

The CaseValidateAction runs server-side. If constraints are violated, the API returns a 422 with the specific policy breach. If accepted, the case is persisted and the EWA provider can disburse the funds.

3. Query advance history

GET /api/tenants/{tenantId}/employees/{employeeId}/cases
    ?caseName=XX.EwaAdvance&periodStart=2026-05-01

Returns all advances in the current period. Used by the frontend to display transaction history and calculate remaining availability.

MCP Server Pro

For AI-driven interfaces, the MCP Server Pro exposes the same operations through natural language. An AI agent can answer “How much can I withdraw today?” by running a forecast, reading the net, and applying the policy rules — all through the same tool protocol used for other payroll queries.

Multi-Country: One Pattern, Every Jurisdiction

The EWA architecture is jurisdiction-agnostic. The pattern — forecast job, case tracking, deduction wage type, validation rules — works identically across all 11 supported countries. What changes per country is the content of the forecast calculation, not the EWA mechanics:

A provider offering EWA in Germany, France, and the UK doesn’t need three different estimation models. One architecture, one API pattern, one case model — and the country regulation handles the calculation differences automatically.

Why This Beats External EWA

The fundamental advantage is architectural: there is no gap between the EWA calculation and the payslip calculation because they are the same calculation. External EWA providers will always have a reconciliation problem because they operate outside the payroll engine. PE-integrated EWA eliminates this category of problems entirely.