Spreadsheet checks before running Damages Allocation in Maine

5 min read

Published April 15, 2026 • By DocketMath Team

This article is for informational purposes only and does not constitute legal advice. Laws change frequently — verify all citations with current official sources.

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Before you run Damages Allocation in Maine (US-ME), DocketMath’s spreadsheet checker helps you avoid the most common failure points that lead to incorrect allocations, broken calculations, or missing time-window inputs.

It’s focused on issues that are easy for a spreadsheet to “accept” without throwing obvious errors—especially when the underlying time inputs (dates, start/end boundaries, and time slices) are off.

Here are the main issues it’s designed to catch in your sheet:

Missing or malformed date fields
- Examples:
  
  Blank “incident date” or “filing date”
  
  Dates stored as text (e.g., 01/15/2025 entered into a cell formatted as text)
  
  Inconsistent day/month ordering across tabs
**Statute-of-limitations (SOL) window errors (baseline rule)
- Maine’s general/default limitations period is 0.5 years under Title 17-A, § 8.
- Important: the checker treats this as the general period only. Your jurisdiction notes did not identify any claim-type-specific sub-rule, so the sheet should not imply a longer/shorter period unless your own materials include that logic elsewhere.
- The checker validates that your model’s time window matches this baseline and doesn’t accidentally include or exclude the wrong portion of time.
Incorrect directionality in time math
- Common spreadsheet mistakes:
  
  Calculating “elapsed” as start - end instead of end - start
  
  Using absolute values (ABS(...)) that hide sign errors
Row alignment and unit consistency
- Damages allocation spreadsheets often join multiple schedules (damages categories, parties, time periods).
- The checker verifies that:
  
  Category labels align with their numeric columns
  
  Currency/units are consistent (for example, dollars vs. cents, months vs. days)
Broken formulas or reference drift
- It flags conditions like:
  
  #REF! errors
  
  Ranges that shift after sorting/filtering
  
  Totals computed from the wrong column due to inserted columns
Allocation totals that don’t reconcile
- Many allocation models require that “sum of allocated amounts” equals “allocated pool.”
- The checker checks reconciliation logic so you don’t end up with subtle rounding or missing-row errors that still look “nearly right.”

Pitfall to avoid: If your date cells are formatted as text, spreadsheets can silently treat them as strings. That can cause elapsed-time calculations to return blanks or 0, while Damages Allocation still runs using incorrect inputs.

When to run it

Run the checker at two points: before you run Damages Allocation and after any edits that touch timing or mappings.

A practical workflow:

At the start of modeling
- Confirm your sheet includes:
  
  incident/event date(s)
  
  relevant “as-of” date(s) used by the Damages Allocation logic
  
  consistent date formatting across tabs
Right after you import or paste data
- This is when date formatting and reference alignment are most likely to drift:
  
  copying from exports
  
  pasting from case management tools
  
  splitting/merging tables
After you change any of these columns
- Date columns: incident/occurrence/filing/as-of
- Time-slice boundaries (weeks/months used in the allocation)
- Category mapping tables
- Total/allocation pool inputs

Maine-specific timing check you should expect

The calculator/checker uses Maine’s general/default limitations period of 0.5 years under:

Title 17-A, § 8 (General SOL Period: 0.5 years)
https://legislature.maine.gov/statutes/17-a/title17-asec8.html?utm_source=openai

Because the jurisdiction notes do not identify any claim-type-specific sub-rule, the checker should not treat the SOL as a different period based on claim type. If your own dataset includes special timing rules outside these notes, make sure your sheet reflects that logic explicitly and that the checker is configured/covered accordingly.

Try the checker

You can start directly from DocketMath’s tool flow. Use the primary CTA:

Run Damages Allocation: /tools/damages-allocation

Before clicking “run,” use this quick preparation checklist on your spreadsheet:

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

Spreadsheet inputs to prepare

Ensure they behave like dates (not strings).
- “as-of” (or calculation end date) minus “incident/event” (calculation start date).
- Baseline: 0.5 years under 17-A § 8 (general rule).
- Labels and values stay in sync after sorting/filtering.
- “allocated amounts” sum to the pool you intend to allocate.

How outputs change when the sheet is wrong

When the spreadsheet has an issue, the checker is meant to stop bad inputs early. Typical knock-on effects include:

SOL window validation fails
- The tool flags that your model includes time outside the 0.5-year general/default period under 17-A § 8.
Time-slice allocation shifts
- If dates are off by even a few days, the included/excluded slices can change, which changes allocated outcomes.
Reconciliation discrepancies appear
- Missing rows or misaligned columns lead to “totals don’t match,” and that mismatch can cascade into the final allocation results.

Once you correct underlying inputs—especially date formatting and start/end alignment—the results should stabilize quickly, because the checker’s job is to ensure the spreadsheet can be trusted before the calculator performs the heavier computation.

Gentle reminder: this is a spreadsheet validation workflow, not legal advice. SOL logic and claim timing can be fact-specific—if you have unique circumstances, confirm your approach using qualified guidance.