Spreadsheet checks before running attorney fee calculations in Maine

6 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Before you run any Maine attorney-fee spreadsheet calculations with DocketMath, do a quick sanity-check on the workbook inputs and formulas. In practice, spreadsheets fail most often due to time-window mistakes, wrong sign conventions, or “quiet” data issues (blank cells, mixed formats, duplicated rows).

Here are the most common problems the spreadsheet-checker should catch before you calculate fees:

1) Incorrect date logic (especially for deadlines)

Maine’s general statute of limitations is 6 months (0.5 years) under Title 17-A, § 8. This guidance uses the general/default period onlyno claim-type-specific sub-rule is identified here. If your spreadsheet uses a different time window (or hard-codes a different number of days), results can drift significantly.

Checks to run in the sheet

  • Confirm the spreadsheet uses 6 months (not “1 year,” and not “180 days” unless you verify the conversion method).
  • Verify whether the date window is calculated from:
    • the event date (e.g., filing/occurrence), or
    • a notice date, or
    • the date the underlying action is “brought.”
  • Ensure time-zone and “end-of-month” edge cases aren’t creating off-by-one results.

Pitfall: Converting “6 months” into a fixed “180 days” can miscount when the span crosses months with different lengths. Even a one-day shift can change which time entries fall inside the allowable window.

2) Misapplied attorney-fee “type” mapping

Even if the fee calculation is arithmetic-correct, fee spreadsheets often mix categories, such as:

  • attorney time vs. paralegal time,
  • hourly rates vs. blended rates,
  • expenses vs. fees,
  • settlement reductions vs. award amounts.

The checker should confirm that each line item lands in the correct bucket and that totals roll up predictably.

Quick validation ideas

  • Spot-check 5–10 rows: confirm each row’s “type” routes to the expected subtotal.
  • Confirm rollups: totals should sum exactly the included rows (and not “almost match” due to a range mismatch).

3) Formula integrity problems

A spreadsheet can look right while being broken:

  • hard-coded numbers where a formula should reference a table,
  • stale lookups (rates table updated but formulas still point to old columns),
  • accidental truncation (rounding at intermediate steps),
  • inconsistent totals (sum ranges don’t match displayed rows).

Checklist

  • Every “total” cell should trace back to a defined row range.
  • Lookups should fail loudly in test/dev data (e.g., show #N/A) rather than silently returning blanks.
  • Rounding should occur at the final output step unless the fee method explicitly requires earlier rounding.

4) Sign and currency direction errors

Common sign issues include:

  • negative durations because “end date” precedes “start date,”
  • rate cells stored as text (e.g., "250/hr"),
  • currency symbols embedded in numbers.

Sanity-check inputs and computed values to confirm:

  • all durations are ≥ 0,
  • all rates are numeric,
  • totals follow expected directionality (e.g., reductions subtract; awards add).

5) Duplicate or missing time entries

If your export pipeline can re-run, duplicates happen. Similarly, blank billing notes can lead to empty rows that should still be included—or rows that are excluded when they shouldn’t be.

The checker should:

  • detect duplicated (date, description, hours) triples,
  • flag rows with hours but missing required fields (or vice versa),
  • verify that row counts match the source extract you imported.

Note: This is a practical QA step, not legal analysis. Treat it as a way to catch mechanical spreadsheet errors before you run the calculation.

When to run it

Use the checker at three points in your workflow so issues are caught when fixes are cheapest.

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.

Run #1: Before any fee math

Do this immediately after importing:

  • the time entries,
  • the rates table,
  • the expense list,
  • the dates needed for the limitations or window logic.

At this stage, you’re verifying structure and formats—not debating results.

Run #2: Right after you pick the limitations/window parameters

If your spreadsheet includes a “window start/end” section, run the checker immediately after setting those dates based on Maine’s general 6-month period (0.5 years) under Title 17-A, § 8.

Because no claim-type-specific sub-rule was found in the provided brief, treat the 6-month period as the general/default baseline and document that assumption in a “Notes” tab.

Source: https://legislature.maine.gov/statutes/17-a/title17-asec8.html?utm_source=openai

Run #3: After the first fee calculation output

Finally, validate that the spreadsheet outputs behave like expected numbers:

  • totals increase when hours increase,
  • totals decrease when you apply reductions,
  • changing the date window moves entries in/out of inclusion.

Try the checker

DocketMath’s attorney-fee flow works best when the spreadsheet is already clean. Here’s a practical approach to run the spreadsheet-checker checklist before you hit /tools/attorney-fee.

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Step 1: Confirm the limitations window setup

Add a small “Window inputs” area to your workbook and verify:

  • Window length: 0.5 years (6 months)
  • Calculation method: months-based vs days-based
  • Start anchor: the correct event date your sheet uses

If you’re using 17-A, § 8 as your baseline, keep it explicit:

  • Maine general SOL: 0.5 years
  • Statute: Title 17-A, § 8
  • General/default period only (no claim-type-specific sub-rule identified in this brief)

Step 2: Validate time-entry math

For each row:

  • ensure duration = end_date - start_date (or matches your workbook’s agreed conversion),
  • ensure hours is derived or verified from duration,
  • ensure no row is included with blank hours or malformed rates.

A quick spot test is enough:

  • pick 3 rows at random,
  • re-check their hours and rate inputs,
  • compare the row-level subtotal to the formula output.

Step 3: Verify rollups and totals

Rollups fail silently in spreadsheets. The checker should enforce:

  • totals match sum of included rows,
  • totals exclude rows flagged as out-of-window (if your method filters by date),
  • subtotals reconcile with the final figure shown in the report tab.

Use these sanity relationships:

  • Grand total = Fees + Expenses
  • Fees = (Hours × Rate) aggregated by category
  • Final = Gross − Reductions (if reductions are modeled)

Step 4: Run DocketMath for the first calculation

Once the worksheet passes structure checks, run the actual calculation in DocketMath via:

Then observe sensitivity:

  • increase one included row’s hours by 1.0
  • confirm output changes by approximately rate × 1.0 (minus any configured rounding behavior)

That one test catches many “formula points at the wrong range” issues.

Warning: If you see no change after adjusting included hours by 1.0, your spreadsheet may be summing the wrong range or not applying the inclusion filter you think it uses.

Related reading