Spreadsheet checks before running attorney fee calculations in New York

6 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Run this scenario in DocketMath using the Attorney Fee calculator.

Before you run attorney-fee calculations in New York with DocketMath’s attorney-fee tool, you want your spreadsheet to survive basic “data integrity” stress tests. Attorney-fee models often combine invoice-level inputs, timekeeping rates, task categories, and reductions (for example, disallowed hours). A single mis-specified cell can silently create a large (or oddly small) error that still looks mathematically clean.

DocketMath’s attorney-fee workflow is strongest when your spreadsheet is internally consistent—meaning the spreadsheet’s totals can be explained from the rows beneath them, and date scoping behaves the way you intended. The checklist below is designed for New York work where the relevant legal baseline you might be using includes N.Y. Crim. Proc. Law § 30.10(2)(c), and where the general/default statute of limitations is 5 years. Importantly, no claim-type-specific sub-rule was found in the provided jurisdiction data—so treat 5 years as the default baseline (and don’t branch by claim type) unless you have additional, independently sourced authority.

Here are the most common problems the “spreadsheet checker” catches in practice:

  • Date logic errors
    • Start date after end date (often caused by copy/paste or sorting)
    • Inconsistent date formatting (e.g., some cells are real dates and others are text)
    • Wrong date field used (for example, using settlement date where service/invoice date was intended)
  • Hours math mismatches
    • “Total hours” doesn’t equal the sum of line-item hours
    • Negative hours entered to represent reversals (and not handled downstream)
    • Units swapped (minutes treated as hours, or hours treated as minutes)
  • Rate and blended-rate inconsistencies
    • Multiple rate columns exist, but the total formula references only one
    • Overtime or associate/senior rates applied to the wrong rows
    • Mixed definitions (e.g., “rate” meaning hourly vs. “rate” meaning already-adjusted)
  • Reduction or exclusion rules broken
    • Disallowed hours/reductions are present but not wired into the final computation
    • Reductions applied twice (for instance, both in a “net hours” step and again in a “net fee” step)
    • Reductions exceeding line totals due to sign errors
  • Category mapping failures
    • Task/category labels don’t map to the intended inclusion or exclusion rules
    • Typos in category names cause silent fallbacks (sometimes defaulting to zero or to the wrong category)
    • Blank categories that bypass mapping rules
  • Rounding and formatting traps
    • Currency rounding applied early (line-by-line) instead of keeping full precision through intermediate steps
    • Values stored as text (e.g., "$250.00" stored as text), leading to partial recalculation or string concatenation
    • Mixed decimal separators (common when copying from different locales)

Pitfall to watch: A spreadsheet can be numerically consistent while still being legally wrong—most often because the date coverage (and therefore eligibility scope) is wrong. That’s why your checker should validate date-window behavior and reconcilability from the row-level inputs, not just the final totals.

When to run it

Run the checker in three moments: (1) before you calculate, (2) after you import, and (3) after you apply legal filters (like a time-window selection).

Run the checker before importing a spreadsheet into the Attorney Fee workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

1) Before you calculate (baseline integrity)

Do this when the sheet is first created or edited. The goal is to catch structural issues early:

  • Every row has an invoice date (or service date—whatever your model uses)
  • Every row has numeric hours and numeric rate
  • Totals reconcile to sums
  • Category fields required for mapping are not blank

2) Immediately after importing or pasting data

If you’re bringing data from billing software, PDFs, or exports:

  • Re-validate that date columns stayed dates, not text
  • Confirm decimals and currency fields kept numeric formatting
  • Check that any “paid to date” / “adjusted totals” columns didn’t overwrite raw totals used by your model

3) After you apply any time-window filter tied to New York timelines

Even if your fee formula is purely arithmetic, the scope of eligible work often depends on a timing baseline. With the provided jurisdiction data, the general/default statute of limitations is 5 years. And again: no claim-type-specific sub-rule was found, so use 5 years as the default baseline unless you have other verifiable, sourced rules.

When you apply that filter:

  • Confirm the filter logic uses the correct date column (service date vs. invoice date)
  • Verify how boundary dates are handled consistently (inclusive vs. exclusive)
  • Ensure excluded rows don’t still contribute via a hidden reference (for example, a “net hours” calculation still referencing unfiltered rows)

Warning: If your spreadsheet uses a “default lookback start date” but your model never updates that date when you change the filing/benchmark date, totals can look “right” for the prior run while being wrong for the current one.

Try the checker

You can sanity-check your spreadsheet before running the full attorney-fee logic using DocketMath’s attorney-fee tool here: /tools/attorney-fee.

A practical approach is a “known reconciliation” pass first. Even without making legal conclusions, you can confirm your spreadsheet wiring is correct by verifying that the computed outputs behave the way you expect when you adjust inputs.

A quick reconciliation routine (works well for fee spreadsheets)

  • Sum line-item hours → equals the sheet’s “total hours”
    • (Eligible hours × rate) − (reductions/disallowed amounts) → equals the sheet’s “net fee”
    • Only rows with dates within your intended 5-year default lookback window contribute to eligible totals
    • Every row’s category is recognized; no rows fall into an “unknown” bucket
    • Keep full precision through intermediate calculations; round only for display totals

What to watch when you change inputs

Use the tool as a feedback loop. Change one input at a time and confirm the output moves in the expected direction:

Input changeExpected output behavior
Increase hours on a single line itemNet fee increases proportionally based on that line’s net rate impact
Adjust rate for one categoryOnly rows in that category move proportionally
Toggle a reduction percentageNet fee decreases proportionally; reductions don’t exceed line totals
Move the lookback start date forward by 1 yearNet fee decreases (or stays the same) if you’re excluding older work
Change date format (paste as text)The checker should flag missing/invalid dates; otherwise totals may freeze incorrectly

If any expected behavior fails, stop before running the full model. Tools like this can only reflect what your spreadsheet actually feeds them. (This is not legal advice—just a practical data-validation workflow.)

Related reading