Why Wage Backpay results differ in Illinois
4 min read
Published April 15, 2026 • By DocketMath Team
The top 5 reasons results differ
Run this scenario in DocketMath using the Wage Backpay calculator.
If you run the DocketMath Wage Backpay calculator for the same employment facts in Illinois (US-IL) and see different totals, the mismatch is usually explainable. In Illinois, the general/default statute of limitations (SOL) for civil actions is 5 years under 720 ILCS 5/3-6. Also, no wage-claim-type-specific sub-rule was found, so the calculator should treat this 5-year period as the default unless your modeling inputs explicitly incorporate otherwise.
Here are the most common drivers of different results:
Your SOL “lookback” date is computed differently
- DocketMath’s output depends on the date anchors you enter (for example: last pay date, notice date, or filing/claim date—depending on what you’re modeling).
- Even a 30–60 day shift can move the cutoff and change which pay periods are counted, altering the total backpay.
The “regular” rate vs. “claimed” rate changes the math
- Backpay depends on the rate you use per unit of time (hourly rate, salary conversion, bonus/proration assumptions).
- If one run uses an hourly baseline and another uses a different effective rate (or different weekly hours), totals can diverge quickly.
**Work hours assumptions differ (especially overtime and schedule changes)
- Wage backpay often turns on:
- weekly schedule (e.g., 40 vs. 45 hours),
- overtime eligibility,
- part-week periods.
- Swap the “worked hours” inputs, and you may change the compensation baseline—even if the SOL window stays the same.
Payment timing and offset handling differ
- Some inputs reflect amount received, while others rely on netting assumptions (what was already paid during the relevant period).
- If a payment is mapped to different weeks than intended, DocketMath can show a different “unpaid” portion, even with the same overall numbers.
Rounding and prorating across partial weeks/months differ
- Calculators often prorate by day/week for partial coverage periods.
- When your dates don’t align with pay cycles (e.g., termination mid-week), small date differences can create noticeably different totals.
Important Illinois note for diagnostics: Under 720 ILCS 5/3-6, the baseline SOL is 5 years. Since no claim-type-specific sub-rule was identified for this purpose, treat the 5-year default as the starting point and focus on your inputs and anchors as the likely reason results differ.
How to isolate the variable
To pinpoint why two DocketMath runs disagree, use a single-change method: keep everything constant except one input area at a time.
Recommended workflow (fast and practical):
**Run 1 (Baseline)
- Record:
- total backpay output,
- the number of days/weeks included in the SOL window (if displayed),
- any intermediate totals by period (if shown).
**Run 2 (Change only SOL anchor)
- Adjust only the date that drives the 5-year lookback window.
- If the total changes while weekly math stays identical, the SOL window is the culprit.
**Run 3 (Change only rate inputs)
- Keep dates/hours/payments constant.
- If output moves, differences in the effective hourly rate, conversion, or proration logic are likely driving the mismatch.
**Run 4 (Change only hours/schedule)
- Keep rate and dates constant.
- Watch how partial weeks behave; mismatches frequently show up when schedules/overtime assumptions change.
**Run 5 (Change only payment/offset mapping)
- Keep all else constant and alter which pay periods each payment is applied to.
- If totals swing, your payment allocation differs between runs.
Quick checklist (use alongside DocketMath):
If you’re starting from scratch, use the tool here: /tools/wage-backpay.
Next steps
Confirm your date anchors match the Illinois 5-year default
- Illinois general SOL is 5 years under 720 ILCS 5/3-6.
- Make sure the “start” and “end” dates you enter into DocketMath produce the lookback window you intended.
Normalize rate and hours to the same pay-period structure
- If one run uses weekly totals and another uses daily conversion, outputs won’t match even with the same real-world circumstances.
Standardize how payments are treated
- Decide whether you’re modeling:
- what was already paid during each week, or
- a lump sum applied across a different span.
- Then use that same approach in every run.
Keep a difference log
- For every change that produces a different total, write down one sentence like:
- “Changed SOL end date by X days,” or
- “Changed weekly hours from 40 to 45.”
- This prevents “fixing” the wrong input and reintroducing the original mismatch.
Gentle disclaimer: This is meant to help you diagnose calculation differences and check input consistency—not to provide legal advice. For case-specific guidance, consider speaking with a qualified professional.