Common Wage Backpay mistakes in Maryland

The top mistakes

Run this scenario in DocketMath using the Wage Backpay calculator.

When people calculate or pursue wage backpay in Maryland using DocketMath, the most common errors tend to fall into repeatable buckets: picking the wrong start date, applying the wrong lookback window, mixing up what’s “due” versus what was “paid,” and entering wage components inconsistently.

Below are the mistakes we see most often in Maryland (US-MD), using the general/default statute of limitations (SOL) period.

Note (Maryland SOL baseline): Maryland’s general SOL for civil actions is 3 years under Md. Code, Cts. & Jud. Proc. § 5-106. The jurisdiction data you provided is the default general period; no claim-type-specific sub-rule was found, so treat 3 years as the default lookback for wage backpay calculations unless your exact claim theory uses a different, statute-specific rule.

1) Backpay “start date” set to the wrong event

A frequent problem is starting the clock on the wrong date—such as:

• using the date someone noticed the missing wages rather than the first pay period when wages were due,
• using the date of an internal complaint rather than the first missed/underpaid pay period,
• using the termination date even though the underpayment began earlier.

Why it breaks the math: Your backpay total is driven by which pay periods fall within the lookback window and by the amounts due in those pay periods.

2) Ignoring the 3-year lookback window (Md. Code, Cts. & Jud. Proc. § 5-106)

Another common error is calculating backpay for more than 3 years by default—especially when someone:

• uses the employment start date as the earliest “backpay start,” or
• manually counts all missing periods back to the earliest paperwork, without filtering to the SOL window.

Correct jurisdiction-aware default approach:

• In Maryland, use 3 years as the general/default SOL lookback window under Md. Code, Cts. & Jud. Proc. § 5-106.
• If your earliest wage shortfall is older than that window, those older periods may not be recoverable in a civil action under the general SOL.

3) Treating wages as one flat number even though pay changes by period

Backpay is rarely a single fixed figure. People often enter one hourly rate (or one salary number) without accounting for:

• different rates after raises,
• shift differentials,
• scheduled hours that change week to week,
• overtime that depends on weekly/pay-period rules.

Result: DocketMath output can be directionally off because it’s sensitive to the wage delta for each pay period, not just the average rate.

4) Under-inputting or double-counting wage components

Two opposite but related input errors show up frequently:

• Under-input: entering only base hourly wages and forgetting additional compensable items (where applicable to your facts).
• Double-count: adding an adjustment twice—for example, including regular wages and also entering a total that already includes them.

Practical takeaway: Enter wage components consistently and only for the period they apply to.

5) Using payment dates instead of “wages due” dates

Even with good payroll records, it’s easy to enter:

• the date money was paid (remittance date),
• instead of the period when wages were earned/due.

Why it matters: Two workers can have the same payroll totals, but the “due” timing determines which periods land inside/outside the 3-year default window and how the per-period wage differences are computed.

6) Leaving assumptions undocumented (hard to defend later)

Backpay numbers often get challenged because the inputs aren’t explainable. Common gaps include:

• which pay periods were included/excluded,
• whether partial-pay periods were prorated,
• how estimated hours were derived.

DocketMath can compute totals, but an audit trail still matters for internal consistency and for explaining how the total was built.

How to avoid them

To keep your DocketMath workflow practical and Maryland-specific (US-MD), use a structured checklist and a few targeted sanity checks.

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-by-step checklist (practical workflow)

Inputs that usually change the output the most

Small input changes can swing calculated totals noticeably. Focus on:

A quick sanity check before finalizing your calculation

Run these checks in order:

1. Count pay periods inside the 3-year window (default): Ensure your earliest included period is within the last 3 years under the general SOL.
2. Compare totals to payroll deltas: Your total “missing” amount should track with reasonable payroll differences (avoid large, unexplained leaps).
3. Look for step changes: If the computed amount jumps sharply after a month, confirm there was a documented rate/schedule change and that dates were mapped to the correct wage periods.
4. Reconcile one pay period manually: Pick a single period with complete records and verify DocketMath matches a hand calculation for that period.

Gentle reminder: This content is for practical calculation guidance, not legal advice. If your situation may involve a different SOL rule than the general default, consider getting advice from a qualified professional.

Related reading

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