Inputs you need for Wage Backpay in Kentucky
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 in Kentucky with DocketMath, you’ll need inputs that map your pay history into a backpay worksheet. This guide uses the Kentucky default lookback window (how far back wages can be recovered) so you can set up the wage-backpay calculator correctly:
- General SOL period: 5 years
- General statute: KRS 500.020
- Scope note (important): No claim-type-specific sub-rule was found that would override the general/default period. That means you should treat KRS 500.020’s general 5-year period as the baseline lookback window for your calculation setup.
Use the checklist below to gather what you’ll plug into DocketMath’s wage-backpay calculator (here’s the primary CTA link: /tools/wage-backpay).
Input checklist (Kentucky)
Pitfall to watch for: If you skip dates (even one missing pay period start date), the “eligible” periods can shift. With a 5-year default lookback under KRS 500.020, that can change which pay periods drive your backpay totals.
Where to find each input
DocketMath works best when your inputs come from consistent, date-specific documents. Here’s where each item typically lives, and what to look for.
Most inputs live in the case file, contracts, or docket entries. Dates usually come from the triggering event notice; rates and caps come from governing documents or statute; and amounts come from the ledger or judgment. Record the source for each value so the run is reproducible.
Pay dates and the lookback window
- Pay period start/end dates: usually listed on pay stubs and/or in the payroll calendar
- Separation date (if used): commonly on the final pay stub, HR separation paperwork, or the employee’s last day record
- Why it matters for Kentucky: DocketMath uses your date anchors to apply the Kentucky default 5-year period tied to KRS 500.020. Since no claim-type-specific override was found, use the general baseline as your lookback setup.
Wages and hours
- Hours worked / time records: timesheets, punch logs, scheduling systems, or manager-approved time summaries
- Hours expected / contracted terms: job offer or employment agreements, documented schedules, or contemporaneous internal records of expected hours
- Pay rate: payroll records, HR/offer paperwork, or written rate-change notices. If your payroll shows different rates over time, input the correct rate mapped to each pay period.
“Expected vs. paid” amounts
- Gross pay actually received: pay stub earnings totals for each pay period (include categories you want to model—regular, overtime, etc.)
- Expected amounts: you (and DocketMath) will generally compute using the rate and hours you provide for each pay period, then compare that expected wage amount to what was paid.
Adjustments / already-paid amounts
- Corrections already made: later payroll runs, lump-sum adjustments, corrected pay stubs, or any written acknowledgement/record of repayment.
Run it
After you collect your pay-period data, you can run DocketMath → wage-backpay.
Enter the inputs in DocketMath and run the Wage Backpay calculation to generate a clean breakdown: Run the calculator.
When rules change, rerun the calculation with updated inputs and store the revision in the matter record.
Step-by-step workflow (practical setup)
Select your calculation range
- Enter the earliest date you want considered and the most recent date you want included.
- This range should align with how you want the 5-year baseline lookback applied under KRS 500.020.
Enter pay rate and hours by pay period
- Add the pay rate that corresponds to each period (especially if rates changed).
- Provide the hours basis you’re using (worked hours vs. expected hours, depending on what your records show).
Input what was actually paid
- Enter paid earnings totals for each pay period, using the same categories you’ll compare in your “expected” calculation.
Enter the “should have been paid” logic
- DocketMath uses the expected terms you provide (for example, rate × hours, plus any components you input) to estimate the shortfall for each period.
Apply the Kentucky lookback window
- Use the general 5-year period as the baseline.
- Because no claim-type-specific sub-rule was found for wage backpay, don’t assume a different lookback applies automatically—stick with KRS 500.020’s general default in your setup.
How outputs change when inputs change
Use these checks to understand why results move:
| Input you change | Likely effect on backpay result |
|---|---|
| You add earlier pay periods within the 5-year baseline | Backpay total may increase because more eligible shortfall periods can be included |
| You widen the date range beyond the 5-year boundary | Totals may not increase proportionally; periods outside the baseline may not drive eligible totals |
| You correct hours worked (e.g., missing overtime hours) | Backpay likely increases for periods where expected wages rise |
| You update pay rate for one period | Shortfall for that period can change, shifting totals even if hours stay the same |
| You subtract amounts already paid | Backpay total should decrease by the credited adjustment amounts |
Gentle note: DocketMath can’t decide what is “disputed” based on your intent. If you believe a category (like overtime) was undercalculated, make sure your hours and rate mapping reflect the calculation method you want to model.
Export and document your calculation trail
After running:
- Save the output summary
- Keep your input assumptions (date anchors, rates, hours basis, and category breakdowns)
- Keep a copy of the underlying documents (pay stubs and time records) so the worksheet matches the math