How to interpret Wage Backpay results in Maryland

What each output means

DocketMath’s Wage Backpay calculator is designed to translate key facts about unpaid wages into (1) a backpay amount and (2) a time-based view of what portion of those unpaid wages may be treated as “covered” in Maryland (US-MD).

For Maryland, the calculator applies the general/default statute of limitations you provided: 3 years under Md. Code, Cts. & Jud. Proc. § 5-106. Also note: the brief you supplied did not identify any claim-type-specific sub-rule. So the tool uses the default 3-year period rather than a specialized timeline.

When you use DocketMath’s Wage Backpay tool, you’ll typically see outputs that you can map to these concepts:

• Backpay (covered period)
  This is the unpaid wage amount limited to the portion of time that falls within the applicable limitations window. In Maryland, interpret this as generally the portion of wages earned within the last ~3 years (relative to the tool’s anchor logic). The limitations basis is Md. Code, Cts. & Jud. Proc. § 5-106.

• Unpaid time window / lookback period
  This is the time span the calculator uses to determine what gets counted toward the “covered period” total. In practical terms for Maryland, treat this as the period where unpaid wages are “eligible” to be included under the general 3-year rule from § 5-106. Wages earned outside that window typically won’t appear in the covered period number.

• Daily/weekly wage rate used (if shown)
  If your inputs include an hourly rate, annual salary, or hours per week, the calculator will standardize to a consistent rate and then multiply by the covered unpaid days/weeks. This means:

  • if the rate conversion is based on incorrect inputs, the backpay number will be off, and
  • even small rate errors can compound across many covered pay periods.

• Total wages vs. any adjustments (if shown)
  Some results break the calculation into components (for example, a base wage total, then adjustments driven by the timing or wage-rate fields you selected). Interpret these as building blocks that roll into the final covered-period backpay figure.

Two questions to interpret every run correctly

1. What wage rate did you enter (and did the tool convert it the way you expect)?
   If your hourly rate, hours-per-week, or salary-to-hours assumptions are inconsistent with your actual pay, the wage-rate output will drive an inaccurate backpay total.

2. Did the calculator include the right dates inside the 3-year window?
   Because Maryland uses the general/default 3-year SOL in § 5-106, the covered-period result depends heavily on whether the periods you want counted fall within the calculator’s lookback window.

What changes the result most

In most backpay models, the result changes most when you adjust items that affect either:

1. the wage rate (multiplier) or
2. the amount of time included inside the 3-year covered window (time window).

These inputs have the biggest impact on the final number. Adjust them one at a time if you need a sensitivity check.

• date range
• rate changes
• assumption changes

High-impact factors

1. The wage rate you entered

   • Hourly rate vs. salary conversion
   • Average hours per week (or pay period hours)
   • Pay frequency assumptions (weekly/biweekly/monthly), if the tool asks for them

   Practical effect: if the rate is understated, the covered-period backpay can be too low because the error repeats across the covered earnings.

2. The start date / lookback window anchor DocketMath’s Maryland logic relies on the general 3-year limitations period under Md. Code, Cts. & Jud. Proc. § 5-106. The “start date” (or the tool’s internal anchor date logic) determines which weeks fall inside vs. outside the window.

   Practical effect: if you move the anchor date, you can gain or lose covered weeks even when the wage rate stays the same.

3. **The dates of unpaid work you entered (unpaid time model) If your inputs represent unpaid time as days out, number of weeks, or pay periods, the tool may include those days/weeks in the covered period. Overstating unpaid time can inflate the result; understating can suppress it.

4. Whether pay is modeled consistently If your situation includes multiple wage components (for example, base pay plus another component) and you only enter one part, the tool may undercount. If DocketMath shows multiple wage fields, ensure they match what actually became “unpaid wages” in your situation.

Quick interpretation checklist (use after you run /tools/wage-backpay)

• Does the wage rate used reflect what your pay records actually support (gross wages for the relevant period)?
• Is the “covered period” length close to 3 years (consistent with § 5-106), given the tool’s anchor logic?
• When you change inputs, does the output move more due to:

  • rate changes (wage inputs), or
  • date/window changes (lookback inputs)?
• If the result feels unexpectedly high/low, did it change mainly because of rate (multiplier) or dates (time window)?

Next steps

The most useful next steps are practical: verify inputs, confirm the timing logic, and run a couple of “sanity check” tests to understand what drove the result.

1. Reconcile your timeline to the 3-year covered period Since Maryland’s general limitations period is 3 years under § 5-106, confirm whether the calculator’s lookback window matches your actual unpaid wage timeline. If your unpaid wages extend beyond 3 years, you should expect only the portion within the general 3-year window to appear in the covered period total.

2. Verify wage-rate inputs against documents Compare what you entered to pay records such as:

   • pay stubs,
   • payroll summaries,
   • offer letters or employment agreements for base pay terms.

   If the tool uses an hourly equivalent, ensure the hours-per-week assumption reflects your actual historical schedule.

3. Create a simple wage timeline Write down (even roughly):

   • when unpaid wages began,
   • whether pay rate changed (and when),
   • when unpaid wages ended,
   • the date/anchor logic your run is using (as shown by the tool or implied by your inputs).

4. Run a quick sensitivity test You don’t need to redo everything—just test what matters:

   • adjust wage rate by a small percentage (e.g., ~5%)
   • shift the start date within the range supported by your records
   • compare how much the “covered period” backpay changes

   This tells you whether your result is more rate-driven or date-window-driven, so you know where to focus verification effort.

Related reading

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