Why Wage Backpay results differ in Kentucky

5 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 Wage Backpay in Kentucky (US-KY) using DocketMath, you may see different totals across cases that look similar on the surface. That’s usually not a math problem—it’s a jurisdiction-aware input problem plus how DocketMath applies the relevant time window.

In Kentucky, the general/default statute of limitations is 5 years, governed by KRS 500.020. Importantly, no claim-type-specific sub-rule was found in the materials provided, so DocketMath should use the general/default 5-year period (not a shorter or longer category-specific window). If you compare outputs without controlling for that window, differences are expected.

Here are the top 5 reasons results differ:

  1. **Your backpay window is cut off at 5 years (KRS 500.020)

    • DocketMath limits recoverable wages to the lookback period under the general rule.
    • Changing the start date of potential backpay (or the filing/trigger date you’re using) changes which pay periods are included.
  2. Different trigger dates change how many payroll cycles fall inside the window

    • Two people with the same pay rate and hours can get different results if one uses an earlier trigger date.
    • Even a shift of 90 days can add or remove multiple paychecks, especially with biweekly (or other non-monthly) payroll.
  3. Hourly vs. salaried inputs can produce different implied hours

    • If one scenario provides hours per week and another provides a monthly salary, DocketMath may convert/prorate those inputs using different assumptions.
    • The output changes when the computed hours differ—not because Kentucky’s rule changes.
  4. Intermittent earnings (mitigation/offsets) can reduce net backpay

    • If you include earnings during the backpay period, DocketMath can net out those amounts depending on the workflow you choose.
    • So even with the same employer and rate, totals can diverge if there were other jobs or earnings during some portion of the covered time.
  5. Pay components included in “wages” vary based on how you enter the inputs

    • Some setups include overtime, bonuses, or differential pay; others only include base pay.
    • When the input structure changes which components count as backpay, the total changes—even with identical dates.

Pitfall: Don’t compare outputs until you confirm everyone is using the same date anchors (trigger/filing date and the earliest backpay start). In Kentucky, the 5-year SOL window under KRS 500.020 is often the largest driver of “why it’s different.”

How to isolate the variable

To diagnose what’s driving the difference, isolate changes one input at a time. Use this checklist approach:

  • Kentucky default is 5 years under KRS 500.020.
  • Because no claim-type-specific override was identified, both scenarios should use the general/default period.
  • Use the same “start of recovery measurement” date in both runs.
  • If one run uses an earlier trigger date, you’ll likely see more pay periods included within the 5-year window.
  • If one scenario begins earlier, it can add recoverable periods—unless the 5-year window truncates it.
  • Compare the “rate × hours” basis:
    • Same hourly rate?
    • Same hours/week?
    • Same proration method for salary?
  • If one run includes earnings during the period and the other does not, totals will diverge even when dates match.
  • Base-only vs. base + overtime + other pay.

Quick diagnostic table (compare two runs)

Input/AssumptionRun ARun BWhy it changes output
Trigger/filing dateShifts which paychecks fall within 5 years (KRS 500.020)
Earliest backpay startAdds/removes periods after SOL truncation
Pay basisHourly / SalaryHourly / SalaryChanges conversion/proration assumptions
Hours per pay periodChanges computed wages
Offsets/other earningsIncluded / Not includedIncluded / Not includedNet backpay decreases

If you want consistent results, use the same scenario template and change only the single field you suspect. (And remember: this is not legal advice—just a practical way to understand model sensitivity.)

Next steps

  1. Start with a control run
    • Run Kentucky Wage Backpay using DocketMath’s default 5-year SOL approach under KRS 500.020.
  2. Duplicate and change one field
    • Shift the trigger date by one step (e.g., 30 or 60 days) and observe the delta.
    • Then revert and test pay inputs (rate/hours) before touching offsets.
  3. Verify date alignment before interpreting “big differences”
    • Large swings most often mean pay periods were added/removed by the 5-year window.
  4. Use DocketMath as the shared baseline
    • If two versions of the calculation disagree, the fastest path is to reconcile date anchors and pay components, then re-run.

Primary CTA: /tools/wage-backpay

Related reading