Why Wage Backpay results differ in South Dakota

The top 5 reasons results differ

When you run a Wage Backpay calculation with DocketMath in South Dakota (US-SD), different outputs usually come from a small set of inputs and how the jurisdiction rules are applied. In South Dakota, the general statute of limitations (SOL) period is 3 years under SDCL 22-14-1. No claim-type-specific sub-rule was found, so this should be treated as the default/general lookback period for wage backpay computations in US-SD.

Here are the most common reasons results differ across people, spreadsheets, or repeated runs.

1. **SOL cutoff date mismatch (3-year lookback)

   • Even if both runs say “3 years,” they may apply it from different triggers (for example, “3 years before filing” vs. “3 years before the last day worked”).
   • Because the SOL lookback window controls which pay periods are eligible, changing the start/cutoff date can immediately change the total months/periods included.

2. Different “work period” endpoints

   • Wage backpay totals often depend on what you treat as the end of the relevant time window, such as:

     • the date pay stopped,
     • the date pay resumed (if applicable),
     • or the end of the “violation” period used in your timeline.
   • A small endpoint change (even a couple of months) can materially affect totals.

3. **Pay rate inputs not aligned (hourly vs. effective weekly/annualized)

   • If one run uses $X/hour and another uses an effective weekly or annualized figure, results can diverge—especially if:

     • hours/week assumptions differ,
     • overtime assumptions differ,
     • or bonuses/commissions are mapped differently into wage components.

4. Pay frequency and proration/compounding assumptions

   • Some models compute wages by pay period directly; others annualize and then prorate.
   • If pay frequency inputs (weekly vs. biweekly vs. semi-monthly) or proration rules differ, the included dollar amount per period can shift, causing different totals even with the same base hourly rate.

5. Inclusion/exclusion of wage components

   • Two runs can agree on the hourly wage yet disagree on whether specific earnings are included as “wages” in the dataset driving the calculation.
   • Since DocketMath can only compute what you input, inconsistent inclusion rules (base pay only vs. base + certain incentive pay, etc.) will produce inconsistent results.

How to isolate the variable

Use a controlled comparison. The goal is to change one input or one rule at a time and see which change causes the largest shift in the result. That usually identifies the driver quickly.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

Step-by-step diagnostic checklist

• Ensure both runs use the same “event date” and the same SOL-based cutoff logic.

  • Confirm you are using 3 years as the general/default SOL period under SDCL 22-14-1.
  • Don’t just compare “3 years” statements—compare the exact date each run uses as the start of the lookback window.
  • If those cutoff dates differ by even weeks or months, the totals can diverge.
  • Ensure both runs use the same unit approach (e.g., hourly rate + consistent hours/week).
  • Align overtime/extra-pay assumptions if your inputs include them.
  • Confirm both runs include the same number of eligible pay periods and treat partial periods the same way (proration).
  • Make a simple component inventory for each run:

    • base pay included? ☐
    • overtime included? ☐
    • commissions/bonuses/incentives included (if your dataset treats them as wages)? ☐
  • The component list should match across runs.

Quick “change one knob” test (recommended)

Run these in order, changing only one thing per run:

1. Run A: baseline inputs
2. Run B: change only the SOL lookback start/cutoff date
3. Run C: change only hours/week (or equivalent time-rate inputs)
4. Run D: change only the wage rate amount (keeping units consistent)
5. Run E: change only the end date (or wage stop/resumption endpoint)

Whichever run creates the biggest swing usually points to the variable driving your discrepancy.

Practical note: If you change both dates and pay inputs at the same time, it becomes hard to know which factor caused the difference.

For the actual computation tool, start with DocketMath’s Wage Backpay calculator: /tools/wage-backpay.

Next steps

Once you isolate the cause, you can make your calculations more consistent and easier to review.

• Write down the SOL rule you applied

  • Document that South Dakota uses a 3-year general SOL under SDCL 22-14-1.
  • Also document your practical translation: how you determined the lookback start/cutoff date for the time window.
  • (Because no claim-type-specific sub-rule was found, treat 3 years as the default/general period for these runs.)
• Create an input ledger

  • For each run, record:

    • the backpay start/cutoff date,
    • the backpay end date,
    • wage rate type and unit,
    • any hours/week or pay-period assumptions,
    • and which compensation components are included.
• Re-run with the stabilized set

  • After aligning dates and wage inputs, run DocketMath again to confirm the results converge.
• Keep versions instead of overwriting

  • If you’re exploring alternatives (different timelines, endpoints, or wage compositions), label them clearly rather than editing the same run repeatedly.

Gentle disclaimer: This is a practical workflow for diagnosing calculation differences, not legal advice.

Related reading

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