Spreadsheet checks before running Wage Backpay in South Dakota
6 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Wage Backpay calculator.
Running a wage backpay calculation in South Dakota goes smoother when you confirm your spreadsheet aligns with the case timing rules first. DocketMath’s Wage Backpay workflow can be paired with a spreadsheet pre-checker that focuses on “silent failures”—problems that may not throw errors, but can still skew totals.
Below are the key spreadsheet patterns the checker is designed to catch for South Dakota (US-SD), using the general statute of limitations (SOL) period of 3 years under SDCL 22-14-1.
Important clarity on SOL: No claim-type-specific sub-rule was found. The checker therefore treats this as the general/default period (3 years) rather than applying a special shortened or extended clock for particular claim types. The goal is consistency across the worksheet.
1) Service date vs. claim start date misalignment
A common cause of incorrect backpay totals is mixing:
- the work period start/end dates, and
- the date the claim is measured from (often tied to filing or another triggering date, depending on your workflow).
Checker output impact: it flags date-window logic that includes workdays across the SOL lookback boundary too broadly. That typically results in backpay being calculated for days that should fall outside the 3-year general SOL.
2) SOL lookback boundary not represented in the spreadsheet
Even when you know the SOL, spreadsheets often fail to implement it clearly. The checker looks for whether you’ve created (or can derive) a cutoff date that represents “3 years back from the relevant measurement date.”
- General rule used by the checker: 3 years
- Legal citation: SDCL 22-14-1
- No claim-type-specific sub-rule found: the checker uses the general/default 3-year period as the standard for the sheet (not a different clock).
Practical example of what this looks like: if your sheet filters rows by date, but the cutoff is missing, hard-coded incorrectly, or computed from the wrong “measurement date” field, the checker will detect that the worksheet cannot reliably apply the SOL window.
Gentle reminder: this is a tooling check for spreadsheet logic, not legal advice.
3) Off-by-one errors around partial days
If your spreadsheet counts wages using day-level granularity, inclusive vs. exclusive boundaries can shift totals.
The checker reviews whether your logic uses things like:
>=vs.>- whether the cutoff date is treated as included in time windows
- whether your prorating behaves correctly when a pay period straddles the cutoff boundary
Checker output impact: it can identify consistent “one day” (or fraction-of-day) behavior where totals are always slightly high or low relative to the intended SOL filter. The result can look plausible but be systematically wrong.
4) Pay frequency mismatches (weekly vs. biweekly vs. monthly)
Backpay sheets often include:
- an hourly wage rate,
- hours worked per period, and
- a pay-period identifier or multiplier.
If the pay frequency implied by your formulas doesn’t match how your hours are stored, the checker flags aggregation inconsistencies—such as applying a “weeks in range” multiplier to values that are already recorded weekly.
Checker output impact: totals can still appear reasonable, but they drift by roughly one pay-cycle’s worth of hours. The checker helps you catch that mismatch early.
5) Duplicate or overlapping time blocks
Another silent failure is double-counting: two rows cover the same calendar days (commonly from copying templates or manually splitting ranges).
The checker looks for:
- overlapping date ranges per employee (or per line item, depending on your sheet structure)
- ranges that overlap by even 1 day
Checker output impact: double-counted wages, often discovered later when someone compares to payroll records or expected totals.
6) Missing or blank wage inputs
Even if dates are correct, blanks in key fields can cause incorrect numeric behavior:
- zeros via formula fallbacks,
- text values accidentally entering numeric calculations,
- default rates that aren’t what you intended.
Checker output impact: it highlights missing “rate” or “hours” fields for every row used in totals—so DocketMath doesn’t calculate with incomplete inputs.
When to run it
A spreadsheet check is most valuable before you run the Wage Backpay calculation in DocketMath—not after, and not while iterating on major logic changes (unless you already have reliable intermediate outputs).
Use this timing sequence:
- Before the first calculation run
- Confirm the spreadsheet derives the cutoff date using the 3-year general SOL under SDCL 22-14-1.
- After any date edits
- If you change work start/end dates or the measurement date, redo the check immediately. Date edits are the main driver of SOL filtering issues.
- After you change pay frequency logic
- If you switch from weekly to biweekly (or similar changes), re-check aggregation consistency.
- Before exporting or submitting calculations
- This helps prevent avoidable “data hygiene” issues that create rework.
Checkbox workflow you can follow:
Try the checker
To try the workflow, start with DocketMath’s Wage Backpay tool and run a spreadsheet pre-check first.
Primary CTA: /tools/wage-backpay
Inline link: If you want to confirm your input layout before running formulas, start here: /tools/wage-backpay.
How the outputs should change when issues are found
Below is what you should expect to see (or what should change in your totals) after fixes.
If the checker flags SOL window problems
- Fewer included workdays in the filtered dataset
- Backpay totals should drop to reflect the 3-year general SOL under SDCL 22-14-1
- Any “included vs. excluded days” breakdown in your sheet should clearly show intended cutoff handling
If it flags overlapping time blocks
- Time-range validation should either:
- merge overlapping rows, or
- exclude the duplicate portion
- Totals should move downward (sometimes materially), because overlapping wages were not meant to be counted twice
If it flags pay frequency or aggregation inconsistencies
- Totals should stabilize after formula adjustments
- If you compare by pay period, bucketed sums should match expected weekly/biweekly structure instead of drifting
One practical approach:
- Run the checker.
- Fix one category of issue at a time (dates, overlaps, pay frequency, missing inputs).
- Re-run the checker.
- Only then run the Wage Backpay calculation.
This staged approach reduces the risk of “fixing” one problem while introducing another.