Why attorney fee calculations results differ in Vermont

The top 5 reasons results differ

Run this scenario in DocketMath using the Attorney Fee calculator.

If you’re seeing mismatched attorney-fee numbers in Vermont using DocketMath (tool: /tools/attorney-fee), the discrepancy is usually caused by input differences rather than “mysterious math.” In this diagnostic, Vermont’s general/default statute of limitations (SOL) period is 1 year. Also, no claim-type-specific sub-rule was found in the provided jurisdiction data—so for SOL-based gating in this diagnostic, you should start from the general 1-year baseline unless you’re applying a different, claim-specific rule elsewhere.

Here are the five most common causes of different results:

1. **Date mismatch (service, filing, judgment, or last work)

   • Attorney-fee models often compute a time window from a specific “start” date.
   • If one run uses a different trigger (or end) date, the “included time” can shift—and any time-based multipliers will shift too.

2. **Rate model mismatch (hourly rate vs. blended vs. updated rate)

   • One calculation may use the lawyer’s current hourly rate, while another uses a historic rate or a blended schedule.
   • Even a small rate difference can compound across the total included hours.

3. Time entry filtering differences

   • Many fee calculations exclude certain entries (e.g., administrative time, clerical tasks, duplicates, or time outside the assumed scope).
   • Two runs may look identical at the surface, but if they include/exclude different time categories, totals will diverge.

4. Partial-claim / partial-success allocation

   • Some methods apply an “allocation” concept (fees tied to successful claims vs. total claims).
   • If one run assumes full recovery and another uses a success ratio (or only selected claims), the fee outcome can change materially.

5. **Discounting or normalization (rounding and unit conversions)

   • DocketMath calculations may normalize time (e.g., rounding minutes to billable increments like 0.1, 0.25, or 1/6 hour).
   • Small rounding differences can become surprisingly large when multiplied by many time entries.

Quick SOL reminder for Vermont in this diagnostic: use the general/default 1-year SOL period, because no claim-type-specific sub-rule was identified in the provided jurisdiction data. If your situation truly requires a claim-specific SOL rule, that could explain differences that this diagnostic won’t resolve by itself.

How to isolate the variable

Use this practical “single-variable” approach to identify the driver quickly—without changing multiple assumptions at once.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

Step 1: Lock the SOL gate dates

• Identify the date your fee run treats as the trigger (common examples: claim accrual, or a procedural milestone).
• Confirm both runs use:

  • the same trigger date
  • the same end date (or the same lookback assumption)
  • the same SOL baseline
• For this Vermont diagnostic, the SOL baseline is 1 year (general/default), with no claim-type-specific sub-rule found in the provided jurisdiction data.

Checklist:

Step 2: Compare rate assumptions line-by-line

Create a quick comparison table for every rate-related input:

Step 3: Reconcile included time entries

If the inputs include hours/minutes, reconcile these items between runs:

Tip: If you can export or list included time entries, do a count comparison first (entries included vs. excluded), then compare aggregated totals.

Step 4: Check allocation / success ratio

If allocation is applied, make sure both runs match on:

Step 5: Run a “minimal test” case

To isolate, keep everything the same except one variable at a time:

• Example 1: keep rate identical; change only the time window
• Example 2: keep time identical; change only the rate

When the results line up after one change, you’ve found the likely cause.

Pitfall: If you change more than one input between runs (even unintentionally, like updating a rate effective date), you may misidentify the root driver.

Next steps

1. Re-run using DocketMath with harmonized inputs

   • Use /tools/attorney-fee to mirror the other run’s assumptions.
   • Aim for the same date trigger, rate model, and time filtering rules.

2. Write down the exact input deltas

   • Keep a short “delta log,” such as:

     • Date trigger: ___ → ___
     • Rate model: hourly → blended (or vice versa)
     • Allocation: applied (Y/N); success ratio: ___
     • Rounding increment: ___ → ___

3. Confirm the SOL baseline being used

   • For this diagnostic, use Vermont’s general 1-year SOL period and note that no claim-type-specific sub-rule was found in the provided jurisdiction data.
   • If your workflow uses a claim-specific SOL elsewhere, that can explain remaining mismatches.

4. If mismatch persists, compare the computation steps

   • Focus on where outputs can be transformed:

     • minutes → billable hours conversion
     • filtering decisions
     • allocation ratios
     • any multipliers or normalization logic

For the jurisdiction data reference supporting the general SOL period used in this diagnostic, see:
https://legislature.vermont.gov/Documents/2020/Docs/CALENDAR/hc200226.pdf

If you want to test side-by-side, start from /tools/attorney-fee.

Related reading

• Attorney Fees Guide for Alaska
• Attorney Fees Guide for American Samoa
• Attorney Fees Guide for Arkansas