Spreadsheet checks before running Damages Allocation in Rhode Island

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Running a Damages Allocation calculation in Rhode Island without a spreadsheet QA pass can introduce silent errors—especially when your sheet combines multiple inputs (dates, claim amounts, payments, and allocation buckets) that drive the final output.

The DocketMath spreadsheet-checker (jurisdiction-aware for US-RI) is designed to catch common issues that break downstream logic before you run the damages-allocation calculator at /tools/damages-allocation.

Below are the main checks the checker performs using Rhode Island’s general/default limitations rule provided in the jurisdiction data (including the statute citation).

Date-field inconsistencies

• Missing start date or end date
• End date earlier than start date
• Dates stored as text (for example, 01/02/2025 saved as a string), which can cause mis-sorting or “zero-day” style logic errors

General SOL timing issues (default/general rule)

• The checker applies Rhode Island’s general/default limitations period using General Laws § 12-12-17.
• Per the jurisdiction data provided, the general/default period is 1 year.
• No claim-type-specific sub-rule was identified, so the checker uses the general/default period rather than a specialized carve-out.
• It flags cases where the worksheet’s event-driving date (or the date your sheet indicates for timing) plus 1 year falls outside the limitations window.

Allocation math faults

• Allocation buckets that don’t add up to the intended total

  • Example: $25,000 split into $10,000 + $8,000 + $6,000 = $24,000
• Percent-based allocations that don’t total 100%
• Negative values where your sheet expects nonnegative amounts (often caused by “net” columns, sign flips, or subtraction in the wrong direction)

Data typing problems

• Amounts stored as text (for example, "$1,200" including a currency symbol)
• Mixed units (some entries in dollars, others in cents), leading to incorrect proportional allocation

Cross-column alignment errors

• Row-level mismatches (for example, payments tied to the wrong line item due to a shifted column)
• Duplicate rows with slightly different numbers (common copy/paste drift)

Pitfall to avoid: The most dangerous spreadsheet problems aren’t the ones that crash your calculation—they’re the ones that produce results that “look right.” The checker is built to find those “plausible but wrong” conditions early.

When to run it

Run the checker as a gate before you run /tools/damages-allocation—and especially at points where your sheet is likely to change or where one incorrect input can propagate into many outputs.

A practical cadence for US-RI:

• Before the first run

  • After you paste or import line items into your spreadsheet
  • Right after you set column headers for dates, amounts, and allocation buckets

• After any changes

  • You update any date used to determine whether the worksheet falls within the 1-year general/default period under General Laws § 12-12-17
  • You add new rows (new claims, new payments, or new categories)
  • You change totals logic (for example, switching from “gross” to “net,” or adjusting any reconciliation formula)

• Before sharing results

  • If you copy outputs into a settlement memo, appendix, or an externally shared spreadsheet, re-run the checker on the export-ready version to reduce transcription risk

A simple “best order” workflow:

1. Verify your sheet’s date columns are real dates (not text)
2. Run /tools/spreadsheet-checker
3. Run /tools/damages-allocation
4. If you adjust inputs based on the first results, re-run the checker and re-check outputs

Try the checker

You can test the workflow on your Rhode Island worksheet by combining the checker with the damages calculator.

1. **Run the spreadsheet-checker (jurisdiction-aware QA)

   • Open: /tools/spreadsheet-checker
   • Target your worksheet inputs for:

     • the event-driving date(s) used for SOL timing
     • allocation amounts and/or allocation percentages
     • totals referenced by your damages-allocation logic

2. Run the Damages Allocation calculator

   • Primary CTA: /tools/damages-allocation

What to provide (inputs that affect outputs)

To get useful results, make sure the checker can read the cells for:

• Dates

  • Event date (the date your sheet treats as the “trigger”)
  • Any supporting date columns if your sheet uses them for gating

• Amounts

  • Total damages / total claim amount
  • Bucket amounts (or bucket percentages)
  • Payments or reductions (if your allocation design uses them)

• Allocation logic

  • Whether the sheet allocates by percentages or by fixed amounts
  • Any constraints that require buckets to sum to a total (or sum to 100%)

How outputs typically change after fixes

Once you correct what the checker flags, damages-allocation outputs usually change in predictable ways:

• SOL-window flags cleared

  • If the checker previously determined your worksheet falls outside the 1-year general/default window under General Laws § 12-12-17, fixing date formatting or correcting the driving date can flip whether the timing check passes.

• Sum-to-total issues corrected

  • If buckets didn’t sum to the expected total, corrected totals usually update:

    • allocated amounts per bucket
    • any proportional distribution results based on those bucket values

• Text-to-number fixes

  • Converting amounts stored as text into numeric values commonly prevents “empty,” zeroed, or miscomputed allocation arithmetic.

Reminder: This is not legal advice. Treat the checker as a math-and-data QA layer that uses the provided Rhode Island general/default SOL period for timing flags.

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