Spreadsheet checks before running Wage Backpay in Kansas
6 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Wage Backpay calculator.
Before you run a Wage Backpay calculation in Kansas with DocketMath, make sure your spreadsheet passes a few jurisdiction-aware “sanity checks.” The goal isn’t to predict the outcome—it’s to prevent input mistakes that can shift the backpay window and distort the damages math.
1) Expired or mismatched lookback period (default SOL)
DocketMath’s wage backpay calculator uses a general statute of limitations (SOL) period as the default when no claim-type-specific rule is available. For Kansas, the checker assumes the following default:
- General SOL Period: 0.5 years
- General Statute cited: K.S.A. § 21-6701
Important: The brief does not identify a claim-type-specific sub-rule. So the checker treats 0.5 years as the general/default lookback period. If you later find a claim-type-specific rule that changes the window, you’d want to update your sheet accordingly.
What the checker looks for in your spreadsheet: date logic that accidentally includes/excludes pay periods that fall just outside (or on the edge of) the 0.5-year lookback anchored by your as-of date.
2) Date field inconsistencies (the most common silent failure)
Even if the math is correct, inconsistent date handling can make the spreadsheet select the wrong rows. The checker flags issues like:
- Start date after end date
- Pay period dates that don’t align with your wage/pay schedule
- Missing as-of date (the “measure back from” anchor)
- Timezone/format issues, especially:
- dates stored as text instead of real date values
- mixed formats across columns
Practical effect: two pay rows that look like they’re in range on-screen may be treated as out-of-range by the formula engine if one date column is text and another is a true date.
3) Negative or impossible amounts
Backpay sheets often include adjustments (e.g., credits, offsets, partial payments). Those are valid concepts—but they create sign and arithmetic risks.
The checker looks for patterns such as:
- Wage inputs that generate negative gross or otherwise “impossible” totals
- Hours that are negative or unrealistic for the selected pay period (or exceed your intended bounds)
- Payments entered with the wrong sign (e.g., payments entered as negative numbers when the sheet expects positive)
Pitfall to watch: If your spreadsheet calculates net backpay by subtracting payments from wages, but some payments were entered with the wrong sign, the resulting figure can look plausible while being wrong. The checker helps you catch those inconsistencies early—before you rely on the output.
4) Currency and unit mismatches
Unit errors are easy to miss and can dramatically change results. Common examples the checker catches:
- Mixing annual wage inputs with hourly hours lines without converting
- Treating hours like days (or vice versa) when distributing totals across pay periods
- Row-level calculations that assume one unit while other rows use another
Practical effect: your totals may still “sum neatly,” but the per-period wages included in the backpay window are based on the wrong unit basis.
5) Off-by-one-day cutoff behavior
Lookback windows are time-based, but spreadsheets often implement cutoffs with integer day comparisons. That can cause boundary mistakes.
The checker flags when your sheet:
- applies the lookback cutoff date inconsistently across columns or steps
- includes a row on the boundary day in one calculation path but excludes it in another
Practical effect: a boundary-day pay period can swing totals noticeably, especially if wages are concentrated in a few pay periods.
When to run it
Run the spreadsheet checks at a few key moments so you fix issues while they’re still cheap to correct.
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.
A) Right after you enter or map the inputs
Run checks immediately after you set up:
- wage rate (hourly or converted)
- hours/pay periods
- start date and end date (if your sheet uses both)
- as-of date
- any payment/offset lines or adjustment logic
B) After you change dates (even by one day)
Small changes can move eligible rows in or out of the 0.5-year default window under K.S.A. § 21-6701. So re-run checks after any date edits, including:
- as-of date changes
- pay period date edits
- start/end date edits
- any cutoff or eligibility parameter adjustments
C) Before you export, screenshot, or paste results
Before you share or submit anything, re-run the checker and keep a versioned copy of the spreadsheet. This helps prevent “final numbers” built from an older, unvalidated sheet.
Tie it to DocketMath workflow
To keep logic consistent between your spreadsheet and DocketMath:
- Start from /tools/wage-backpay
- confirm your as-of date and window alignment match what the calculator expects
- use the checker to verify your spreadsheet selects the same eligible rows and applies the same units/sign conventions
Try the checker
You can use DocketMath as your anchor tool and then validate your spreadsheet against it in a jurisdiction-consistent way.
- Primary CTA: /tools/wage-backpay
- Jurisdiction context: **Kansas (US-KS)
Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.
Fast step-by-step test checklist
Dates
Default SOL window alignment
Units
Amounts
What the outputs change when checks pass vs fail
If checks pass: your output is stable because the spreadsheet and DocketMath agree on:
- which rows are eligible (based on the default 0.5-year lookback)
- how totals are computed (units consistent; no sign mistakes)
- boundary behavior (cutoff applied consistently)
If checks fail: you typically see one of these symptoms:
- eligible wage window suddenly shrinks or expands after a date fix
- net backpay flips in direction after correcting payment sign conventions
- totals jump after unit conversion or correcting an annual vs hourly mix-up
Gentle disclaimer: This checker is designed to catch spreadsheet logic and data issues, not to provide legal advice. For any case-specific legal interpretation, consult a qualified professional.