How to run Wage Backpay in DocketMath for Tennessee

Step-by-step

Below is a jurisdiction-aware walkthrough for running Wage Backpay in DocketMath for Tennessee (US‑TN). This guide focuses on how to use the Wage Backpay calculator correctly and how Tennessee’s lookback period affects the results.

1) Start at the Wage Backpay tool

1. Open DocketMath’s Wage Backpay calculator: **/tools/wage-backpay
2. Confirm the jurisdiction is set to Tennessee (US‑TN). If the interface asks you to choose a jurisdiction, select US‑TN.

2) Identify the “backpay through” date

DocketMath’s output depends heavily on the time window you’re measuring.

• Pick the relevant end date for your workflow (common examples: the date the wage claim is filed, the date employment ended, or another event date your case tracks).
• Record that date before you enter any numbers.

3) Use the Tennessee default lookback period (1 year)

In this Tennessee (US‑TN) setup, DocketMath uses a General SOL Period of 1 years as the default lookback window for the wage backpay calculation.

• Tennessee Code Annotated § 40‑35‑111(e)(2) is the general/default rule used here.
• No claim-type-specific sub-rule was found, so the calculator should treat the 1-year period as the default lookback window.

How this changes your results:

• If your backpay through date is later, you’ll usually get more workweeks included.
• If your backpay through date is earlier, the included wage history shrinks because the tool typically limits the covered period to the last 1 year relative to that end date.

4) Enter the wage/earnings inputs DocketMath expects

The Wage Backpay calculator computes “missed” wages during the covered window using the wage/earnings inputs you provide.

In the tool, you’ll generally enter concepts like:

• Wage baseline / what should have been paid
  Enter the wage rate(s) that represent the expected compensation (for example: an hourly rate or an equivalent weekly amount, depending on how the tool asks for inputs).
• Actual wages paid
  Enter the wages actually paid during the covered period.
• Hours / schedule (if required by the UI)
  Provide hours worked during the segments the tool uses (or totals in the exact units the tool requests).
• Pay frequency (if the tool asks)
  Choose how DocketMath should interpret the wage inputs (weekly, biweekly, etc.), if that option is present.

If you have multiple pay rates (for example, a raise during the covered period):

• If DocketMath supports segmenting by rate changes, run the calculation by rate segments.
• If it does not, follow the tool’s aggregation guidance carefully—avoid blending rates in a way that doesn’t reflect time-weighted amounts.

5) Run the calculation and review the time-window impact

After you submit inputs:

• DocketMath will calculate backpay based on the wage difference logic you entered.
• It will also apply Tennessee’s default 1-year lookback window tied to § 40‑35‑111(e)(2).

What to check in the output:

• Covered dates included (the actual window the calculator uses)
• Total backpay amount
• Any breakdown by week/pay period (if provided)

If the result feels too low or too high, the most common cause is that the calculator is applying only the last 1 year from your selected end date—not the entire employment history.

6) Adjust inputs systematically (don’t guess)

When outputs change, isolate which input drove the change. A practical way to iterate:

• Changing the end date → changes which dates fall inside the 1-year covered window.
• Changing the wage baseline → changes the “should have been paid” amount.
• Changing actual paid wages → changes the wage difference.
• Changing hours worked → changes earnings within the covered period.

Quick checklist while you iterate:

7) Export or document your run

If the workflow supports copying results or saving a summary, capture:

• the covered date range
• the wage inputs you used
• the final backpay figure

This helps you compare the calculator output to payroll records and review any revisions later.

Common pitfalls

• 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.

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

1) Assuming Tennessee allows more than 1 year by default

For Tennessee in this DocketMath workflow, the calculator uses a General SOL Period of 1 years based on § 40‑35‑111(e)(2).

Because no claim-type-specific sub-rule was found for this guide, treat 1 year as the default lookback unless you have a workflow reason (and support) to apply something different.

2) Using the wrong “through” date

Even correct wage numbers can produce incorrect totals if the date driving the covered window is off.

Common patterns:

• Using the employment end date when the tool should be measuring through a different case-relevant date (or vice versa).
• Selecting a date that shifts the covered window by months, which can materially change totals.

3) Mixing per-period and total inputs

This is a frequent driver of inflated or deflated results.

For example:

• If the tool asks for hours per week but you enter total hours for multiple weeks, the result can be dramatically incorrect.

Mitigation:

• Match your entries to the unit labels shown in DocketMath (hours per week vs. total hours, weekly wage vs. total wages, etc.).

4) Blending multiple pay rates without segmenting or weighting

Raises, changes in overtime treatment, or different roles can create step changes in the wage baseline.

If the UI doesn’t let you segment cleanly:

• be careful with how you aggregate rates and ensure the tool’s expected method matches your approach.

5) Forgetting that the 1-year window controls which hours matter

Hours outside the covered window should not affect the output—but if you enter aggregated totals without providing the date structure the tool needs, the tool may incorporate values in a way you didn’t intend.

Mitigation:

• Use the tool’s requested structure (dates/segments if supported; correct units if it uses aggregates).

Try it

Follow this “first run” approach to validate your setup for Tennessee (US‑TN):

1. Open DocketMath’s /tools/wage-backpay.
2. Confirm jurisdiction is US‑TN.
3. Enter:

   • your selected end date (the date the calculator uses to determine the lookback window)
   • your wage baseline (what was owed)
   • your actual paid wages
   • hours worked in the exact units the tool requests
4. Run the calculation.
5. Verify the tool’s covered window reflects a 1-year lookback tied to Tenn. Code Ann. § 40‑35‑111(e)(2) as the general/default rule.

Sanity check (quick iteration):

• Change the end date by 30 days and rerun.
• If the covered window changes (it should), your total backpay should also shift.
• If totals don’t move, double-check that the calculator is receiving the updated end date and that other inputs weren’t unintentionally changed.

Related reading

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