Inputs you need for Wage Backpay in Montana

Inputs you will need

Run this scenario in DocketMath using the Wage Backpay calculator.

To calculate wage backpay in Montana with DocketMath (US-MT), you’ll need inputs that let the tool reconstruct the wage shortfall pay period by pay period, then apply Montana’s jurisdiction-aware time window. The main jurisdiction rule you should expect to see applied here is the general/default statute of limitations (SOL)—which sets the default lookback period for what dates count.

Core wage-backpay inputs (math)

• ☐ Pay rate type (choose one):

  • ☐ Hourly wage
  • ☐ Salary (convert using an hourly equivalent or workweek schedule, if your setup requires it)
• ☐ Regular hourly rate (or equivalent wage figure)
• ☐ Work hours you should have been paid each pay period
  (Use a consistent estimate if exact hours aren’t available.)
• ☐ Backpay period start date
  (Earliest date you want DocketMath to consider.)
• ☐ Backpay period end date
  (Latest date you want DocketMath to consider.)
• ☐ Wages actually paid for the covered period (if any; otherwise enter $0)
• ☐ Frequency (e.g., weekly, biweekly, semimonthly, monthly)

**Overtime (if applicable)

• ☐ Overtime rules and hours (only if your work included overtime)

  • ☐ Indicate overtime hours and overtime rate

Montana jurisdiction-aware input (time window)

• ☐ SOL cutoff applied by calculator

  • DocketMath uses Montana’s general/default SOL for this wage-backpay setup.
  • General SOL period: 3 years under Montana Code Annotated § 27-2-102(3).
  • The tool will generally exclude dates older than the SOL window from the backpay calculation, unless the tool supports overriding dates in a way that changes which dates are counted.

What “general/default period” means here

No claim-type-specific sub-rule was identified for this workflow based on the materials provided. That means the time window should be treated as the default general statute of limitations—3 years—rather than a guarantee that every possible wage-backpay theory uses the same timing rule.

Quick sanity-check numbers to gather

Before you enter anything into DocketMath, it helps to collect:

• ☐ Number of pay periods between your start and end dates
• ☐ Typical hours per pay period
• ☐ Any known changes to pay rate (raise, demotion, contract change) during the period

If your pay rate changed midstream, you’ll typically get cleaner math by running separate calculations for each distinct rate period and then adding the totals.

Where to find each input

Use this section as a “retrieval map” so you know where to pull each fact (payroll, HR files, schedules, and personal records).

Most inputs live in the case file, contracts, or docket entries. Dates usually come from the triggering event notice; rates and caps come from governing documents or statute; and amounts come from the ledger or judgment. Record the source for each value so the run is reproducible.

1) Pay rate and wage details

Common sources:

• ☐ Offer letter / employment agreement
• ☐ Pay stubs (show the regular rate and overtime entries, if any)
• ☐ Payroll history / HR records
• ☐ Timekeeping records (timesheets, scheduling systems)

What to extract:

• ☐ Regular hourly rate (or the salary + your expected schedule so it can be converted)
• ☐ Overtime hours (if any) and how overtime was calculated

2) Hours you should have been paid

Common sources:

• ☐ Timesheets you submitted (for example, before the wage issue began)
• ☐ Work schedules (rosters, staffing calendars, staffing logs)
• ☐ Performance expectations or documented requirements (if schedules aren’t available)

Tip:

• ☐ If you can’t find exact hours for every week, use the most reliable consistent baseline you can support (for example, a regular schedule or historical averages). DocketMath will compute from whatever you enter—your documentation is what makes the assumptions credible.

3) Backpay period dates

Common sources:

• ☐ Termination date (or last day you performed eligible work)
• ☐ Start date of wage loss (when pay stopped, reduced, or became improperly calculated)
• ☐ Demand/complaint timeline (useful for aligning the calculation window with how SOL filtering is applied)

Montana SOL reference used in this workflow:

• Montana’s general SOL is 3 years under Mont. Code Ann. § 27-2-102(3).

4) Wages actually paid

Common sources:

• ☐ Pay stubs during the disputed timeframe
• ☐ Payroll summaries
• ☐ Bank statements (often less ideal than payroll records)

Goal:

• ☐ Enter the amount DocketMath needs to determine the difference between what you should have been paid and what you were actually paid (if you have partial wages).

Run it

1. Open DocketMath’s wage-backpay calculator
   Use the primary CTA: /tools/wage-backpay.

2. Enter your dates and wage facts

   • Start with pay rate (hourly or salary setup).
   • Add hours per pay period and pay frequency.
   • Set backpay period start date and backpay period end date.
   • Add wages actually paid (or $0 if none were paid for the relevant shortfall).

3. Let Montana’s SOL window apply DocketMath’s Montana (US-MT) setup uses the general/default 3-year SOL:

   • Mont. Code Ann. § 27-2-102(3) (General SOL period: 3 years)

   Practical meaning:

   • If the calculation framework treats your start date as older than the 3-year window, the tool will limit the covered dates it counts.
   • If your start date is within the 3-year window, the calculator can include it.

4. **Check how outputs change (what-if testing) Try a few controlled changes to make sure the math behaves the way you expect:

   • If you increase hours per pay period
     “Should have been paid” increases, so backpay typically increases (before considering wages actually paid).
   • If you enter wages actually paid
     Net backpay decreases by that amount (or by the portion applicable to the covered period).
   • If you move your start date earlier than 3 years
     Backpay results may not change much because the SOL limiter filters out older dates under the general/default rule.
   • If you split due to pay rate changes
     Run separate calculations for each pay-rate band, then combine totals.

5. Record the outputs Save (or screenshot):

   • Total backpay (net and/or gross, depending on what the tool displays)
   • Covered period dates after SOL filtering
   • Assumptions you entered (hours, overtime settings, wages actually paid, dates)

1. Next practical step Export or screenshot your results and keep your input assumptions with supporting documents:

   • pay stubs
   • schedules/timesheets
   • any notes explaining why the start date and hours estimate are what they are

This makes it easier to review your backpay reconstruction later.

Related reading

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