Common attorney fee calculations mistakes in New York

5 min read

Published April 15, 2026 • By DocketMath Team

The top mistakes

Run this scenario in DocketMath using the Attorney Fee calculator.

Running attorney-fee calculations in New York is easy to get wrong because the arithmetic is only one part of the work. The other part is making sure your inputs reflect the governing legal framework and the contract or court order you’re applying. Below are the most frequent mistakes we see when people use DocketMath (or do manual calculations) for New York attorney-fee scenarios.

  1. **Using the wrong assumptions about the lookback window (statute of limitations)

    • Many fee models either:
      • assume a longer period by default, or
      • apply a “claim-type-specific” limitation period without checking whether the scenario actually has that special rule.
    • New York’s general/default statute of limitations for criminal-process-related attorney-fee concepts is 5 years, tied to N.Y. Crim. Proc. Law § 30.10(2)(c). Source: https://www.nysenate.gov/legislation/laws/CPL/30.10
    • Important modeling rule: if you don’t find a claim-type-specific sub-rule applicable to your specific fee theory, your calculation should use the general 5-year default period as the starting point (don’t “invent” a narrower or longer window).

    Note: In many fee worksheets, the limitation period is what separates a correct total from a wildly overstated one. When there’s no specific sub-rule identified, start from the general/default 5-year period.

  2. Misaligning “time worked” to “time billed”

    • Fee worksheets frequently separate:
      • hours worked,
      • hours billed,
      • and hours allowed (i.e., what is actually compensable under the governing order/contract).
    • A common error is using billed hours as allowed hours without adjusting for any reductions, disallowance, or directional limits in the order/contract.
    • In DocketMath terms, this often shows up when inputs reflect activity but not the compensable set (your totals look plausible, but the “allowed” basis doesn’t match the legal requirement).
  3. **Double-counting phases (e.g., filing + briefing)

    • Teams often copy/paste time entries by phase, then also include a “total hours” rollup that already includes those same entries.
    • Typical symptom: totals are exactly (or another clean multiple) of what you’d expect from the raw line items.
  4. Forgetting minimum date boundaries

    • If the limitation period starts on a specific trigger date, fee entries before that date should be excluded.
    • error pattern:
      • building a list of entries,
      • then applying a limitation window to only some components (e.g., “work”),
      • while leaving other components (e.g., costs, certain multipliers, or interest-related components) unfiltered.
    • If the limitation window applies to the compensable claim as a whole, it should generally be applied consistently to each eligible category the governing source treats as part of the compensable basis.
  5. Incorrectly handling partial months or prorations

    • Some models convert dates into “month buckets” and round up partial months.
    • That can inflate results if the governing framework expects day-level eligibility.
    • A safer approach in most workflows is: filter by exact dates (day-level inclusion/exclusion). Only use month-bucketing or prorations if your governing document explicitly supports that methodology.
  6. Mixing currency assumptions or rate tiers without a rule

    • Hourly-rate models break when someone:
      • blends multiple rates into one average without documenting why, or
      • applies a uniform rate to time that should have different rates by date range, attorney level, or segment.
    • With DocketMath, this typically means the rate logic is not mapped to the time entries being multiplied (e.g., each line item should use the rate tier associated with its date/attorney/segment, but the model uses one blended rate for everything).
  7. Ignoring statutory anchors in template-driven workflows

    • Fee tools can look “purely computational,” but the inputs still have to map to legal concepts like eligibility windows and compensable categories.
    • If your workflow includes a limitation date, anchor it to the governing period.
    • For New York in this context, don’t treat the limitation window as optional when it directly affects inclusion/exclusion. Use the general 5-year default (unless you have a clearly applicable claim-type-specific rule).

How to avoid them

You can reduce errors fast by building a calculation pipeline that is both arithmetic-correct and rule-aligned. Here’s a practical checklist you can use before you finalize totals in DocketMath.

  1. **Lock the limitation window first (then filter)

    • Confirm you have the correct starting point and duration.
    • For the general/default approach in New York, use the general 5-year period found in N.Y. Crim. Proc. Law § 30.10(2)(c): https://www.nysenate.gov/legislation/laws/CPL/30.10
    • Use the limitation window to filter which entries are eligible before calculating totals.

    Checklist:

  2. Treat “allowed hours” as a first-class input Instead of one raw “hours” number, separate:

    • hours logged,
    • hours compensable/allowed (after reductions or order-directed limits),
    • and hours actually multiplied by your rate.

    Modeling approach:

  3. Prevent double-counting with a single source of truth Pick one:

    • either phase totals, or
    • the individual line entries, but not both.

    Recommended method:

  4. Avoid month-bucketing and rounding unless required Use exact dates for eligibility filtering:

  5. **Keep rate logic explicit (no “mystery averages”) If rates change:

  6. Validate outputs against sanity checks Before accepting final numbers:

    A quick sanity-check table:

    CheckWhat to computeWhat you’re looking for
    HoursIncluded line-item hours sumMatches DocketMath “included hours”
    Date filterOldest included dateIs within 5 years of the trigger date
    Rate mappingAvg rate by bandReflects your rate-tier logic
    DuplicationPhase totals vs line totalsNo clean multiples that suggest duplication

Caution (non-legal advice): A calculation can be mathematically correct yet still be wrong if it includes entries outside the governing eligibility window. Filter eligible time first, then compute totals.

If you want a fast starting point for your own workflow, use DocketMath here: /tools/attorney-fee.

Related reading