The top mistakes

Run this scenario in DocketMath using the Wage Backpay calculator.

If you’re using DocketMath’s Wage Backpay calculator in Utah (US-UT), the fastest way to get an incorrect number is to feed it assumptions that don’t match Utah’s wage-and-hour and limitations landscape. Below are the most common mistakes people make when calculating wage backpay and then using that figure for a demand or filing.

1) Using the wrong lookback window (statute of limitations)

A common error is assuming a longer limitations period based on other states’ rules or generic “wage claim” timelines. In Utah, you should start with the general/default SOL period of 4 years.

• General SOL period (default): 4 years
• General statute: Utah Code § 76-1-302
• Utah limitations reference: https://www.utcourts.gov/en/legal-help/legal-help/procedures/statute-limitation.html

Why this matters for your math: DocketMath calculates backpay by tying wages owed to a time period. If you accidentally look back 6 years instead of 4, your backpay total can inflate dramatically—especially when overtime is involved.

2) Mixing up “gross” vs “net” pay assumptions

Another frequent issue is inconsistent “wage” inputs:

• Some inputs reflect gross wages (hours × rate).
• Others reflect net pay (what hit the paycheck after deductions).

What goes wrong: If you enter net amounts but treat them like gross wages (or vice versa), your “should have been paid” versus “actually paid” comparison can become mismatched—leading to understatements or overstatements.

3) Omitting overtime hours or entering them in the wrong fields

Overtime is where backpay math often drifts.

Common data-entry mistakes include:

• Entering overtime hours into the “regular hours” field.
• Leaving overtime hours at zero because timesheets are missing.
• Applying an overtime multiplier yourself when the calculator already accounts for overtime pay based on its own defined inputs.

Result: Even a small hours-entry error can change the earnings gap substantially, which then cascades into a higher total.

4) Using the wrong start/end dates for the pay-period timeline

Even if your limitations window is correct, date-range errors can still produce a wrong result.

Examples:

• Starting the lookback at the employment separation date instead of the first missed wage period.
• Using the wrong pay schedule (for example, biweekly vs weekly), which shifts how pay periods are grouped.
• Ending the range after the date corrective payment was received (meaning the corrected period may be counted incorrectly as still unpaid).

Impact: DocketMath’s output changes based on the date range you enter. A few misaligned pay periods can move totals by hundreds or thousands.

5) Counting corrected/reinstated wages twice—or skipping them

Employers sometimes correct partial payments:

• A catch-up payment may be made in a lump sum.
• Rate changes may begin midstream.
• Some shifts may be re-paid.

error patterns:

• Double subtraction: you manually subtract prior payments and also enter wages paid into the calculator (counting the same amounts twice).
• Double counting: you don’t account for corrected wages at all, so periods that were partially fixed get treated as fully unpaid.

6) Applying one pay rate across a period where rates changed

Utah backpay calculations can be materially off when pay rates change during the lookback window.

Typical triggers:

• Promotions or job reclassification
• Scheduled wage increases
• Off-cycle pay adjustments
• Different rates tied to work type or classification

If you use one rate for the entire window: your total can become inaccurate—particularly for overtime-heavy workweeks.

How to avoid them

DocketMath can reduce guesswork, but only if your inputs reflect the underlying facts you’re modeling. Use this checklist before you click the calculator.

If you want to run the numbers, start at: /tools/wage-backpay

Step 1: Lock the limitations lookback to Utah’s default 4-year SOL

Use a 4-year lookback period as the general/default rule.

• Utah Code § 76-1-302 (general/default): 4 years
• Utah courts limitations help page: https://www.utcourts.gov/en/legal-help/legal-help/procedures/statute-limitation.html

Important clarification: No claim-type-specific sub-rule was found in the provided data, so the 4-year period is the general/default default you should start from.

Practical workflow

• Identify the first pay period where unpaid wages began (your factual start).
• Identify the end date you’re modeling (often the last date of nonpayment, or the date corrective pay was made).
• Apply a maximum lookback of 4 years from the relevant trigger date you’re using in your calculations.

Step 2: Separate regular vs overtime hours (and confirm how DocketMath expects inputs)

If you have overtime:

• Enter regular hours in the regular-hours field.
• Enter overtime hours in the overtime-hours field.

Also confirm whether the calculator expects:

• Hours only (and it computes the overtime wages internally), or
• Already-calculated overtime wages (in which case you shouldn’t also apply overtime multipliers yourself).

Quick sanity check

• Compare total hours entered to your timesheet totals.
• Spot-check 1–2 pay periods:

  • Regular earnings = regular hours × regular rate (as defined for your scenario)
  • Overtime earnings = overtime hours × overtime rate/multiplier (as defined for your scenario)

Step 3: Use a consistent “wage basis” on both sides (gross-to-gross)

Pick the concept you’re modeling and keep it consistent:

• If your “should have been paid” side is gross, your “actually paid” side should also reflect gross (or be converted/modeled consistently).
• If your payroll record only gives net, don’t mix net with gross assumptions.

A practical approach is to align both sides around the same method (for example, an hourly-rate-based approach rather than blending paystub net amounts with gross expectations).

Step 4: Use pay-period-aligned dates, not just event dates

Try to use pay-period dates (or the date inputs the calculator is designed for) rather than approximate calendar events.

Checklist:

Step 5: Account for corrective payments once—through DocketMath, not twice

If DocketMath has fields for wages already paid / prior payments / adjustments, use them consistently.

Common safe pattern:

• Calculate or model what you believe you were owed per period.
• Use the calculator’s “wages actually paid” / prior payments side to capture amounts already paid.
• Avoid manual subtraction outside the tool unless the tool specifically requires it.

Step 6: Handle pay-rate changes by segmenting the calculation

If your rate changed during the lookback window:

• Don’t average everything into one number unless DocketMath is explicitly designed to do that for your scenario.
• Prefer segmented inputs (or reruns) at the correct rate(s), then sum the results.

Output sensitivity tip: If the result changes drastically when you adjust the rate, treat that as a sign to verify your pay-rate history—especially if overtime was frequent.

Related reading

• Browse the blog

The top mistakes

• missing a required input
• using a stale rate or rule
• ignoring calendar or holiday adjustments
• skipping documentation of assumptions

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

Capture the source for each input so another team member can verify the same result quickly.

How to avoid them

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

Related reading

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