Spreadsheet checks before running attorney fee calculations in Delaware

What the checker catches

Before you run an attorney-fee spreadsheet in Delaware, DocketMath recommends doing a quick sanity-check pass. Attorney-fee models often fail for spreadsheet reasons—not legal reasons—so the goal is to catch math, unit, and logic errors before they compound into a final number.

Here are the most common issues a good spreadsheet checker should detect in fee calculations:

• Time unit drift

  • What it looks like: Hours entered as “minutes” in one tab and “hours” in another.
  • What to check: Ensure every time conversion uses the same base (for example, minutes → hours via ÷ 60), and that the “unit label” and the conversion logic match across all tabs.

• Rate/amount mismatches

  • What it looks like: Billing rate pulled from the wrong worksheet (or a blended/rolled-up rate used inconsistently).
  • What to check: Confirm the worksheet that supplies the hourly rate is the one actually used in each line’s hours × rate calculation.

• Row-level arithmetic errors

  • What it looks like: A “total” column that adds when it should multiply, or multiplies the wrong column (e.g., using a corrected-hours column in one place but uncured hours in another).
  • What to check: Recompute totals for a few rows independently using the raw hours and rate, then compare against the spreadsheet’s line totals.

• Double counting or omission

  • What it looks like: The same time entries included in both “attorney time” and “paralegal time,” or accidentally filtered out during categorization.
  • What to check: Reconcile counts and sums—for example, compare the number of raw time entries to the number of entries that flow into your fee subtotals, and confirm entries are routed to exactly one category (unless your design intentionally allows overlap).

• Date-window filtering mistakes

  • What it looks like: Entries included outside the intended reporting window, or excluded when they should be included.
  • What to check: Audit the min/max dates in the underlying dataset and confirm your filter logic’s inclusion behavior is consistent (inclusive vs. exclusive boundaries) across every tab that applies the date window.

• Subtotal logic that breaks when you change inputs

  • What it looks like: Updating a single case number or timekeeper only changes part of the model because one table is hard-coded.
  • What to check: Run brief “what-if” tests—change one attorney’s rate or adjust one day’s hours—and confirm the outputs update everywhere they should.

• Inconsistent rounding

  • What it looks like: Rounding hours early, then multiplying by rate, then rounding again.
  • What to check: Keep high precision in intermediate calculations and apply rounding once at the final reporting/display stage (or apply rounding consistently, exactly as your model intends).

Delaware timing reference for scoping your dataset (not legal advice)

For Delaware fee modeling, one timing concept that commonly matters for data hygiene is the general limitation period for most civil actions: 2 years. Delaware’s general statute is Title 11, § 205(b)(3) (Delaware Code). Source: https://delcode.delaware.gov/title11/c002/index.html?utm_source=openai

Because this is a brief focused on fee calculation sanity-checking, treat this as a documentation and data-window sanity reference, not a claim-type-specific rule. No claim-type-specific sub-rule was found in this brief, so the 2-year general period is the default to reference plainly and consistently.

When to run it

Run the checker at three points: before you calculate, while you iterate, and right before export.

1. Before first calculation

   • Confirm your spreadsheet structure is stable:

     • Are “hours,” “rate,” and “line total” coming from the intended columns?
     • Does each timekeeper total equal the sum of their underlying entries?
   • Quick rule: fix data model problems first; don’t chase rounding or presentation issues until arithmetic and mappings are verified.

2. After any data import or copy/paste

   • Spreadsheet failures frequently start when:

     • a CSV import changes date formats,
     • decimal separators shift (e.g., “1,5” vs “1.5”),
     • or time entry text fields are converted unexpectedly.
   • Use the checker immediately after imports to validate row counts, date parsing, and unit conversions.

3. Right before you rely on the totals

   • Your final numbers may be used in briefs, declarations, internal approval memos, or other sensitive contexts.
   • Run the checker again to confirm no later edits (especially formula changes) altered outcomes.

Delaware dataset scoping note (general default period):
If your workflow includes a limitation-period-based review window, align dataset filtering with the general 2-year period under 11 Del. C. § 205(b)(3). Since this brief uses only the default general rule, describe the window as “general/default 2 years,” not as a claim-specific limitations period. (This is for fee-data consistency, not legal advice about any particular cause of action.)

A practical checklist to apply every time

Try the checker

You can sanity-check your Delaware attorney-fee spreadsheet model by running DocketMath’s attorney-fee workflow. Start with the spreadsheet inputs, then focus on the outputs that reveal logic failures early.

Primary CTA: Run DocketMath attorney-fee

What to verify inside the tool (and how outputs should change)

As you test, make controlled changes—small enough to interpret, big enough to see an effect:

• Change 1 time entry’s hours

  • Expectation: that line total increases proportionally, and the grand total increases by the same delta.

• Change 1 time entry’s date

  • Expectation: if you have a date filter enabled, the entry should move into or out of the included window, changing totals accordingly.
  • If totals don’t respond, the date column may not be wired into the filter logic.

• Change 1 attorney’s rate

  • Expectation: all lines mapped to that attorney’s rate update, without affecting unrelated timekeepers.

If your spreadsheet has multiple stages (for example: raw entries → categorized entries → totals), treat each stage like a checkpoint:

• Raw entries stage: correct hours and rates per line
• Categorization stage: totals preserved (or intentionally adjusted)
• Reporting stage: categorized subtotals match the sums of the underlying line totals

Quick spot-check method while you run DocketMath

Use a simple “small change → predictable output” approach:

Note (Delaware timing reference): If your workflow uses a “review window,” describe it as a general/default 2-year data scoping window tied to 11 Del. C. § 205(b)(3). Avoid implying a different claim-specific limitations period unless you’ve applied a claim-specific authority.

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