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:

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 numeric 0.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:

  1. Before running damages-allocation

    • Purpose: prevent errors from cascading into calculated outputs.
    • Best time: right after you paste/upload the spreadsheet data into DocketMath.
  2. 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).
  3. 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:

  1. Open DocketMath → damages allocation
  2. Run spreadsheet-checker first
  3. Fix any flagged items
  4. 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 findsTypical effect before fixWhat improves after fix
Filing date stored as textTimeliness bucket may misclassify all rowsTimely/untimely split reflects correct dates
Weights formatted as "25%" textAllocation totals may be 0 or nonsensicalAllocation amounts distribute correctly
Missing weight cellsSome rows allocate incorrectly or appear to “drop”Rows receive consistent allocation logic
Date order reversed in a subset of rowsOnly 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).

Related reading