Spreadsheet checks before running Wage Backpay in Wisconsin

What the checker catches

Before you run Wage Backpay in Wisconsin (US-WI) with DocketMath, a spreadsheet-style preflight check can prevent the most common “silent errors” that distort a damages estimate. DocketMath’s wage-backpay calculator is jurisdiction-aware, but your spreadsheet still has to feed it correctly.

This checker focuses on three categories of issues: time coverage, wage coverage, and case math.

1) Statute-of-limitations alignment (Wisconsin default)

Wisconsin uses a general statute of limitations period of 6 years for criminal actions under the general rule in Wis. Stat. § 939.74(1). In this Wisconsin Wage Backpay workflow, the guidance you should follow for your inputs is:

• General/default lookback period: 6 years
• Source: Wis. Stat. § 939.74(1)
  https://codes.findlaw.com/wi/crimes-ch-938-to-951/wi-st-939-74/

Note (important): No claim-type-specific sub-rule was found for this workflow. Treat Wis. Stat. § 939.74(1) as the general/default limitation period in your spreadsheet checks.

What the checker does: it confirms your spreadsheet’s “start date” logic matches that 6-year default window, so you’re not accidentally including periods outside the window (or excluding periods that are inside it).

Spreadsheet checks to include:

• Compute limitation_earliest = as_of_date - 6 years
• Ensure your inclusion rule consistently uses that date for filtering (for example, include a row only if its relevant period overlaps the limitation window, depending on your chosen inclusion rule)

2) Payroll period consistency (date boundaries)

Backpay calculations often fail due to inconsistent period boundaries. The checker should flag:

• Overlapping pay periods (double-counting hours/pay)
• Gaps between pay periods (missing compensation)
• Mismatched date columns (e.g., “period start” vs “period end” swapped in some rows)

Simple enforcement rule: keep dates consistent row-to-row, for example:

• next_period_start = previous_period_end + 1 day (or your system’s standard rule)
• each row has exactly one start date and one end date
• period_end >= period_start for every row

3) Wage base correctness (gross vs net; hourly vs salary)

DocketMath can only calculate from what you provide. Your spreadsheet should standardize:

• Hourly rate vs salaried equivalent
• Gross wages vs net wages
• Regular wages vs differential pay (and whether your spreadsheet includes the same wage components every row)

Common failure mode: one row uses “gross” and another uses “net,” producing totals that may look plausible but are internally inconsistent. The checker should highlight that by enforcing a consistent “wage basis” field (or by validating that rate/wage_amount behaves consistently with hours).

4) Time and pay unit sanity checks

Before you run Wage Backpay, validate core units:

• Hours are numeric and non-negative
• Pay rates are numeric and non-negative
• If using hourly inputs: pay = hours * rate matches your spreadsheet logic (within your rounding rules)

Practical approach: add a “reconciliation” or “variance” column, such as:

• variance = expected_pay - entered_pay

Then flag rows where the mismatch is larger than what your rounding policy allows, for example:

• ABS(variance) > 0.01 * entered_pay (adjust threshold to match your dataset’s rounding)

5) Partial-day and rounding behavior

Watch for rounding drift:

• hours rounded to different increments in different parts of the sheet (e.g., 0.25 vs 0.01)
• pay rounded per pay period in some rows, and recomputed later in others

What the checker enforces: one rounding approach across the dataset. If you compute computed_pay = hours * rate, either:

• compare to entered pay using the same rounding rule, or
• recompute entered pay using the same rule and flag rows that differ.

When to run it

Run the checker in two moments: (1) before you set up inputs and (2) immediately before you click through the calculator.

Run the checker before importing a spreadsheet into the Wage Backpay workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

Step 1: After you import or paste payroll rows

Do this after your spreadsheet has the raw dataset, but before you start adjusting dates or filtering.

Checklist:

Step 2: Immediately before running DocketMath (fresh validation)

Even if Step 1 passed, you may have changed filters or recalculated totals. Re-run the checker right before you calculate.

Validate:

Practical timing tip

If you’re iterating (e.g., trying different date triggers or scenario assumptions), treat each iteration like a new scenario:

• re-run the checker after each change
• keep a simple change log column like Scenario_Date_Trigger so differences are explainable

Gentle note: This is a workflow quality-control step, not legal advice. If your facts or legal theory differ, the correct inputs may also differ.

Try the checker

Start with DocketMath — Wage Backpay here: /tools/wage-backpay. If you want an extra validation pass, keep your checker results “next to” your calculator inputs so you can quickly correct the data the calculator will read.

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Recommended input structure for Wisconsin (US-WI)

Create columns in your spreadsheet like this:

• period_start
• period_end
• hours
• rate (hourly) or wage_amount (if already computed)
• pay_component (optional but helps consistency)
• computed_pay (hours × rate, when using hourly)
• included_flag (based on the 6-year default window)

How outputs change when you fix spreadsheet issues

Use these “symptoms” to interpret changed DocketMath results:

Wisconsin-specific limitation framing in your worksheet

Include a cell for the 6-year default window using the general rule in Wis. Stat. § 939.74(1), treated as the default limitation period for this workflow:

• limitation_earliest = as_of_date - 6 years

Then set:

• included_flag = 1 when period_end >= limitation_earliest (or your chosen inclusion rule)

Because DocketMath’s calculation depends on your included dataset, this worksheet logic is what keeps the calculation anchored to the jurisdiction-aware default.

Finally, after the checker passes, run /tools/wage-backpay.

Related reading

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