How to run Wage Backpay in DocketMath for New York

Step-by-step

This guide walks you through running Wage Backpay in DocketMath for New York (US-NY) using jurisdiction-aware rules and the calculator workflow. It’s written to be practical—think of it as a repeatable setup checklist rather than legal advice.

1) Open the Wage Backpay calculator

Go to the primary CTA: /tools/wage-backpay.

In the calculator UI, you’ll typically be asked for inputs that determine:

• the backpay period (start/end dates or a lookback duration),
• wage rate(s),
• and whether the calculation should include overtime/regular allocation assumptions (depending on the calculator options).

If you see date-based fields, set them first because those dates drive the days/weeks included.

2) Set the backpay lookback window using New York’s default SOL period

For the New York configuration used in this guide, the default period is:

• General SOL period: 5 years
• General statute cited: N.Y. Crim. Proc. Law § 30.10(2)(c)
  Source: https://www.nysenate.gov/legislation/laws/CPL/30.10

Because the provided jurisdiction data does not identify a claim-type-specific sub-rule, run DocketMath using the general/default 5-year window.

What to do in the calculator:

• Select the option that uses the jurisdiction SOL default (if available), or
• Enter the backpay start date as 5 years before the relevant “as of” date you’re using in your workflow (for example, the date you’re modeling damages through).

How outputs change when you change this input:

• Moving the start date earlier by 1 year increases the included compensation period and can materially increase total backpay.
• Moving it forward reduces the eligible period and can reduce the total by roughly proportional amounts (though pay calendars and partial periods can make it not perfectly linear).

3) Enter wage inputs in the format the calculator expects

Next, populate wage information. Common inputs include:

• Hourly wage (e.g., $18.50/hr)
• Work schedule (e.g., hours per week)
• Employment start/end dates (if the calculator derives eligible days from employment dates)
• Pay changes (if supported—some tools let you add wage tiers by date)

Practical tip: If you have multiple wage rates during the backpay period, add them in the way DocketMath supports (tiered rates or multiple segments). If you enter a single blended rate when your work history includes raises, totals can be off.

4) Choose whether to reflect overtime or “straight time” assumptions

Some wage backpay calculators include toggles for:

• Regular wage only, or
• Regular + overtime (with overtime multiplier assumptions),
• or “hours eligible for overtime.”

Because overtime is one of the fastest ways for results to diverge, confirm you’re using the same hours basis you plan to rely on downstream in filings or analysis.

Output behavior to watch:

• Turning on overtime logic can increase totals by more than your intuition if:

  • your hours frequently exceed daily/weekly thresholds, or
  • the calculator uses a different definition of overtime eligibility.

5) Confirm the calculation end point (the “as of” date)

DocketMath needs a target end date for the backpay window. That date can be:

• the filing/modeling date you’re using for the calculation snapshot, or
• the end date you’re using to define the damages period.

If the tool asks for a “through” date, use the same “through” date consistently across your models.

How outputs change:

• Extending the “through” date later adds more pay periods to the window.
• If the through date falls mid-week/month, expect partial-period calculations.

6) Review the line-item breakdown, not only the total

Once you compute, DocketMath typically returns:

• total backpay, and
• a breakdown by period and/or wage component (regular/overtime).

Before saving, verify:

• the earliest date included in the breakdown matches your 5-year default window expectation,
• the included number of weeks/days aligns with your schedule assumptions,
• and wage rate tiers match your actual wage history.

A quick cross-check:

• Multiply hours per week by weeks included and by wage rate (for regular-only assumptions),
• then compare that estimate to the calculator’s regular wage component.

If totals don’t align closely, it often indicates a date mismatch or wage-rate formatting issue.

7) Export or record your inputs for repeatability

If DocketMath provides an export (PDF/CSV/share link), capture:

• the jurisdiction setting used (US-NY),
• the computed backpay period range,
• wage inputs, and
• any overtime toggles.

This helps you re-run calculations after changing any single variable, like:

• “through” date,
• hours per week, or
• wage rate segments.

Common pitfalls

Use this checklist to avoid the most common “number surprises” when running wage backpay calculations in DocketMath.

• missing a required input
• using a stale rate or rule
• ignoring calendar or holiday adjustments
• skipping documentation of assumptions

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

Pitfall checklist (quick scan)

New York jurisdiction-specific note to keep your model consistent

For this walkthrough, the default time window uses the general 5-year SOL period based on N.Y. Crim. Proc. Law § 30.10(2)(c) from the jurisdiction dataset:

• 5 years (general/default)
• No claim-type-specific sub-rule provided in the dataset

When you document your calculation, reflect this clearly so readers don’t assume a different limitation period was applied.

Try it

Ready to compute a New York wage backpay estimate in DocketMath? Start here:

• **/tools/wage-backpay

To get a clean first run, follow this order:

1. Set the backpay start/end window to reflect the 5-year general/default period.
2. Enter hourly wage and hours per week (or your schedule inputs).
3. Confirm overtime logic settings match your intended assumptions.
4. Run the calculation and review the date range included and the regular vs. overtime breakdown.
5. Record the inputs so you can re-run after adjustments.

If you want, run two versions back-to-back:

• Version A: overtime off (regular-only)
• Version B: overtime on (regular + overtime, if supported)

That comparison quickly shows whether overtime assumptions are driving the differences, which is often the biggest factor in backpay models.

Related reading

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