Spreadsheet checks before running Wage Backpay in West Virginia

What the checker catches

Before you run Wage Backpay in West Virginia with DocketMath, the biggest avoidable problem is feeding the calculator dates that don’t match the jurisdiction’s statute of limitations (SOL) logic. The DocketMath spreadsheet checker is designed to catch the issues that most often cause “off by a month/year” results—especially when your backpay total depends on how far back you can recover.

For West Virginia, this checker uses the general/default SOL period of 1 year, based on W. Va. Code §61-11-9. No claim-type-specific sub-rule was identified for this checker, so the 1-year general rule is the baseline. (In plain terms: treat the 1-year window as your default starting point, and validate it against your case timeline.)

Here’s what the checker is designed to catch in your spreadsheet before you click Run:

• SOL window mismatch

  • Detects when your “earliest wage date” predates the SOL window implied by your “trigger date” (often the filing date or another timeline anchor you input).
  • Flags cases where the calculated period includes days that fall outside the general 1-year lookback.

• Date field inconsistencies

  • Finds spreadsheets where:

    • “Start date” is after “end date”
    • A date is stored as text (for example, 01/15/2024 typed as a string)
    • Mixed date formats appear (for example, 2024-01-15 alongside 01/15/24)
  • These issues can silently distort the number of days included in backpay.

• Partial periods and truncation errors

  • Catches cases where you slice the calendar incorrectly (for example, excluding the first day of the period or double-counting the last day) because of off-by-one formulas.

• Negative or zero wage components

  • Identifies inputs like:

    • hourly rate = 0
    • negative hours worked (often from sign errors)
    • missing pay frequency assumptions that can cause downstream totals to collapse to zero

• Missing timeline anchoring

  • Ensures you supplied the timeline anchor needed to apply the SOL logic (for example, leaving the trigger/anchor date blank can cause the checker to rely on defaults or fail to apply the window consistently).

When to run it

Run the spreadsheet checks before you run the calculator—and again after any input changes that could shift the SOL window or the length of the paid/unpaid period. Keeping this step early reduces rework, because spreadsheet corrections are easiest while your sheet is still in “draft mode.”

Practical checklist:

• Right before your first Wage Backpay run

  • Confirms date fields parse correctly
  • Confirms the SOL window is applied consistently

• After you update any date

  • Examples:

    • changing the filing date / trigger date
    • adjusting earliest work date
    • correcting when the wage issue began

• After you import or copy/paste rows

  • Spreadsheet transfers frequently convert dates into text or change formatting in ways the formulas don’t expect.

• When hours or pay rate inputs change

  • If wage computations change, rerun checks to ensure the calculator is still using the intended wage period and not a shifted/truncated one.

A simple workflow that usually prevents surprises:

1. Validate your timeline columns (start/end/trigger dates).
2. Run DocketMath spreadsheet checker.
3. Only then run /tools/wage-backpay to compute totals.
4. If totals look unexpectedly low/high, go back to the checker—SOL window problems and date parsing are among the most common causes.

Gentle reminder: this is a spreadsheet quality check, not legal advice. If you’re unsure about what date anchors to use, confirm with the relevant facts and guidance you’re following.

Try the checker

Use DocketMath’s wage backpay workflow at /tools/wage-backpay .

If you’re building or updating the spreadsheet, structure it so the checker has clear, consistent inputs. A typical layout looks like this:

Inputs that commonly shift outputs

• Earliest wage date

  • If you move this date backward by more than 1 year relative to your trigger date, the checker should flag that earlier time likely falls outside the general SOL window. That typically reduces included days—and changes the backpay total.

• Trigger date

  • Shifting the anchor date forward/backward changes where the 1-year window starts and ends. The same earliest wage date can be in-range on one trigger date and out-of-range on another.

• Date formatting

  • A text-formatted date may cause the calculator/checker to treat it as blank/invalid, which can drastically change totals or produce warnings. Converting to true date values usually fixes this.

Quick interpretation guide for typical checker warnings

When the checker flags an issue, expect the computed result to change after you correct it:

• “Out of SOL range” warning

  • Expect backpay totals to decrease after the period is trimmed to the general 1-year lookback.

• “Date parsing” warning

  • Expect totals to change after you convert date columns to true dates (not text) and rerun.

• “Negative hours / rate” warning

  • Expect totals to correct after sign conventions and missing values are fixed.

Related reading

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