Why Wage Backpay results differ in Utah
6 min read
Published April 15, 2026 • By DocketMath Team
The top 5 reasons results differ
Run this scenario in DocketMath using the Wage Backpay calculator.
If your Wage Backpay numbers in Utah look inconsistent across two runs (or two calculators/tools), DocketMath is usually applying a jurisdiction-aware timing rule and then combining it with input-driven differences. In Utah, the most common driver is the general statute of limitations (SOL) period of 4 years.
Utah’s general/default SOL is 4 years under Utah Code § 76-1-302. Utah Courts also explains the general SOL framework for limitation periods (as a general guidance point). Importantly, your brief notes no claim-type-specific sub-rule was found, so this content treats the 4-year general rule as the default for these comparisons.
Here are the top 5 reasons results differ in US-UT:
The lookback start date shifts
- DocketMath’s wage backpay logic uses a “lookback” window that effectively anchors on the SOL cutoff.
- Even a few days difference between the event/trigger date you input (for example, violation/discovery/filing trigger—depending on how you’re using the tool inputs) and the pay period dates you include can move whole paychecks into or out of the 4-year window.
Pay period coverage changes
- Two runs can have similar wage facts but use different pay period ranges.
- If one run includes pay periods partially outside the 4-year window, totals will diverge because the tool may exclude those out-of-window periods.
Misalignment between hourly wage inputs and earnings frequency
- Pay frequency (weekly vs. biweekly vs. semi-monthly) matters.
- If one run converts hourly wage into earnings using one frequency/assumption, while the other run uses a different frequency—your per-period backpay math changes, even if the SOL boundary is the same.
Different treatment of adjustments
- Outputs can change when you include/exclude:
- overtime hours,
- different wage rates over time,
- wage changes during the relevant 4-year period.
- Small wage-rate changes can compound across many included pay periods, amplifying differences.
Time zone / date parsing differences
- If one dataset treats a date as the start of a day and another treats it as the end (or uses inconsistent formatting), the SOL boundary can shift at the “edges.”
- This commonly presents as a “why did it include one extra period/month?” situation—an off-by-a-period or boundary-parsing issue.
Pitfall to watch: The Utah 4-year SOL rule (Utah Code § 76-1-302, using the general/default period) is what decides which periods count. If your anchor input date differs even slightly, the set of eligible pay periods can change—and so will the output.
How to isolate the variable
Use a structured “two-run” approach in DocketMath. The goal is to determine whether the difference comes from the SOL cutoff/eligible period selection or from paycheck math (wages, hours, overtime, adjustments).
- 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 isolation checklist
- Run 1: Use your best estimate of the anchor/trigger date.
Run 2: Change only that date by +7 days.
Compare outputs:
- If totals jump by a period-sized chunk, the SOL cutoff is likely the driver.
- If totals shift only slightly, you may be dealing more with paycheck math inputs than SOL eligibility.
Make sure both runs reference the exact same pay period start/end dates.
If DocketMath (or your workflow) “rebuilds” pay periods automatically, confirm the inclusion logic is consistent across runs.
Confirm hourly wage amounts are the same in both runs.
If wage increases occurred during the relevant 4-year period, check whether each run models the correct wage rate for each pay period rather than averaging incorrectly.
Ensure hours are entered/derived consistently per pay period.
A common issue: one run implicitly assumes 40 hours/week while the other run uses biweekly periods without adjusting how those hours roll up.
If overtime exists, ensure both runs use the same overtime flags/rates and same mapping of overtime hours to the correct pay periods.
If adjustments exist (different wage components, separate rates), include/exclude them consistently.
Utah timing anchor you should expect to show up
For Utah, the comparison behavior should reflect the general/default 4-year SOL under Utah Code § 76-1-302 (no claim-type-specific sub-rule identified in your brief). When your inputs shift pay periods across the “in-window vs. out-of-window” boundary, totals change because eligible periods change—not because the underlying wage arithmetic necessarily changed.
Next steps
Run two scenarios and record the delta
- Use the smallest change that produces a different result (often anchor date or pay period boundary).
- Document:
- anchor date used,
- earliest included pay period date,
- latest included pay period date,
- number of pay periods counted.
Audit the first and last included pay periods
- Find the “edge” periods—where the included range begins and ends.
- If that first included period looks close to a boundary, your likely culprit is date entry/parsing or the anchor date.
Reconcile wage-rate schedules
- If you had wage changes, confirm DocketMath is applying the correct wage rate to the correct dates.
- If one run uses a blended rate and another uses a time-sliced schedule, results can diverge substantially.
Do a quick per-period sanity check
- Pick 1–2 pay periods that are clearly included in both runs.
- Manually estimate: (hours × rate [+ overtime/adjustments if any]) and compare to what the tool implies for those same periods.
Gentle reminder: this is a diagnostic walkthrough to explain why outputs differ in the tool. It’s not legal advice about whether any claim is time-barred.
If you’re starting from scratch, you can use /tools/wage-backpay to reproduce the inputs and test the differences.