Inputs you need for Wage Backpay in Wisconsin
5 min read
Published April 15, 2026 • By DocketMath Team
Inputs you will need
Run this scenario in DocketMath using the Wage Backpay calculator.
To calculate wage backpay with DocketMath for Wisconsin (US-WI), you’ll want to gather a consistent set of facts that lets the calculator do two jobs:
- Convert the work you performed (“time worked”) into the gross wages you should have received.
- Apply the statute of limitations (SOL) “lookback” window so you only count the portion of the period that falls within Wisconsin’s default coverage.
For Wisconsin, DocketMath uses a jurisdiction-aware default approach: the general/default SOL period is 6 years. Wisconsin’s general SOL for certain criminal offenses is set by Wis. Stat. § 939.74(1) (described as a 6-year period). Based on the material provided, no claim-type-specific sub-rule was found for the specific wage-backpay lookback. So the calculator guidance below uses the general 6-year period as the default SOL window.
Friendly note (not legal advice): SOL rules can be fact-dependent. If your situation involves a different limitations theory or a different trigger/clock, the “default 6-year window” may not match the legal outcome.
Gather the following inputs before you run /tools/wage-backpay:
- Check whether your wage changed (for example, a raise effective on 01/01/2023).
- Include the overtime rate rule you’re using (e.g., your overtime multiplier) so the calculator matches your overtime math.
- If you know the earliest date the dispute covers, include it. If you don’t, the calculator will apply the 6-year default SOL window from the relevant trigger date.
- This is the date used to define the 6-year SOL window in the default setup. Common choices include the filing date or the date the wage issue became actionable—use the option that matches your internal case timeline/workflow.
Pitfall to avoid: If you skip the calculation trigger date, the backpay covered by the 6-year default window can be incorrect even if your hourly wage and hours are perfect. The output totals will still compute—but they may reflect the wrong slice of time.
Quick “coverage” checklist (for the SOL window)
Where to find each input
A practical way to gather these inputs is to pull them from the same records you’d use to support hours and wage rate calculations. Typical sources include:
- Employment start/end dates
- Employment agreement, offer letter, HR onboarding/offboarding email, termination paperwork, or the final pay stub date.
- **Wage rate(s)
- Pay stubs (look for base hourly rate, salary breakdowns, or regular-rate references)
- Written wage change notices (raises, role changes, promotions)
- Payroll history reports that list effective-date changes in rates
- Pay frequency
- Offer letter or onboarding paperwork
- Payroll portal settings
- Pay stubs showing the cadence
- Hours worked
- Timesheets, attendance logs, scheduling system exports, or payroll reports listing hours by pay period
- If you use payroll “hours” lines instead of timesheets, keep the definition consistent (hours actually worked vs. hours paid).
- Overtime treatment
- Company policy documentation on overtime eligibility/calculation
- Your payroll calculations process
- Pay stubs if overtime is broken out clearly (helpful for aligning your overtime inputs with how your pay was computed)
- Offsets / amounts already paid
- Employer checks or paystubs tied to a “make-whole” or remedial payment for the dispute period
- Any settlement payment documentation (if you’re modeling offsets)
- Other earnings records from the same window if you’re netting
Finally, locate your calculation trigger date in your timeline documentation. Common candidates include:
- Filing date (if that’s how your analysis is structured)
- Date you identified the wage shortfall as actionable in your workflow
Run it
Once your inputs are assembled, open DocketMath and navigate to:
- Primary CTA: /tools/wage-backpay
Then enter your information in this order to reduce avoidable mistakes:
- Enter the timeline inputs
- Employment start date
- Employment end date (or “to date”)
- Calculation trigger date
- Enter the wage inputs
- Base hourly/salary rate(s)
- Any changes in rate by effective date
- Overtime inclusion and the overtime rule/multiplier you’re using
- Enter the time inputs
- Hours worked by pay period (if available)
- If you only have totals, use the input structure that best matches what the calculator expects for your dataset
- **Enter offsets (if you’re netting)
- Amounts already paid for the dispute period
- Other earnings during the same window (only if your approach nets them)
What changes when you change an input (practical effect)
Use these quick checks while testing:
- Changing wage rate(s): backpay totals generally change proportionally.
- Changing hours worked: impact is typically linear—more hours usually increases backpay.
- Changing the calculation trigger date: the included SOL-covered window changes first, and totals follow.
- Changing overtime settings: outputs can shift materially because overtime hours often carry a higher multiplier than regular hours.
Default SOL window you’ll be using in this calculator context
In this Wisconsin (US-WI) setup, DocketMath’s default uses a 6-year general period grounded in Wis. Stat. § 939.74(1). The material provided does not identify a claim-type-specific sub-rule for wage backpay, so the calculator approach is general/default rather than claim-specific.
Warning: A default SOL window is not guaranteed to be correct for every wage-backpay theory. If your fact pattern points to a different limitations rule or a different trigger/clock, you may need to adjust your inputs accordingly.
