Spreadsheet checks before running Wage Backpay in New York

5 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Before you run a Wage Backpay calculation in DocketMath (US-NY), use the Spreadsheet checker to verify that your spreadsheet won’t quietly sabotage the math. In New York, wage backpay workflows often hinge on timing—especially the statute of limitations (SOL) logic that determines whether older compensation is included.

This New York checker is designed to catch spreadsheet issues that lead to incorrect SOL filtering. It applies a default/general 5-year period because no claim-type-specific sub-rule was found in the provided jurisdiction data. In other words: the checker follows the general rule unless your workflow confirms a different, more specific limitations rule.

New York SOL anchor (for timing filters)

Note: The checker uses the general/default 5-year SOL because no claim-type-specific sub-rule was identified in the provided jurisdiction data. If your matter involves a different, more specific limitations rule, validate whether that applies before relying on the spreadsheet output.

Spreadsheet problems the checker flags

Use the checker to validate common failure points that cause SOL logic errors:

  • Date field integrity

    • Blank “start date” or “end date”
    • Dates stored as text (e.g., 01/05/2025 typed inconsistently)
    • Mixed formats (e.g., 2025-01-05 in one column, 01/05/25 in another)
  • Off-by-one and boundary errors

    • Treating the cutoff day incorrectly (including/excluding a day due to time-of-day or midnight handling)
    • Using “calendar years” instead of an exact 5-year lookback
  • Wrong “trigger” date

    • Solving against the wrong reference date (e.g., using hire date instead of termination/notice date, depending on your workflow)
    • Using multiple candidate dates without a clear selection rule in the spreadsheet
  • Row-level inconsistency

    • Hours/pay periods shifted across rows while the SOL filter is applied using only one global date
    • Retro pay lines missing pay-period coverage dates
  • Aggregation mistakes

    • Summing gross amounts but filtering based on net/withholding dates
    • Double-counting overlapping pay periods

Quick “expected output” behavior

When the checker is working properly for US-NY:

  • It applies a 5-year lookback window (general/default SOL period) to the wage backpay line items.
  • Output totals change immediately when you:
    • adjust the trigger/cutoff date, or
    • correct pay-period dates that were previously misread or misformatted.

To keep your spreadsheet auditable, the checker should produce a clear before/after effect: older lines drop out once they fall outside the 5-year window, and recent lines remain.

(Gentle disclaimer: this is a spreadsheet-validation and workflow-checking step—not legal advice.)

When to run it

Run the checker before you press “calculate” in the Wage Backpay workflow—and again after any data edits that touch dates, time periods, or pay-line structure.

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 moments in the workflow

  • After importing or copying pay-period data
    • Especially if you pulled data from payroll exports, PDFs, or another workbook.
  • Before you change any cutoff/trigger date
    • If you update the date that controls the SOL window, re-check.
  • Whenever you see a “suspiciously round” total
    • For example, a total that looks like an unfiltered sum of all periods.
  • After reconciling overlaps
    • If you merge retro periods or adjust coverage dates, validate the row-level date logic.

Inputs to treat as “high risk”

Checkboxes help teams standardize who checks what:

Output checks you can perform quickly

After running DocketMath’s spreadsheet checker:

  • Compare totals:
    • Unfiltered total vs filtered SOL total
  • Validate boundary periods:
    • Pay periods that sit near the 5-year cutoff should be the most sensitive to errors.
  • Spot-check 3–5 rows:
    • One clearly inside the 5-year window
    • One clearly outside
    • One near the cutoff date (most likely to fail due to formatting or time handling)

Try the checker

To see the SOL-window logic for New York (US-NY) applied consistently, start in DocketMath and run the Wage Backpay tool from the primary CTA.

Here’s a practical way to test the spreadsheet checker without guessing:

  1. Pick a known set of pay periods
    • Include at least one pay period that should clearly fall outside 5 years and one that should clearly fall inside.
  2. Run the checker
    • Fix any flagged issues (date parsing, missing dates, inconsistent coverage).
  3. Adjust only one variable
    • For example, move the trigger/cutoff date by 30 days.
  4. Observe what changes
    • Correct behavior: some older rows move from included → excluded (or vice versa).
    • Incorrect behavior: the total stays unchanged after date edits, or many mid-range rows flip unexpectedly (often a sign of date-type problems).

Warning: Spreadsheet systems sometimes store dates as text, especially after copy/paste from exports. The checker helps prevent false SOL inclusion/exclusion caused by “string dates” that don’t sort or compare correctly.

For jurisdiction-aware operation, the checker uses the general/default 5-year SOL (as reflected in the provided jurisdiction data and anchored to N.Y. Crim. Proc. Law § 30.10(2)(c)). If your workflow relies on a more specific limitations rule than what’s reflected here, ensure your internal logic aligns before finalizing totals.

Related reading