How to run Wage Backpay in DocketMath for United States (Federal)

6 min read

Published April 15, 2026 • By DocketMath Team

Step-by-step

Run this scenario in DocketMath using the Wage Backpay calculator.

You can run Wage Backpay in DocketMath for United States (Federal) by using the Wage Backpay calculator with jurisdiction-aware rules set to US-FED. The goal is to translate your wage facts (rates, hours, dates, and any damages/benefit options available in the tool) into a backpay range you can clearly document.

Note: This walkthrough explains how to use DocketMath’s calculator. It’s not legal advice, and it can’t capture every fact pattern or evidentiary detail that may affect what backpay is available in a real dispute.

1) Open the Wage Backpay calculator

  1. Go to the primary CTA: /tools/wage-backpay
  2. Confirm you’re on the Wage Backpay calculator (not a general damages calculator).

2) Set jurisdiction to United States (Federal)

  1. In the jurisdiction selector, choose United States (Federal) (US-FED).
  2. Keep the tool’s jurisdiction setting consistent for the whole run—changing jurisdiction midstream can change the assumptions the calculator uses for rules and framing.

3) Enter the backpay period (dates)

DocketMath needs a defined time window to compute the number of days/workweeks used in the wage model.

  • Provide a start date and an end date for the backpay period you want to model.
  • If you’re comparing different phases (for example, before mitigation vs. after mitigation, or different employment status periods), run separate calculations for each period rather than mixing facts in one run.

Output impact: Changing the date range changes:

  • the total days/workweeks included
  • whether and how the tool applies any earnings offset window logic
  • the baseline “would have earned” figure before any offsets

4) Add the wage rate(s) and expected hours

Backpay is typically grounded in what the worker should have earned during the period.

In DocketMath, enter:

  • Expected wage rate (use the input format the tool provides—often an hourly wage)
  • Expected hours per week (or the weekly/normalized hours equivalent used by the tool)

If your scenario has different wage rates across time, use separate runs per rate segment (for example, “rate A period” and “rate B period”) and then compare totals across runs rather than blending rates in a single input set.

Output impact: Higher expected hours and higher expected wage rate increase the baseline “would have earned” number, which then drives the computed final backpay (after any offsets the tool models).

5) Enter actual earnings (offsets) and mitigation assumptions

Next, specify what the employee actually earned during the same period so DocketMath can model wage offsets.

Common inputs in wage-backpay calculators include:

  • Actual earnings (often the hourly wage and hours, or weekly/total earnings depending on the tool UI)
  • Whether you want DocketMath to apply an earnings offset approach for the backpay window

If you have partial weeks, you can still model the scenario using the tool’s weekly inputs—just make sure your date range stays accurate and consistent with how you entered those weekly values.

Output impact:

  • If actual earnings are lower than expected earnings, computed backpay generally increases.
  • If actual earnings are equal to or higher than the expected level (based on the tool’s assumptions), computed backpay can decrease toward zero.

6) Choose wage/benefit options in the tool (if offered)

Some wage backpay models include options such as:

  • wage-only vs. wage plus benefits
  • inclusion of particular compensation components (depending on the tool’s design)

Select the option that best matches what you’re documenting. If you’re unsure, start with wage-only to keep the scenario transparent, then create a second run that includes benefits (if supported) and compare results.

Output impact: Adding benefits usually increases totals, but the magnitude depends on the tool’s benefit parameters and the values you input.

7) Review the output breakdown (don’t just copy the total)

After you compute, review the breakdown lines the calculator provides, such as:

  • Expected earnings
  • Actual earnings (or the offset inputs/derived values)
  • Calculated backpay amount
  • any additional line items or scenario flags included by the tool

When documenting results, include the date inputs and wage assumptions you entered. DocketMath outputs are most helpful when you can point to which inputs produced which lines in the breakdown.

8) Run scenarios and capture differences

For a practical workflow, run at least:

  • Baseline scenario: simplest setup the tool supports (for example, wage-only, or the offset configuration you intend to compare against)
  • Earnings/mitigation scenario: with the actual earnings entered so offsets are applied
  • Boundary scenario (sensitivity check): adjust the end date slightly (for example, one workweek earlier/later) to test how sensitive the total is to the period boundary

Output impact: Scenario comparisons help you identify which assumptions move the number the most—commonly hours, wage rate, and the actual earnings inputs used for offsets.

Common pitfalls

Backpay calculations are sensitive to input errors. Use this checklist before trusting results.

Pitfall: A small date error—such as a start date a week too early—can materially change totals when the calculator converts dates into workweeks and applies the wage rate across the expanded interval.

Try it

  1. Open Wage Backpay in DocketMath: /tools/wage-backpay
  2. Set Jurisdiction: United States (Federal) (US-FED).
  3. Enter:
    • start date and end date
    • expected wage rate and expected hours per week
    • actual earnings (so the tool can model offsets)
  4. Compute and review the breakdown lines:
    • expected earnings
    • actual earnings / offsets
    • calculated backpay
  5. Run one additional scenario:
    • keep everything the same, but adjust the end date by one workweek to see how sensitive the total is to the period boundary.
  6. Save/export the scenario details (if the interface supports it) so you can compare runs side-by-side.

Tip: If you’re building a calculation narrative, start with the simplest model first (for example, wage-only). Then run the more complete model (for example, wage plus benefits if supported) and compare the delta between totals.

Related reading