Spreadsheet checks before running Wage Backpay in Maryland

What the checker catches

Run this scenario in DocketMath using the Wage Backpay calculator.

Before you run Wage Backpay in Maryland with DocketMath, run a quick spreadsheet check. This step prevents the most common data issues that can quietly distort backpay calculations and case timelines.

DocketMath’s wage-backpay checker is designed to validate core assumptions that typically drive your spreadsheet outputs—especially around the statute of limitations (SOL).

Maryland SOL baseline the checker uses (general/default)

Maryland’s general limitations period for most civil claims is 3 years under Md. Code, Cts. & Jud. Proc. § 5-106 (the “general/default period” noted in the jurisdiction data).

No claim-type-specific sub-rule was found here, so the checker applies this general period as the default.

Common spreadsheet problems the checker flags

Use the checklist below as you review your spreadsheet before running DocketMath:

• Date-field errors

  • Start date after end date
  • Missing “work performed” dates
  • Inconsistent formatting (e.g., MM/DD/YYYY mixed with YYYY-MM-DD)

• Lookback window mismatch

  • Your “covered wages” range doesn’t align to a 3-year SOL lookback window under Md. Code, Cts. & Jud. Proc. § 5-106

• Pay-rate inconsistencies

  • Hourly rate is blank, zero, or entered as weekly salary by error
  • Rate changes mid-stream but the spreadsheet doesn’t segment by effective date

• Hours misalignment

  • Hours recorded as negative numbers
  • Mixed units (e.g., some rows in minutes, others in hours)

• Pay frequency drift

  • Pay period length (weekly/biweekly/semimonthly) doesn’t match how you computed totals

• Aggregation and rounding

  • Totals don’t reconcile with line items
  • Over-aggressive rounding applied per row instead of after summing

How the checker affects outputs

When the checker detects a problem, the downstream Wage Backpay output typically changes in one or more ways:

• Covered period shrinks or shifts if your “earliest date” falls outside the 3-year window.
• Backpay total decreases if rows are excluded due to date-window issues.
• Line-item totals change when hours/rates are corrected or normalized.
• Discrepancies appear when the checker forces reconciliation between row totals and summary totals.

If you want a quick sanity check, compare:

• total hours × hourly rate (by segment) vs.
• your computed backpay column,

and verify they agree within your expected rounding tolerance.

When to run it

Run the spreadsheet checker before you run DocketMath’s Wage Backpay calculation, and also at two other high-risk moments.

Run the checker before importing a spreadsheet into the Wage Backpay workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

Best time: right before you calculate

Use this sequence:

1. Clean and standardize dates in your spreadsheet
2. Confirm rate and hours units per row
3. Run the checker (DocketMath’s wage-backpay worksheet validation)
4. Recalculate only after the checker passes

This order matters because SOL filtering and row selection depend on accurate dates.

Also run it after changes

Re-run the checker whenever you modify any of the following:

• the start date of the wage period you’re using
• the trigger date you’re using for the lookback analysis (commonly the filing date or another date defined by your workflow)
• pay-rate data or segmentation rules
• hours entry method (manual vs. imported from payroll)

Maryland-specific timing logic (general/default SOL)

Because the checker is built around the general 3-year period in Md. Code, Cts. & Jud. Proc. § 5-106, the core timing gate is:

• any work performed outside the 3-year lookback window is not included in the covered calculation range, under the checker’s default rules.

Try the checker

You can run DocketMath’s Wage Backpay flow directly here: /tools/wage-backpay.

If you’re building your worksheet, here are the input categories to verify first—then watch how outputs change after the checker runs.

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Spreadsheet inputs to standardize (Maryland)

• Work performed date (per row): required for SOL filtering under the general/default 3-year rule
• Hours worked (per row): keep consistent units (hours, not minutes)
• Pay rate (per row): hourly rate or the unit rate you use consistently
• Rate-change segmentation: if rates vary, split into separate rows/segments by effective dates

Output checks after running

Once you run the tool, confirm three things:

• Covered period boundaries
  Does the earliest included date align with the 3-year window derived from Md. Code, Cts. & Jud. Proc. § 5-106 (general/default)?

• Row inclusion/exclusion
  Are you seeing exclusions only where dates truly fall outside the lookback window?

• Totals reconciliation
  Do the totals roughly match sum-of-lines logic before and after validation?

If you want a quick cross-check before launching, verify each segment:

• segment backpay ≈ (hours, in consistent units) × (rate)
• then compare your sheet’s segment totals to the tool’s covered totals

(These are math consistency checks, not legal conclusions. If you’re unsure about a timing rule for a specific claim type, consider getting qualified legal guidance.)

Related reading

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