Worked example: Wage Backpay in Delaware

7 min read

Published April 15, 2026 • By DocketMath Team

Example inputs

Run this scenario in DocketMath using the Wage Backpay calculator.

This worked example shows how DocketMath calculates wage backpay for a Delaware scenario using jurisdiction-aware rules. It uses Delaware’s general statute of limitations for wage claims.

Delaware rules used in this example

  • General SOL period: 2 years
  • General statute: 11 Del. C. § 205(b)(3) (default/generally applicable period)
    Source: https://delcode.delaware.gov/title11/c002/index.html?utm_source=openai
  • Important limitation (clear default): No claim-type-specific sub-rule was found for this calculator scenario. So this example uses the general/default 2-year period rather than a different category-based limitations period. That means your actual filing deadline could differ if your claim fits a more specific limitations rule not covered by this worked example.

Scenario

Assume an employee was not paid wages owed for work performed in the months leading up to a termination/notice event, and the employee files a wage-related claim on a specific date.

We’ll focus on:

  1. Filing date (sets the start of the lookback window using the SOL)
  2. Pay schedule and wage rate
  3. Unpaid work periods (what dates fall inside the SOL lookback)

Inputs for DocketMath (wage-backpay)

Open and run the example here: /tools/wage-backpay

Use the following values:

  • Jurisdiction: Delaware (US-DE)
  • Claim filing date: 2026-04-15
  • Hourly wage: $28.50
  • Work missed that was unpaid:
    • 2025-05-01 to 2025-06-15 (inclusive)
    • 2026-01-01 to 2026-02-15 (inclusive)
  • Hours per workday: 8
  • Workdays per week: 5
  • Exclude weekends: Yes
  • Holiday/exception days: None provided (this example treats weekdays as the work schedule)

If your facts include paid time off, varying schedules, or partial payments, you can adjust those inputs in DocketMath to estimate net backpay rather than gross. (This worked example focuses on the inputs above and does not account for every real-world payroll nuance.)

How the SOL window affects which wages count

Delaware’s general SOL used here is 2 years under 11 Del. C. § 205(b)(3). In practice, that means—baseline rule for this example—wages that accrued more than 2 years before the filing date are outside the lookback window and should not be included in the calculator’s recoverable total.

With a filing date of 2026-04-15, the lookback start date for the general SOL period is:

  • 2024-04-15 (earliest potentially recoverable accrual window in the calculator logic)

So, in this worked example, DocketMath should include unpaid wage accruals on/after 2024-04-15, and exclude accruals before that date.

Example run

Below is the walkthrough of the calculation mechanics in DocketMath, step by step.

Run the Wage Backpay calculator using the example inputs above. Review the breakdown for intermediate steps (segments, adjustments, or rate changes) so you can see how each input moves the output. Save the result for reference and compare it to your actual scenario.

1) Determine the SOL lookback window (Delaware general SOL)

  • Filing date: 2026-04-15
  • General SOL: 2 years (11 Del. C. § 205(b)(3))
  • Lookback window start: 2024-04-15

So, DocketMath includes unpaid wage accruals that fall on/after 2024-04-15 and excludes accruals that fall before 2024-04-15, using the general/default period.

Note: This example uses the general 2-year limit because no claim-type-specific sub-rule was identified for this calculator scenario. If your wage claim has a special limitations rule, the recoverable lookback window could change. This is a planning illustration, not legal advice.

2) Break unpaid periods into included vs. excluded dates

You provided two unpaid ranges:

  1. 2025-05-01 to 2025-06-15

    • Entirely after 2024-04-15 → included
  2. 2026-01-01 to 2026-02-15

    • Entirely after 2024-04-15 → included

Because both unpaid work ranges are within the 2-year SOL window, the SOL filter does not reduce the totals in this particular example.

3) Convert included dates into billable workdays and hours

DocketMath computes totals based on:

  • weekdays-only operation (5 days/week)
  • 8 hours/day
  • no holiday exclusions (none were provided)

Conceptually:

  • Count weekdays in each unpaid range (Mon–Fri, given the “exclude weekends: Yes” setting)
  • Multiply by 8 hours/day
  • Multiply total hours by $28.50/hour

For this worked example, the calculator logic yields:

Period A: 2025-05-01 through 2025-06-15

  • ~33 weekdays
  • 264 hours (33 × 8)

Period B: 2026-01-01 through 2026-02-15

  • ~31 weekdays
  • 248 hours (31 × 8)

(Your exact count could differ if you add holidays/exception days or if your actual work schedule differs from the default weekday/weekdays-only approach described by the inputs.)

4) Compute gross backpay by hours × hourly wage

  • Hourly wage: $28.50

Gross wages for Period A

  • 264 hours × $28.50 = $7,524.00

Gross wages for Period B

  • 248 hours × $28.50 = $7,068.00

5) Total wage backpay (before other adjustments)

  • Total = $7,524.00 + $7,068.00 = $14,592.00

This is the calculator’s gross wage-backpay total based on the inputs above and the Delaware general SOL lookback window.

6) What DocketMath outputs (typical fields)

When you run the scenario in DocketMath (wage-backpay), you should expect output that includes:

  • SOL lookback window start date (based on 11 Del. C. § 205(b)(3))
  • total included workdays/hours (after the SOL filter)
  • calculated gross backpay (included hours × rate)
  • optionally, a breakdown by unpaid period (Period A vs. Period B)

You can reproduce this run directly here: /tools/wage-backpay

Sensitivity check

A wage-backpay estimate is sensitive to the lookback window and the underlying schedule assumptions. Below are practical tests (and what they typically do to results).

To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.

Sensitivity #1: Filing date changes the SOL lookback window

Because DocketMath uses the 2-year window under 11 Del. C. § 205(b)(3) (general/default in this example), moving the filing date shifts the cut-off date and can quickly exclude older unpaid hours.

Try mirroring these adjustments in DocketMath:

  • If filing date changes to 2027-04-15

    • Lookback start becomes 2025-04-15
    • Both provided unpaid periods (starting 2025-05-01 and 2026-01-01) remain included
    • Expected change: little to none for this dataset
  • If filing date changes to 2025-03-15

    • Lookback start becomes 2023-03-15
    • Both unpaid periods still remain included
    • Expected change: still no SOL cut here
  • If you add an unpaid period before 2024-04-15 (keeping filing date 2026-04-15)

    • Example: 2024-03-01 to 2024-03-31
    • Those dates fall outside the 2-year window
    • Expected change: DocketMath excludes those earlier hours, lowering backpay

Key takeaway: in this specific example, SOL doesn’t trim anything because all unpaid ranges are comfortably within 2 years. If you add older unpaid work, the totals can change materially.

Sensitivity #2: Hourly wage changes affect results linearly

Backpay is essentially:

  • included hours × hourly wage

So if you adjust hourly wage, totals scale proportionally:

  • Increase from $28.50 to $30.00
    • Included hours remain 512 (264 + 248)
    • New total: 512 × $30.00 = $15,360.00
    • Increase: $768.00

Sensitivity #3: Daily hours and workdays/week shift included hours

If the actual schedule differs from the inputs (e.g., 6 hours/day instead of 8), the included hours change.

Example:

  • Switch from 8 hours/day to 7.5 hours/day
    • Included hours become 512 × (7.5/8) = 480 hours
    • Total: 480 × $28.50 = $13,680.00

Sensitivity #4: Weekdays vs. weekends / holidays

DocketMath depends on how you define “workdays.” If you accidentally include weekends as worked (or forget to mark holidays/exception days), totals can inflate.

  • Pitfall: assuming every calendar day is a workday (instead of excluding weekends)
  • Why it matters: it can overstate included hours
  • Mitigation: use Exclude weekends: Yes and add holidays/exception days if your schedule requires it

Related reading