Worked example: Wage Backpay in Michigan

Example inputs

Below is a worked example of how DocketMath calculates wage backpay for Michigan, using the tool’s general/default statute of limitations (SOL) approach for claims measured in wages and similar compensation.

Here is a simple illustration for Michigan. These values are for demonstration only and should be replaced with your actual inputs.

• Principal or amount: $100,000
• Rate or cap: 10%
• Start date: 2025-01-15
• End/as-of date: 2025-09-30

Jurisdiction-aware rule used (Michigan)

Michigan’s general statute of limitations for the default rule described in this example is 6 years, tied to:

• MCL § 767.24(1)
• General SOL Period: 6 years (default, because no claim-type-specific sub-rule was found)

Source (jurisdiction data): https://www.michigan.gov

Scenario

Assume an employee claims wages were not paid for a period that begins mid-year and ends recently. We’ll use a simple timeline and assume the employee would have worked the same number of hours each pay period, with no offsets at first.

• Backpay start date: 2020-07-01
• Backpay end date (work stopped / last unpaid date): 2024-05-15
• Pay frequency: Biweekly (every 2 weeks)
• Full-time base wage rate: $28.00 per hour
• Standard hours per pay period: 80 hours
• Overtime (if applicable): none in this example (hours are fixed at 80 per period)
• Other credits/mitigating wages (initially): $0 (we’ll adjust in the sensitivity check)

The wage backpay inputs you’d enter in DocketMath (wage-backpay)

Use these inputs to mirror the scenario in the wage-backpay calculator (Michigan code: US-MI):

• Jurisdiction: US-MI
• Backpay start date: 2020-07-01
• Backpay end date: 2024-05-15
• Hourly wage: $28.00
• Hours per pay period: 80
• Pay period length: 2 weeks
• Credits/offset wages received: $0

If your facts include partial payments, missed shifts, different hours, or other adjustments, reflect them by changing the hours and/or credits/offsets fields.

For the tool, see: **/tools/wage-backpay

Example run

Let’s run the calculation in a way you can follow and sanity-check.

Gentle disclaimer: This is a worked example for illustration and education, not legal advice. You should confirm limitations rules and wage calculations with qualified counsel or by reviewing the underlying facts.

1) Apply Michigan’s default statute-of-limitations window

Because this example uses Michigan’s general/default SOL (not a claim-type-specific rule), DocketMath applies a 6-year limitations window based on the end date of unpaid work.

• Backpay end date: 2024-05-15
• 6-year lookback start (limitations boundary): 2018-05-15 (approximate boundary; DocketMath handles exact day math)

Your requested backpay start date is 2020-07-01, which is within the 6-year window.

✅ Result: No truncation occurs for the limitations window in this example.
Backpay window used: 2020-07-01 through 2024-05-15.

2) Compute the number of pay periods in the window

The wage calculation uses pay periods, because this example assumes fixed hours-per-period.

• Start: 2020-07-01
• End: 2024-05-15
• Pay period length: 2 weeks

DocketMath counts the biweekly periods within the eligible window (including any alignment rules the tool applies to your specific dates).

For these provided dates, the tool’s outcome corresponds to:

• Pay periods counted: ~189

3) Convert pay periods to total hours

• Hours per pay period: 80
• Total hours:
  189 × 80 = 15,120 hours

4) Convert total hours to gross backpay

• Hourly wage: $28.00
• Gross backpay:
  15,120 × $28.00 = $423,360

5) Apply credits/offsets

• Credits/offset wages: $0
• Net backpay:
  $423,360 − $0 = $423,360

Example output (what DocketMath shows)

Conceptually, the result summary is:

Practical takeaways

• The 6-year rule affects how far back the tool looks—it doesn’t change the per-hour math.
• The largest driver is usually (hours × wage rate).
• Credits/offset wages can materially change the net number while leaving the eligible time window unchanged.

Sensitivity check

Now test how the result changes when you adjust key inputs. This helps with budgeting and with checking whether your assumptions match the reality of the wage record.

To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.

A) Move the backpay start date earlier (watch the SOL cutoff)

Change only:

• New backpay start date: 2017-08-01
• Backpay end date: 2024-05-15 (unchanged)

Under the 6-year default window (MCL § 767.24(1)), periods earlier than the limitations boundary (~2018-05-15) should be excluded.

Expected effect:

• Fewer pay periods counted
• Lower total hours
• Lower backpay total

What to look for in output:

• The tool should show a truncated backpay window beginning at the limitations boundary (not at your requested start date).

B) Increase/adjust hours per pay period

Assume the employee actually worked 75 hours per pay period instead of 80.

• Hours per period: 75
• Total hours: 189 × 75 = 14,175 hours
• Gross backpay: 14,175 × $28 = $396,900
• Net backpay (no credits): $396,900

Change compared to baseline:
$423,360 → $396,900 (a reduction of $26,460)

C) Include offset wages received

Assume the employee earned $20,000 in wages from alternative work during the backpay period (as an offset/credit input).

• Baseline gross backpay: $423,360
• Credits/offset wages: $20,000
• Net backpay: $403,360

Expected effect: The SOL still determines what time is eligible; credits then reduce the net number.

Related reading

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