Worked example: Wage Backpay in Kansas
6 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 to estimate wage backpay using DocketMath for Kansas (US-KS), applying the jurisdiction-aware default statute of limitations (SOL) rule.
Not legal advice. This is an educational example showing how the calculator logic can affect the result. Real cases may involve additional facts, different limitations rules, and other damages concepts not included here.
Scenario (assumed facts for the example)
A former employee alleges they were owed wages for time worked at a Kansas employer. They file a wage claim on a specific date and want to understand what portion of backpay may fall within Kansas’s general/default SOL period.
Use these fixed dates in the example:
- Filing date: 2026-04-15
- Earlier unpaid work date under review: 2025-01-10
- Later unpaid work date under review: 2025-12-20
- Wage rate: $22.50 per hour
- Hours unpaid (from 2025-01-10 through 2025-12-20): 320 total hours
- Pre-judgment interest / penalties: Not included in this run (kept out to focus on the SOL-limited principal wage amount)
Kansas SOL inputs used by DocketMath (default rule)
DocketMath uses a default SOL window when no claim-type-specific SOL sub-rule is found.
- General SOL Period (default): 0.5 years
- Kansas general statute cited: K.S.A. § 21-6701
- Default-period clarity (important): Kansas data indicates no claim-type-specific sub-rule was found, so the calculation uses the general/default period rather than a specialized wage-claim limitations rule.
Statute source used for this example:
What you’re trying to compute
You’ll estimate the SOL-limited portion of backpay by:
- Computing the earliest includable date based on the 0.5-year lookback from the filing date.
- Determining whether each unpaid work date falls before or on/after that earliest includable date.
- Estimating eligible hours and multiplying by the hourly wage to estimate principal backpay.
You do not need to guess legal conclusions for this calculator run—just apply the window and use your best available method to allocate hours into eligible vs. ineligible time.
Calculator entry point (as used in this example)
If you’re using the wage backpay calculator directly, start at:
- /tools/wage-backpay
Example run
This section walks through the exact flow a user would run in DocketMath for US-KS using the wage-backpay calculator and the Kansas general/default SOL rule.
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.
Step 1: Determine the SOL lookback start date
- Filing date: 2026-04-15
- General SOL period: 0.5 years
DocketMath treats 0.5 years as six months for the window calculation.
So the earliest includable date is:
- Earliest includable date = 2025-10-15 (six months before 2026-04-15)
Interpretation for this example:
- Unpaid work before 2025-10-15 is outside the default SOL window.
- Unpaid work on/after 2025-10-15 is potentially includable (for principal wages in this simplified model).
Step 2: Apply the window to the unpaid work range
Unpaid work dates considered:
- Earlier date: 2025-01-10
- Later date: 2025-12-20
The SOL window starts at 2025-10-15, which falls inside the review range. That means the period splits into:
- Ineligible portion: 2025-01-10 through 2025-10-14
- Eligible portion: 2025-10-15 through 2025-12-20
To keep the example concrete, we must estimate how many of the 320 total hours fall into the eligible segment. Because the prompt provides total hours for the full period (but not per-day/per-week totals), assume a proportional allocation by time:
- Total review span: 2025-01-10 → 2025-12-20
- Eligible sub-span: 2025-10-15 → 2025-12-20
The eligible sub-span is approximately 18% of the overall span.
- Eligible hours ≈ 320 × 18% ≈ 58 hours (rounded)
If you have timecards, schedules, or a more granular breakdown, substitute those for proportional estimation. That can materially change the output.
Step 3: Compute SOL-limited wage backpay (principal)
- Hourly wage: $22.50
- Eligible hours (SOL-limited): ~58
Estimated wage backpay:
- $22.50 × 58 = $1,305.00
Step 4: Compare to an “all-hours” baseline (to show SOL impact)
For context only, if you ignored the SOL window and counted all unpaid hours:
- $22.50 × 320 = $7,200.00
So, in this scenario, the SOL-limited estimate reduces principal backpay from:
- $7,200.00 → $1,305.00
Example output summary (conceptual)
| Item | Amount |
|---|---|
| Filing date | 2026-04-15 |
| Default Kansas SOL window | 0.5 years (6 months) |
| Earliest includable date | 2025-10-15 |
| Eligible hours (estimated) | 58 |
| Ineligible hours (estimated) | 262 |
| Hourly wage | $22.50 |
| SOL-limited wage backpay (principal) | $1,305.00 |
| Backpay ignoring SOL | $7,200.00 |
Reminder: This example uses the general/default SOL period under K.S.A. § 21-6701 because no claim-type-specific sub-rule was found in the jurisdiction data for this tool’s approach.
Sensitivity check
A quick way to validate a SOL-limited wage calculation is to test how results move when key inputs change. Below are three high-impact changes to try in DocketMath.
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.
1) Filing date shifts the lookback window
Keep wage ($22.50/hour) and total hours (320) the same, and use the same proportional allocation logic. Move the filing date by roughly ±90 days.
| Filing date | Lookback start (0.5 years) | Expected effect |
|---|---|---|
| 2026-01-15 | 2025-07-15 | Earlier eligible start → higher backpay |
| 2026-04-15 (baseline) | 2025-10-15 | Moderate eligible start → baseline |
| 2026-07-14 | 2026-01-14 | Window likely misses most of 2025 → lower backpay / near-zero |
Why it matters:
- Eligible hours are driven by how much of the unpaid-work period falls on/after the earliest includable date.
2) Unpaid work dates change what’s in (or out) of the window
If unpaid work shifts later, a larger portion may fall inside the SOL window.
Example modification:
- Instead of ending at 2025-12-20, end at 2026-02-15
- Keep 320 total hours the same and allocate proportionally across the longer span
Expected effect:
- More time falls after 2025-10-15 → eligible-hour proportion increases → SOL-limited principal backpay increases.
3) Hourly wage scales results linearly
With eligible hours held constant, the calculator output is essentially a multiplier:
- **Backpay = (eligible hours) × (hourly wage)
Using baseline eligible hours ≈ 58:
- At $20/hour → 58×20 = $1,160
- At $25/hour → 58×25 = $1,450
Why it matters:
- Linear behavior is often a sanity check that the tool is applying wage rate correctly.
