Spreadsheet checks before running Wage Backpay in Kentucky

What the checker catches

Before you run a Wage Backpay calculation in Kentucky with DocketMath, a spreadsheet “sanity pass” can prevent the most common downstream errors—especially those tied to the statute of limitations. This checker is designed to validate your worksheet assumptions before you commit to the math.

Here’s what DocketMath’s spreadsheet checker (wage-backpay, US-KY) is built to catch:

• Statute-of-limitations cutoffs applied incorrectly

  • Kentucky’s general limitations period is 5 years under KRS 500.020.
  • If your spreadsheet includes pay periods older than the lookback window, you can end up overstating backpay exposure.

• Date-column mix-ups

  • Many wage-backpay worksheets accidentally store and use different “date meanings” in inconsistent ways, such as:

    • “payment date” in one column but treating it like “work date,” or
    • “workweek start” in one row but aggregating using “workweek end.”
  • The checker flags inconsistencies that often show up as unexpected eligibility drops by row.

• Off-by-one logic in period eligibility

  • A frequent error is including or excluding exactly-at-the-boundary dates inconsistently.
  • With a 5-year general period, even a one-day shift can flip a row from “count” to “skip,” changing totals.

• Aggregation errors

  • Duplicate periods, missing rows, accidental filtering, or formula ranges that don’t match your line items can silently alter totals.
  • The checker confirms row coverage and verifies that the final “eligible totals” line up with the sum of eligible periods.

• Unit and rate mismatches

  • Backpay spreadsheets often mix:

    • hourly vs. weekly rates,
    • gross wages vs. net wages, and/or
    • a regular rate vs. other computed components.
  • The checker helps confirm that the hours and rate inputs produce consistent wage figures.

Gentle note: DocketMath’s Wage Backpay tools compute based on the inputs you provide. A statute-of-limitations error won’t “self-correct” later—it compounds. Run the checker first, then rerun the calculator after your worksheet’s eligibility logic looks right.

Kentucky-specific rule used by the checker

This checker uses Kentucky’s general/default limitations period, and no claim-type-specific sub-rule was added because none was identified for this configuration.

• General SOL period: 5 years
• Statute: KRS 500.020

That means your worksheet should assume a 5-year lookback window for eligibility trimming as a default, unless you later confirm a different rule applies to your specific claim type.

When to run it

Timing matters. To keep your workflow efficient, run the checker at these points:

1. After you import or build your spreadsheet but before you calculate backpay

   • This is where the biggest savings happen: catching bad rows early avoids recalculating and re-explaining totals.

2. After you update date ranges

   • If you change the “from” date, “to” date, charge date, or pay period list, rerun immediately.

3. After you adjust rate calculations

   • Example: switching from hourly wages to a blended rate, or updating hours from “reported” to “corrected.”

4. After you revise SOL assumptions

   • If you override the default eligibility logic, rerun the checker to confirm the new window is being applied consistently.

A practical way to think about it: treat the checker like a pre-flight checklist.

Try the checker

You can run this workflow directly in DocketMath’s Wage Backpay tooling:

• Primary CTA: /tools/wage-backpay

To make the checker’s output useful and explainable, prepare your sheet so it can validate row-level eligibility and wage math rather than only a single grand total.

What to provide (typical spreadsheet inputs)

Most wage-backpay sheets boil down to these columns (names can vary):

• **Pay period date(s)

  • e.g., workweek start date or end date
• Hours for each pay period
• Rate (or enough information to derive wages per hour)
• Computed wages (optional—if included, the checker can validate consistency)

How outputs change when eligibility trimming kicks in

Once the checker applies the 5-year general SOL period under KRS 500.020, you should expect:

• Older pay periods to be excluded from eligible totals
• Row-level wage amounts to remain visible but not included in the eligible sum
• A lower grand total than you would get with “all periods included”

A simple interpretation pattern:

• If the checker excludes many rows: revisit your “work date vs. payment date” logic and any boundary date handling.
• If it excludes only a few rows: your worksheet dates and boundary logic are likely aligned, and the SOL trim is behaving consistently.
• If totals don’t reconcile: check for duplicate periods, filters, or formula ranges that may be dropping or double-counting line items.

Mini checklist before you hit calculate

Use this quick pass every time:

Related reading

• Wage & Backpay Calculator Guide for Alabama
• Wage & Backpay Calculator Guide for Arizona
• Wage & Backpay Calculator Guide for Colorado