Worked example: Wage Backpay in Wisconsin
5 min read
Published April 15, 2026 • By DocketMath Team
Example inputs
This worked example shows how DocketMath can estimate wage backpay totals in Wisconsin (US-WI) using the jurisdiction-aware rule for the general/default statute of limitations (SOL).
Because this is a wage/backpay scenario, the calculator needs a timeline for the “lookback” window. In Wisconsin, this example uses only the general/default period:
- General SOL Period: 6 years
- General Statute: Wis. Stat. § 939.74(1)
Source: https://codes.findlaw.com/wi/crimes-ch-938-to-951/wi-st-939-74/
Note: No wage-backpay-specific sub-rule (i.e., no shorter or specialized limitation period) was identified for this setup. So the example uses the general/default 6-year period from Wis. Stat. § 939.74(1), not a different claim-type limitation.
Scenario used in this example
Assume the employee files on a specific date and wants wages from prior work periods within the SOL window.
Use these inputs:
- Filing date (end date for lookback): 2025-09-15
- Wage rate: $22.50/hour
- Hours not paid (per week): 20 hours
- Total unpaid weekly amount: $22.50 × 20 = $450/week
- Workweeks affected: continuous weekly periods (for simplicity)
If you’re running DocketMath with more detailed facts (different amounts each week, partial weeks, gaps in employment, etc.), your estimate may differ from this simplified model.
DocketMath tool callout (primary CTA)
If you want to run a similar estimate yourself, use the DocketMath calculator here: /tools/wage-backpay.
Example run
Below is the step-by-step calculation flow you’d expect from a wage-backpay estimator when it applies the Wisconsin general 6-year SOL.
Friendly disclaimer: This is a worked example for estimation and understanding how the tool applies the SOL window. It is not legal advice, and it may not capture case-specific legal nuances.
1) Determine the lookback start date using the SOL
- SOL period: 6 years
- Filing date: 2025-09-15
- Lookback start date: approximately 2019-09-15
A practical way to think about this: DocketMath constrains the estimate to the maximum time span permitted by the SOL window.
2) Convert the lookback window into “weeks”
Because this example uses a weekly unpaid amount, we translate the SOL window into an approximate weekly count:
- 6 years ≈ 6 × 52 = 312 weeks
To keep the math transparent, this example uses 312 weeks as the baseline.
(In real inputs, exact calendar-day logic and partial weeks can change the effective count.)
3) Compute unpaid wages within the SOL window
Using the weekly amount:
- Weekly unpaid wages: $450/week
- Weeks in window: 312 weeks
- Estimated wage backpay: $450 × 312 = $140,400
4) Present the outputs as a simple estimate
| Item | Value |
|---|---|
| Wage rate | $22.50/hour |
| Hours unpaid per week | 20 |
| Weekly unpaid amount | $450 |
| SOL window (Wisconsin general) | 6 years |
| Estimated weeks covered | 312 |
| Estimated wage backpay (within SOL) | $140,400 |
What “jurisdiction-aware” means in this example
In this worksheet, the jurisdiction-aware component is the 6-year default lookback, grounded in:
- Wis. Stat. § 939.74(1) (general/default SOL period)
Since no wage-backpay-specific SOL sub-rule was identified for this setup, the estimate uses the general/default period consistently.
Pitfall to avoid: Don’t assume every wage/backpay theory automatically “equals 6 years” in all contexts. This example is intentionally scoped to the general/default Wisconsin period above.
Quick sanity check
If you change only the weekly inputs while keeping the SOL window fixed, the estimate should move proportionally.
For example, if weeks drop from 312 → 260 while $450/week stays the same:
- $450 × 260 = $117,000
That linear scaling is a good diagnostic that the calculator is applying the SOL window as a cap on time, not as a nonlinear adjustment.
Sensitivity check
Small input changes can meaningfully affect the estimate because the SOL window determines how many unpaid work periods are included.
Use the same wage rate ($22.50/hour) and unpaid hours (20/week), then test how results move under realistic variations.
A) Filing date changes the lookback window (capped by SOL)
Keeping weekly wages constant, changing the filing date can alter the effective lookback period—but the SOL rule caps recovery at the maximum window.
Because this example uses a strict 6-year cap, the key expectation is:
- Once you’re within the 6-year cap, results should stabilize around the same maximum time span.
B) Weekly unpaid hours drive proportional changes
Keep the lookback at 6 years / 312 weeks and change hours.
| Unpaid hours/week | Weekly amount | Weeks (cap) | Estimated backpay |
|---|---|---|---|
| 15 | $22.50 × 15 = $337.50 | 312 | $337.50 × 312 = $105,300 |
| 20 | $450.00 | 312 | $140,400 |
| 25 | $562.50 | 312 | $562.50 × 312 = $175,500 |
This highlights proportionality:
- Increasing weekly hours by 25% increases the estimate by 25%, assuming the same SOL window and wage rate.
C) Wage rate increases are not absorbed—everything scales
Hold weeks at 312 and change wage rate.
| Wage rate | Weekly amount (20 hrs) | Weeks | Estimated backpay |
|---|---|---|---|
| $20.00 | $400.00 | 312 | $400.00 × 312 = $124,800 |
| $22.50 | $450.00 | 312 | $140,400 |
| $25.00 | $500.00 | 312 | $500.00 × 312 = $156,000 |
Input checklist for a cleaner DocketMath run
Before you run your own estimate on /tools/wage-backpay, confirm: