Spreadsheet checks before running Damages Allocation in Vermont

What the checker catches

Running a “Damages Allocation” step in Vermont is only as reliable as the spreadsheet that feeds it. Before you calculate, DocketMath’s damages-allocation checker is designed to catch the spreadsheet problems that most often cause allocation math to drift, overwrite values, or silently misclassify items—especially when rows and dates drive timing logic.

Below are the failure points this checker targets before you commit to an allocation run in US-VT.

Data integrity issues

• Blank or null claim fields
  Examples include missing dates, missing principal/fee amounts, or empty allocation categories.
• Negative values where they don’t belong
  Examples: a negative “days outstanding” or a negative “base damages” line.
• Inconsistent currency formatting
  For example, some cells stored as text (e.g., $1,200) mixed with numeric cells—this can break totals and comparisons.
• Unit mismatches
  Examples: “days” entered as “months,” or an annual rate entered in a field that expects a total rate.
• Duplicate line items
  Same description and date repeated across rows can cause double-counting even when totals “look close.”

Allocation logic hazards

• Totals that don’t reconcile
  For example, row sums don’t match column sums, or an “allocated total” doesn’t equal the spreadsheet’s “gross total.”
• Percentages that don’t total 100% within the allocation section
  A small split error can cascade into large component shifts.
• Cap/limit fields present but not linked
  If the worksheet includes limit inputs, the checker flags when they appear disconnected from the damage components they should constrain.
• Cross-column misalignment
  A common spreadsheet risk: a date column shifted by one row so components attach to the wrong time period. The output may still compute, but it won’t represent the intended timeline.

Jurisdiction-aware timing checks (Vermont)

DocketMath can apply a Vermont-aware default statute-of-limitations timing screen using the general rule you’ll be operating under for spreadsheet runs.

• General SOL Period (Vermont): 1 years
• Claim-type-specific sub-rule: No claim-type-specific sub-rule was found in the provided jurisdiction data.
  So the checker uses the general/default period as the governing timing frame.

Pitfall (how this affects results): If your spreadsheet contains event dates older than 1 year from your chosen reference date (commonly the filing date you’re modeling), the checker can flag timing risk. However, it won’t “fix” your underlying date assumptions—your allocation outputs may still be produced, but they may reflect a window you should re-check.

Output-side flags you should expect

After you run the checker, look for:

• A reconciliation report (what balanced, what didn’t)
• A validation list (which rows/cells triggered issues)
• A timing summary (based on the 1-year general SOL period in the jurisdiction data)

The goal is simple: reduce spreadsheet ambiguity before allocation math begins.

When to run it

Treat spreadsheet checks as a gate before any allocation computation that depends on dates, amounts, and category mapping.

Run the checker before importing a spreadsheet into the Damages Allocation workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

Run it before “Damages Allocation” whenever…

• You edit any of the following:

  • Event dates (accrual/start/end)
  • Amounts (principal, fees, interest base, adjustments)
  • Allocation categories or percentage splits
• You add or delete rows (especially if the spreadsheet uses formulas that reference row ranges)
• You change the reference date used for timing screens (Vermont timing uses the general/default 1-year period provided in the jurisdiction data)

Recommended workflow (practical and repeatable)

1. Import spreadsheet → run checker
2. Review reconciliation and validation errors
3. Correct inputs
4. Re-run checker until the report is clean (or only contains acceptable exceptions)
5. Run damages-allocation calculator
6. Lock the input snapshot (export/save the checked version) so re-runs match the validated state

Note (not legal advice): This is workflow guidance and spreadsheet validation. The SOL timing screen is based on the general/default period (1 year) provided in the Vermont jurisdiction data, and is intended to highlight date-driven spreadsheet risk—not to determine legal entitlement.

Why the timing screen belongs early

Damages allocation often depends on the time window of damages components. If your dates are wrong (or mis-typed), the allocation can shift significantly—even when the spreadsheet still “balances.” Running the checker early helps catch date and structure issues before they propagate into outputs.

Try the checker

You can try the Vermont workflow directly in DocketMath using the dedicated tool path for damages allocation:

• Open DocketMath → Damages Allocation: /tools/damages-allocation

Once there, use the checker as your first action.

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

What to prepare in your spreadsheet

Before running, ensure your sheet includes (at minimum) the inputs your allocation model relies on, such as:

• A date column for the events you’re allocating across time
• A base amount column per line item
• An allocation category column (or an allocation percentage mapping section)
• A gross total and/or sum totals the worksheet uses for reconciliation

How outputs should change when you fix checker flags

After you correct a flagged issue and re-run, you should expect improvements such as:

• Reconciliation differences decrease (row/column totals align)
• Percentage-based allocations normalize (allocation totals move closer to expected totals)
• Timing-related flags adjust (dates outside the window may drop or shift once date assumptions are corrected)
• Component totals shift (because misaligned categories or shifted rows are corrected)

If timing risk is reported because dates fall outside the 1-year general SOL window (Vermont general/default period from the provided jurisdiction data), correcting the date assumptions can materially change the allocation window and the component-by-component results.

Law-driven assumption used for Vermont timing checks

For this jurisdiction-specific workflow, the checker uses:

• Vermont general SOL period: 1 year
• Source provided: Vermont legislative calendar document (HC200226)
  https://legislature.vermont.gov/Documents/2020/Docs/CALENDAR/hc200226.pdf
• No claim-type-specific sub-rule identified in the provided jurisdiction data, so the checker applies the general/default period.

Related reading

• Damages Allocation Guide for Alabama — Comparative Fault Rules
• Damages Allocation Guide for Alaska — Comparative Fault Rules
• Damages Allocation Guide for American Samoa — Comparative Fault Rules