Why attorney fee calculations results differ in New York

The top 5 reasons results differ

If your DocketMath attorney-fee calculations don’t match what you (or another party) got in New York, the mismatch is usually traceable to a small number of input/assumption differences. Even when two numbers are “based on the same case,” they can diverge if they don’t apply the same definitions for what counts as hours, rates, expenses, and which time period is eligible.

A key timing anchor is the general/default statute of limitations (SOL) concept. N.Y. Criminal Procedure Law § 30.10(2)(c) provides a general/default 5-year period (and this note does not identify any claim-type-specific sub-rule). Treat this as the baseline framework when SOL filtering is part of your calculation, but recognize that the way the SOL window is implemented can still differ between calculations.

Here are the top 5 reasons your results may differ:

1. Rate vs. total fee confusion

   • Some workflows enter rate as “$/hour,” while others accidentally enter a total that already reflects hours worked.
   • Example input drift: entering $400/hour into a field that is meant to capture $40,000 total (or vice versa).
   • Result: outputs can be off by a factor equal to the hours (or by the inverse), even if the rest of the inputs match.

2. **Hours included (or excluded)

   • Two calculations can use the same hourly rate but diverge because one includes a different set of time entries or categories, such as:

     • research hours included vs. excluded
     • attorney time vs. paralegal time
     • billed vs. written-off hours
   • Result: the “hours” input boundary is often the real cause—not the arithmetic.

3. Different fee components

   • Tools and spreadsheets may break “fees” into multiple components, for example:

     • attorney labor
     • expenses/costs
     • court-awarded components vs. invoiced amounts
   • If one comparison number includes costs inside “fees” and the other lists costs separately (or excludes them), totals will diverge even when labor hours are identical.

4. **Start/end date treatment (including partial periods)

   • Even if the same hours were claimed, mismatched date handling can change which days/time entries are included under any time-based logic.
   • Small date shifts—like May 1 vs. May 15—can change which time entries fall into the calculation window.

5. Statute-of-limitations filtering

   • If SOL logic is applied to decide which invoices/tasks/periods are “countable,” the result can swing dramatically.
   • Under the general framework above, the baseline SOL is 5 years (from N.Y. Crim. Proc. Law § 30.10(2)(c), general/default period).
   • However, two calculations can still differ if they filter based on different event dates, such as:

     • invoice date vs. work-performed date
     • payment date vs. filing date
   • Result: the same claimed work may be included in one calculation window but excluded in another.

Gentle reminder: this is a practical diagnostic, not legal advice. If you need legal guidance on SOL application to a specific fee claim, consult a qualified attorney.

How to isolate the variable

Treat DocketMath like a controlled experiment. Your goal is to change one variable at a time and see whether the output moves in the way you expect.

Use this checklist:

• Match the hourly rate fields

  • Confirm you entered a rate (e.g., $350/hour) rather than a total.
  • If multiple timekeepers exist, ensure each rate maps to the correct role/category.

• Normalize hour inputs

  • Compare the hours-by-category in your source material to the categories DocketMath uses.
  • Watch for common boundary issues:

    • “0.0” entries that were excluded
    • rounded hours (e.g., 1.5 vs. 1.49)
    • timekeeper role swaps (attorney vs. paralegal)

• Reconcile cost/expense inclusion

  • Decide whether your comparison number includes expenses.
  • Then toggle the corresponding inputs (labor vs. expenses/costs) and see whether the output shifts by roughly the expected amount attributable to expenses.

• Align date logic

  • Verify all relevant dates, such as:

    • first billed date
    • last billed date
    • any effective cutoffs used by the other calculation
  • If the other side uses a “billing-period” boundary, replicate the same period boundaries in your inputs.

• Apply the same SOL window logic

  • Use the baseline 5-year SOL framework (general/default) tied to N.Y. Crim. Proc. Law § 30.10(2)(c).
  • Then confirm the event date rule matches between calculations:

    • Is the SOL check based on invoice date or work performed date?
    • Is it based on payment date or another event?

If you want the fastest path: enter the same inputs into DocketMath and compare outputs using the breakdown. Start here: /tools/attorney-fee.

Next steps

Once you isolate the variable, you can correct the mismatch without starting over.

1. Document the delta

   • Write down which input change moved the total and by how much.
   • Example: “Changing the date cutoff from 2021-08-01 to 2021-08-15 changed the total by $2,410.”

2. Lock input conventions

   • Use one consistent definition across all sources:

     • what “hours” means (billed vs. net)
     • whether costs/expenses are included in “fees”
     • how date boundaries are handled

3. Run a “micro test”

   • Test with a tiny dataset (e.g., one entry):

     • 2.0 hours at $300/hour → confirm you get $600 for labor before applying expenses and SOL filtering.

4. Re-run with SOL alignment

   • Confirm the same 5-year baseline framework is applied and that the same event-date rule is used.
   • Even with the same baseline SOL, mismatched filtering can still produce different totals.

Related reading

• Worked example: attorney fee calculations in Vermont — Worked example with real statute citations
• Attorney Fees Guide for Alaska
• Attorney Fees Guide for American Samoa