Spreadsheet checks before running Damages Allocation in New York
6 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Damages Allocation calculator.
Before you run a Damages Allocation calculation in New York (US-NY), it’s easy for spreadsheet problems to slip in unnoticed—and then quietly distort totals, allocations, or the “timely vs. untimely” split.
DocketMath’s spreadsheet-checker is built to catch these issues early, before the damages-allocation calculator processes your rows. Think of it as a pre-flight check for the inputs that drive both the math and any New York jurisdiction-aware timeliness gating.
Here are the most common defects a jurisdiction-aware spreadsheet checker can surface for a New York workflow:
1) Date fields that won’t align with the limitations period
In this New York ruleset, the checker uses the general/default 5-year limitations period:
- General SOL period: 5 years
- General statute: N.Y. Crim. Proc. Law § 30.10(2)(c)
What this means in practice: the checker looks at your date columns (for example, event/accrual/trigger date and filing date, depending on your sheet) to help ensure they behave like real dates inside formulas—not like plain text.
Specifically, it helps verify that dates are:
- stored as a true date type (not text),
- consistently comparable (e.g., same normalization approach across the sheet),
- in the order the allocation/timeliness logic expects.
Important note: This ruleset does not include a claim-type-specific sub-rule. The checker therefore treats the 5-year general/default period as the baseline rather than swapping in narrower timelines.
2) Off-by-one logic that flips boundary rows
A spreadsheet can look correct in a table view but still produce wrong timeliness outcomes due to boundary handling. Common culprits include:
- inclusive vs. exclusive day counting,
- month-end assumptions,
- extracting YEAR from a full date (which can collapse different dates into the same year),
- inconsistent formatting that hides the fact that values aren’t actually equal.
The checker can flag patterns that often lead to “boundary flips,” such as rows that should sit right inside the limitations window but get categorized differently after a format or calculation correction.
3) Allocation math that breaks due to blanks, zeros, or percent formatting
Damages allocation models typically use weights (for example, percent shares) and intermediate subtotals. Spreadsheet issues here tend to be subtle but impactful:
- Empty cells treated as 0
- Percent values entered as text like
"25%"instead of numeric0.25 - Division by a total that becomes 0 after a filter or missing weight inputs
- Negative allocations creeping in due to sign errors or subtractive steps
The checker helps you confirm that critical inputs exist and are usable:
- weight/percent columns are populated for the rows you’re allocating,
- weight values are numeric (not text),
- weights are set so they sum correctly according to your model (e.g., sum to 1 or sum to 100%).
4) Row alignment problems (the “wrong reason, wrong number” bug)
A sheet can have correct-looking columns while the underlying row relationships are misaligned. Examples:
- damages amount shifted by one row,
- claim type labels or categories not matching the same row as the damages value,
- weights table filtered differently from the damages table.
The checker can validate structural consistency—helping ensure that the row set driving weights matches the row set driving allocation amounts, so allocations aren’t accidentally applied to the wrong entries.
5) Output sanity checks that catch “plausible but wrong” totals
Even when each individual calculation seems reasonable, the overall outputs can still be wrong due to rounding, missing rows, or inconsistent partition logic.
The checker can support review by helping confirm that:
- allocated totals behave consistently with the original damages total (unless you’ve explicitly modeled escalation or adjustments),
- the sum of allocations matches the intended base (subject to whatever rounding rules your model uses),
- the “timely” and “untimely” bucket partition aligns with your expectations about which rows fall into each category.
Gentle reminder: the checker is about spreadsheet and input integrity. It’s still your responsibility to ensure the underlying legal assumptions you’ve encoded match your intended use. This content is not legal advice.
When to run it
Run the spreadsheet-checker at three practical points—each time for a different purpose:
Before running
damages-allocation- Purpose: prevent errors from cascading into calculated outputs.
- Best time: right after you paste/upload the spreadsheet data into DocketMath.
After you adjust core dates or SOL-related inputs
- Purpose: confirm that timeliness flags and bucket assignments change only where intended.
- Common triggers:
- changing filing dates,
- correcting event/accrual/trigger dates,
- changing the date column formatting (e.g., text → date).
Before exporting results or sharing with others
- Purpose: ensure the sheet is internally consistent for review and presentation.
- Practical workflow:
- rerun checker,
- fix flagged issues,
- then export or share the allocation results.
Quick checkbox for your next run
Try the checker
If you’re setting this up for the first time, use this sequence:
- Open DocketMath → damages allocation
- Run spreadsheet-checker first
- Fix any flagged items
- Run damages-allocation after the sheet passes checks
Primary CTA: /tools/damages-allocation
How corrections can change outputs (concrete examples)
Here’s what typically changes when the checker detects and you fix input problems:
| Spreadsheet issue the checker finds | Typical effect before fix | What improves after fix |
|---|---|---|
| Filing date stored as text | Timeliness bucket may misclassify all rows | Timely/untimely split reflects correct dates |
Weights formatted as "25%" text | Allocation totals may be 0 or nonsensical | Allocation amounts distribute correctly |
| Missing weight cells | Some rows allocate incorrectly or appear to “drop” | Rows receive consistent allocation logic |
| Date order reversed in a subset of rows | Only some rows appear “late” | Those rows move to the correct bucket |
Warning: If the checker flags a date-format issue, don’t rely on what the sheet looks like. A spreadsheet can display human-readable dates while formulas still treat them as strings—especially around the 5-year general window referenced by N.Y. Crim. Proc. Law § 30.10(2)(c).
When you’re ready, try it directly here: /tools/damages-allocation (run the spreadsheet-checker before the calculator step).
