Common attorney fee calculations mistakes in Delaware

The top mistakes

Run this scenario in DocketMath using the Attorney Fee calculator.

Running attorney-fee calculations in Delaware gets tricky fast—especially when you’re translating litigation facts into spreadsheet logic. Below are common mistakes teams run into when using DocketMath’s /tools/attorney-fee workflow for US-DE scenarios.

1) Using the wrong time window for allowable fees

A frequent error is calculating fees for the wrong period—either:

• Starting too early (including work before the legally relevant period), or
• Stopping too late (including work after a filing deadline that cuts off recovery).

If you’re working from a “lookback” concept, anchoring the period incorrectly leads to inflated totals and later reconciliation issues.

Delaware default anchor to use (when applicable):

• 2-year general SOL period under 11 Del. C. § 205(b)(3) (this is a general default for many situations; no claim-type-specific sub-rule was identified in this brief)

2) Double-counting work across billing categories

Teams sometimes paste the same line items into multiple buckets, for example:

• “Research” and “Attorney time” both containing overlapping entries, or
• “Motions” fees counted again under “hearing preparation.”

This error often appears when invoices are normalized inconsistently—for example, one table records hours by activity while another records totals by phase. Feeding both into the tool can effectively count the same time twice.

3) Misapplying multipliers (or using multipliers that don’t match the tool’s model)

Many fee calculations require consistent approaches to rates and adjustments. A common pattern:

• Applying a multiplier to totals that were already adjusted, or
• Supplying multiplier inputs that don’t align with how DocketMath computes outputs.

Even when your math seems correct, the input model can be mismatched—producing plausible-looking results that are wrong for the tool’s assumptions.

4) Mixing hourly rates with blended rates without reconciling totals

Another pitfall is using both:

• A blended hourly rate (e.g., average across attorneys), and
• Individual hourly rates by timekeeper

If both are applied, you can end up effectively charging the “rate layer” twice.

Practical rule: choose one rate method in the inputs—either timekeeper-specific or blended—and keep it consistent for the run you’re comparing.

5) Treating non-billable (or excluded) time as billable

Invoice exports often include time marked as:

• “Internal review,”
• “Clerical,”
• “Administrative,” or
• “Conference notes”

If excluded time isn’t clearly mapped (and filtered) before running the calculation, it can slip into the billable-hours dataset.

6) Failing to separate recoverable vs. non-recoverable tasks (when your dataset includes both)

Even without giving legal advice, you can reduce calculation risk by enforcing a consistent data model. For example:

• Work tied to multiple outcomes, or
• Tasks clearly outside the fee-shifting or recovery mechanism your model is targeting

If you don’t categorize upfront, the tool may include time you intended to exclude.

7) Not accounting for rate changes across time

If you model attorney rates as “current” rates, it’s easy to accidentally:

• Apply today’s rate to work performed 24 months ago, or
• Apply an old retainer rate to work billed later under a different structure

A common fix is to split hours by rate period (even if your periods are coarse).

How to avoid them

The goal is straightforward: make sure your inputs match your intent, and that your outputs match your policy (i.e., what time and cost you’re modeling). Here are practical, repeatable steps that work well with DocketMath.

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

Step 1: Lock the Delaware time window before entering hours

Before you enter or import hours, decide the fee-eligibility window you’re modeling and apply it consistently.

• Default SOL anchor to use when modeling “default” deadlines: 2 years under **11 Del. C. § 205(b)(3)
• Treat it as a general default and confirm whether a claim-specific SOL rule applies in your situation

Checklist:

Step 2: Normalize invoice lines so nothing can double-count

Before using DocketMath:

If you need multiple views, keep reporting separate from the calculation dataset.

Step 3: Choose one rate method—and apply it everywhere

Pick either:

• Timekeeper-specific hourly rates, or
• A blended hourly rate for the whole matter

Avoid mixing within a single calculation run.

Quick validation:

Step 4: Align multiplier inputs with the tool’s structure

If you’re using any adjustment/multiplier feature in DocketMath:

Small test that usually catches input mismatches:

Step 5: Exclude non-billable time at the data stage

Instead of excluding after the fact, tag and filter upfront:

This reduces the risk that cleanup steps miss edge cases.

Step 6: Split work into rate periods if your dataset spans rate changes

If hours span multiple rate schedules:

This improves accuracy and prevents “rate drift” errors.

Step 7: Use DocketMath to reconcile—not just to compute

After running the tool:

For quick access to the tool: /tools/attorney-fee

Gentle reminder: this is general implementation guidance, not legal advice. A calculation can appear correct yet be wrong if the fee window (including the 2-year general SOL under 11 Del. C. § 205(b)(3)) is applied inconsistently or if a claim-specific SOL rule applies.

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