Spreadsheet checks before running Damages Allocation in Montana
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Damages Allocation calculator.
Running a Damages Allocation workflow in Montana without sanity-checking your inputs can quietly create downstream errors—especially when the statute of limitations (SOL) is involved. The DocketMath damages-allocation spreadsheet-checker focuses on jurisdiction-aware verification before you calculate allocations.
Because your brief specifies no claim-type-specific sub-rule was found, the checker uses the general/default SOL period in Montana as the controlling limit:
- General SOL period: 3 years
- Cited statute: Montana Code Annotated § 27-2-102(3)
(general/default limitations period) - Meaning in practice: If the case’s relevant event date in your model is more than 3 years before the “filing date” (or other SOL-triggering date your sheet uses), the spreadsheet should flag the SOL assumption(s) for review.
Here are the most common spreadsheet issues the checker is designed to catch in a Montana-focused damages allocation:
**Date-window failures (SOL logic)
- Flags when your event/accrual date (or another SOL-relevant date in your model) is more than 3 years before the filing date (or the date your sheet uses as the SOL comparison endpoint).
- Also catches partial inconsistencies such as:
- event date after filing date
- missing filing date
- blank or non-date values in key date fields
Ambiguous date formats and spreadsheet parsing quirks
- Detects dates stored as text (common after copy/paste from email, discovery, or PDFs).
- Flags inconsistent date entry styles (for example, day/month vs month/day confusion) that can shift dates by months.
Allocation logic mismatches
- Validates relationships between columns so totals and distributions stay consistent:
- category amounts don’t sum to expected totals
- percentages exceed 100% or don’t align with corresponding dollar figures
- Flags negative values in fields where your model expects non-negative damages.
Units and rounding drift
- Identifies common mix-ups like “$” vs “%” column wiring issues.
- Highlights rounding situations where totals may drift by a few dollars—enough to break reconciliation when you expect exact category-to-total alignment.
**Jurisdiction alignment (Montana / US-MT rules)
- Ensures the workbook is configured for US-MT logic rather than another jurisdiction profile.
- If your sheet includes a jurisdiction selector, the checker confirms it’s set correctly for Montana.
Gentle caution: The checker is meant to surface input/assumption problems early. Even if the math “looks right,” SOL-related flags can indicate the allocation is resting on an unreliable premise.
Montana SOL rule the checker applies (default)
The spreadsheet-checker assumes the general/default limitations period:
- Montana Code Annotated § 27-2-102(3): 3 years
Since no claim-type-specific sub-rule was found, the checker does not apply different SOL periods by claim category. It uses the 3-year baseline wherever your spreadsheet performs a SOL comparison.
When to run it
Run the checker at three practical points in your damages allocation workflow: before you commit to calculations, after you edit inputs, and immediately before you export or finalize outputs.
Use this checklist:
Before entering damages amounts
- Confirm your SOL-relevant dates are complete and are real spreadsheet dates (not text).
- Ensure the sheet is set to US-MT.
After importing or pasting dates
- Run the checker right away if you copied dates from email, discovery, or a PDF-to-Excel conversion.
Before finalizing allocation totals
- Confirm the allocation math reconciles:
- category totals
- percentage-to-dollar relationships
- no negative or out-of-range entries
When any “trigger” assumption changes
- If you switch the date your model treats as accrual or filing (even by a few days), rerun the checker.
- Small edits can move a case across the 3-year boundary under § 27-2-102(3).
Inputs the checker typically validates (and how results change)
A Montana damages allocation sheet commonly needs:
- Event/accrual date (what starts the clock in your model)
- Filing date / relevant filing date (what ends the comparison window)
- Damages categories and amounts
- Allocation percentages or weights used to distribute totals
How outputs change:
- If dates fail parsing or appear inconsistent, the checker will flag or halt SOL-related evaluation so you don’t produce allocations based on flawed date assumptions.
- If allocation totals don’t reconcile, the checker flags math integrity issues even when SOL dates are otherwise valid.
Try the checker
If you want to validate a Montana damages allocation spreadsheet quickly, start with DocketMath’s calculator and run the spreadsheet-checker step:
- Open: /tools/damages-allocation
- Choose or load your US-MT inputs
- Run the spreadsheet-checker before using the computed damages allocation results
To make the “try it” step meaningful, focus on the inputs most likely to generate flags:
- Enter dates using the format the sheet expects (to avoid “text date” storage).
- Ensure both event/accrual date and filing date are populated.
- Confirm damages category figures and allocation percentages match your intended totals.
Quick try scenario (to see SOL flag behavior change):
- Set event/accrual date to a day within 3 years of the filing date.
- Then move the event/accrual date forward to just beyond the 3-year mark.
- Re-run the checker and observe whether the SOL window flag changes state—this helps confirm the sheet is applying the 3-year default under Montana Code Annotated § 27-2-102(3).
Pitfall to watch: If dates display correctly but are stored as text, the checker may treat them as missing/invalid and produce misleading alerts. Fixing date storage often resolves the bulk of issues.