How to run Wage Backpay in DocketMath for Maryland

Step-by-step

Run this scenario in DocketMath using the Wage Backpay calculator.

This guide walks you through running Wage Backpay in DocketMath for Maryland (jurisdiction code US-MD). You’ll also see how Maryland’s general statute of limitations (SOL) drives the date inputs and the “eligible backpay” window.

1) Start the calculator in DocketMath

1. Open the tool: /tools/wage-backpay.
2. Confirm the jurisdiction is set to Maryland (US-MD).

If DocketMath provides a jurisdiction selector, choose US-MD before entering dates so the calculator can apply the correct SOL logic.

2) Enter the “backpay lookback” anchor (the key date)

Most wage backpay calculations in DocketMath rely on a core anchor date—commonly the date you’re treating as the start of the backpay period or the filing/claim date used to measure the limitations window.

Use the calculator’s fields to set the relevant anchor, such as:

• Claim date / filing date (the date used to measure the SOL window), and/or
• Start date for the wage period you want to evaluate.

Maryland’s general SOL period is 3 years under Md. Code, Cts. & Jud. Proc. § 5-106. Because no claim-type-specific sub-rule was identified for this calculator workflow, this guide assumes DocketMath applies the general/default 3-year limitations window.

3) Set the wage period you want to test

Enter the date range for the wage backpay period you’re analyzing. Typical inputs include:

• Backpay start date (e.g., first day wages were not paid)
• Backpay end date (e.g., last unpaid day through a cutoff date)

As you edit these, watch for two behaviors:

• Date clipping: if your start date is more than 3 years before the anchor date, DocketMath will effectively treat the recoverable period as starting at the SOL threshold.
• Proration changes: if you input hourly wages or partial months/weeks, totals will adjust based on the calendar coverage inside the allowable window.

4) Add wage/compensation inputs

Depending on how the calculator is configured, provide the wages the employer allegedly owed. Common fields include:

• Hourly rate (if applicable)
• Weekly or biweekly rate (if you prefer pay-period totals)
• Hours per week or hours per day
• Employment schedule assumptions (if the tool asks for expected hours)

How outputs change (practically):

• Higher hourly rate → higher backpay principal.
• More hours per week → larger totals across the same SOL-windowed timeframe.
• Shorter wage date range → smaller totals even if hourly rate stays constant.

5) Include additional wage components (if supported)

Some wage backpay scenarios require more than a base wage figure. If DocketMath offers fields for additional components, enter them in the calculator’s specific options. Examples (depending on what the tool supports):

• Overtime (if you model it),
• Bonus/commission amounts (if the tool supports it),
• Other compensable items (if available).

If the tool doesn’t support a component, the backpay may be computed only from the core wage inputs.

Common issue: If you enter overtime or other compensation in the wrong field (or omit a component when the tool expects it), the total can change materially—especially when the wage window is large.

6) Review the output breakdown

After you run the calculator, review what DocketMath returns. You’ll typically see:

• Backpay principal for the SOL-limited timeframe, and
• A breakdown by:

  • time period (month/week/day buckets), and/or
  • wage component (base vs. overtime/other, if supported).

Before using the number elsewhere, verify two items:

1. The eligible start date used by the SOL logic (the “effective” backpay start).
2. The effective date range after 3-year clipping under US-MD (general/default).

7) Save/export your results for consistency

If DocketMath allows saving:

• Save the run with your assumptions so you can compare revisions (e.g., different wage end dates or different hours schedules).
• If there’s an export/copy feature, use it to preserve the exact input set alongside the output.

Practical tip: If you plan multiple scenarios, keep one baseline run and then update only the date fields (or only hours) to see how sensitive the output is.

Common pitfalls

Below are issues that commonly produce incorrect or misleading wage backpay results when running DocketMath’s wage backpay calculator for Maryland.

• Maryland’s general SOL period is 3 years under Md. Code, Cts. & Jud. Proc. § 5-106.

• This workflow uses the general/default period because no claim-type-specific sub-rule was identified for this setup.

• If your backpay start date is earlier than the 3-year window measured from the anchor date, DocketMath will compute from the SOL threshold—not your original start date.

• Accidentally entering an end date where a start date is expected can:

  • shrink the wage window to near-zero, or
  • expand it incorrectly (which can create unexpected output).

• Wage backpay totals are highly sensitive to hours per week and pay-period assumptions.

• Even small schedule changes (e.g., 20 vs. 30 hours/week) can create large differences across 3-year windows.

• If the tool wants an hourly rate, entering a total monthly or pay-period amount as the hourly rate can inflate results dramatically.

• If you include overtime, make sure overtime hours and overtime rate match what DocketMath expects for that field (otherwise totals may be understated or overstated).

Try it

Use this quick “sanity check” workflow to validate your DocketMath run before relying on the result:

1. Set jurisdiction to US-MD
2. Enter a claim/anchor date (the date used to measure the SOL window)
3. Choose a backpay range that spans more than 3 years so you can confirm SOL clipping happens
4. Run the calculator and confirm:

   • the output reflects only the 3-year lookback window per Md. Code, Cts. & Jud. Proc. § 5-106
   • the effective eligible start date matches the calculated threshold

Then run two comparisons:

• Scenario A: Backpay start date = SOL threshold date
• Scenario B: Backpay start date = one year earlier than SOL threshold

Expected outcome:

• Scenario B should not increase the total beyond what the general 3-year period allows, because only the SOL-eligible portion should count.

Start here for navigation and convenience:

• /tools/wage-backpay

If you want to iterate quickly, keep everything the same except:

• end date (to test cutoff sensitivity), or
• hours per week (to test schedule sensitivity).

Related reading

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