Inputs you need for Wage Backpay in South Dakota
5 min read
Published April 15, 2026 • By DocketMath Team
Inputs you will need
Run this scenario in DocketMath using the Wage Backpay calculator.
To calculate wage backpay in South Dakota with DocketMath, you’ll want a clean set of wage, date, and employment details. This guide focuses on the inputs—so you can run an accurate DocketMath Wage Backpay calculation—rather than on legal strategy.
Minimum timeline rule (South Dakota)
DocketMath’s default wage-backpay lookback uses South Dakota’s general statute of limitations (SOL): 3 years under SDCL 22-14-1.
Because no claim-type-specific sub-rule was found for this scenario, DocketMath uses the general/default 3-year period as its default approach for South Dakota.
Note: If your situation includes facts that could affect which SOL applies (for example, a different statutory scheme or a tolling event), the numbers you enter may still be correct, but the date window used by the tool could change. This post can’t determine legal coverage for every fact pattern.
Core inputs checklist (Wage Backpay tool)
Use the checklist below to gather what DocketMath will need for US-SD.
- If you were still employed at the end of your records, use the last date you want included.
- Hourly: hourly rate(s)
- Salary: annual salary and any changes
Why date inputs matter
The date window determines what portion of wages falls inside the 3-year lookback associated with SDCL 22-14-1. Even if underpayment occurred for longer than 3 years, DocketMath’s SOL modeling will typically restrict the calculation to the applicable window—based on its default assumptions for South Dakota.
Where to find each input
Collecting inputs efficiently is often the difference between a run you trust and one you discard. Here’s where each input usually comes from.
Most inputs live in the case file, contracts, or docket entries. Dates usually come from the triggering event notice; rates and caps come from governing documents or statute; and amounts come from the ledger or judgment. Record the source for each value so the run is reproducible.
1) Employment dates (start/end)
Common sources:
- Offer letter or onboarding paperwork
- HR system screenshots/exports
- Separation letter or final paycheck documentation
- Pay history reports from your payroll provider
Tip: Use the earliest date you worked under the pay rate you’re challenging, and the latest date you want included in the backpay model.
2) Pay rate and salary/hourly classification
Common sources:
- Pay stubs (look for “rate,” “hourly,” or salary/pay structure indicators)
- HR compensation history
- Employment agreement for salary amounts
- Written pay rate change notices
If rates changed: DocketMath works best when you separate periods (even approximate periods are better than averaging everything into one rate), so “owed” wages align with what should have been paid during each span.
3) Hours worked (hourly)
Common sources:
- Timesheets (Shift logs, UKG/Kronos exports, spreadsheets)
- Payroll summaries showing hours
- Supervisor schedules when timesheets are missing
4) Amounts actually paid
Common sources:
- Paycheck stubs (look at the wage/gross wages portion)
- Payroll summary totals
- Direct deposit records (use carefully—often they don’t clearly separate wages vs. deductions)
5) Wage offsets/credits
Common sources:
- Pay stubs showing partial payments
- Corrective payments or “catch-up” checks
- Documentation showing amounts that should reduce backpay for the same wage category
Pitfall: Don’t switch between net pay (after deductions) and wages (gross wages). Use the wage/gross figures consistent with how the tool is calculating backpay for owed vs. paid.
Run it
Once your inputs are assembled, run the DocketMath → Wage Backpay tool for South Dakota (US-SD) here: /tools/wage-backpay.
Enter the inputs in DocketMath and run the Wage Backpay calculation to generate a clean breakdown: Run the calculator.
Step-by-step run checklist
- Total backpay over the SOL window
- Period-by-period breakdown (if available)
- Any sensitivity effects based on rate and hour inputs
How outputs change when inputs change
Use these practical rules to sanity-check your results:
| Input you change | Typical impact on backpay output |
|---|---|
| Extend end date farther back than 3 years | Total usually doesn’t increase for additional time if the SOL limits the window under SDCL 22-14-1 |
| Increase “owed” hourly rate | Backpay increases roughly proportionally to the owed-minus-paid wage difference |
| Update hours worked upward | Backpay rises, especially when underpayment is calculated per hour |
| Add an offset amount (already paid) | Backpay decreases dollar-for-dollar (depending on how the tool applies credits) |
| Correct salary amount or salary basis assumptions | Backpay changes based on the difference between owed vs. paid wage totals |
Warning: Avoid mismatched units. For example, don’t enter salary values while providing hourly hours, or use hours when the tool expects wage totals. Inconsistent inputs can produce results that look “precise” but aren’t accurate.
Quick accuracy test before you finalize
Before using results elsewhere:
- Check that the owed vs. paid difference matches what your pay stubs show
- Confirm your dates align with actual pay activity (not an estimated timeline that shifts everything)
- Confirm the tool’s 3-year default SOL assumption is appropriate for your modeling window under SDCL 22-14-1
If something looks off, adjust only one input category at a time (dates, rates, hours, offsets) and re-run.