Common Wage Backpay mistakes in Montana

The top mistakes

When you calculate wage backpay in Montana with DocketMath (jurisdiction code US-MT), the most common errors usually come from assumptions that quietly change your numbers—especially around deadlines and what counts as “back wages.” Below are the practical mistakes to watch for, and how each one can affect your total.

1) Using the wrong deadline (statute of limitations)

A frequent issue is starting backpay too early—using the earliest date that comes to mind rather than the earliest date that falls within Montana’s limits window.

• Montana general/default SOL period: 3 years
• General statute: **Montana Code Annotated § 27-2-102(3)
• Practical effect: If your backpay request covers more than 3 years, wages in the older portion may be barred even if they were earned.

How DocketMath handles this: DocketMath applies the general/default limitation because no claim-type-specific sub-rule was identified here. That means the tool’s default assumption is the 3-year general period, not a specialized wage enforcement timetable.

2) Treating every paid amount as “back wages”

Another common error is building your backpay total from amounts that either don’t belong in the wage figure or shouldn’t be treated the same way as wages.

Common mix-ups include:

• including penalties/interest in the “wages” number
• including reimbursements or other non-wage compensation as if it were wages
• counting bonuses without clarifying whether they were part of the wage entitlement you’re modeling
• forgetting to properly account for items that matter when the dispute involves overtime-related components (if applicable)

Why it matters: Even with a correct 3-year window, an incorrect wage base can push your total too high (or too low).

3) Mis-specifying the pay structure used to compute totals

Backpay math depends on your payroll structure. If your inputs don’t match what your records actually show, the output will only reflect what you entered—not what you’re owed.

Examples:

• entering a single hourly rate when your records show rate changes
• using a salaried-to-hourly conversion when the timeline should reflect a different calculation approach
• not reflecting pay grade/role changes that occurred over time

Result: date-and-rate mismatches can create errors even if your hours are right.

4) Failing to reconcile “hours you worked” vs. “hours you were paid for”

A documentation problem that repeatedly shows up is assuming hours worked equals hours paid.

Typical scenarios:

• timesheets show 42 hours, payroll paid 40
• two record systems disagree (for example, one department’s timekeeping vs. payroll)
• scheduled time was treated as “worked” without the same approval trail

Calculation impact: the backpay shortfall should be based on what was owed versus paid, not simply on gross hours or gross pay.

5) Ignoring partial weeks at the edges of the calculation window

Edge dates can change totals dramatically due to the way weekly or daily segments roll up.

Common mistakes:

• including the first day that falls outside the 3-year window
• excluding the last day that should be inside the window
• mixing up “date filed/commenced” vs. “date notice/claim was made” when building your timeline

Practical tip: even a one-day shift at the start can alter your weekly segments and multiply across the calculation.

6) Inputting the wrong employment dates

This is more common than it seems. Examples include:

• entering month-only or “approximate” dates
• using an offer date instead of the actual start date
• using the termination date instead of the actual last work date (where relevant to your model)
• skipping unpaid leave or suspended work periods when the calculation depends on hours worked

Why it matters: incorrect start/end dates distort the entire wage timeline and the hours-rate matching.

How to avoid them

Use a repeatable workflow before you generate a DocketMath output. The goal is to ensure the tool is using accurate inputs and the correct Montana rule set.

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.

Step 1: Lock the Montana 3-year window

Define the backpay start date using Montana’s general/default SOL period:

• General SOL period: 3 years
• Authority: **Montana Code Annotated § 27-2-102(3)
• Default vs. special rules: This uses the general/default period because no claim-type-specific sub-rule was identified here.

Checklist:

Step 2: Separate wage amounts from non-wage items

Before entering numbers, build two categories:

• **wages owed (wage components)
• non-wage items (exclude unless your entitlement theory clearly treats them as wages for your model)

Quick safeguards:

Step 3: Match pay rates to the exact dates they apply

If your rate changed, don’t average it.

Step 4: Reconcile timekeeping and payroll

Build a simple comparison for the periods you’re modeling:

• hours worked (time records)
• hours paid (payroll)
• the difference (used to identify wage shortfall)

If the difference table doesn’t align with your expected unpaid hours, your totals won’t align either—regardless of how correct the SOL window is.

Step 5: Audit edge dates (off-by-one checks)

Do a boundary review:

Step 6: Validate outputs with sanity checks

After you generate a DocketMath output, check whether it “scales” with your assumptions:

If your total is unexpectedly high, the usual causes are:

Finally, treat DocketMath results like an audit trail:

If you’re ready to try it, start here: /tools/wage-backpay.

Related reading

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