Spreadsheet checks before running Damages Allocation in Florida

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Before you run Damages Allocation in DocketMath for a Florida matter, you want to prevent one common spreadsheet failure: feeding the calculator dates and damage periods that don’t pass jurisdiction-aware checks. The spreadsheet checker is built to catch these issues early, so your allocation math doesn’t get distorted downstream.

For Florida (US-FL), this checker focuses on the general/default statute of limitations (SOL) period—because no claim-type-specific sub-rule was identified for this workflow. That means the checker uses a 4-year baseline rather than trying to classify each claim automatically.

Common problems the checker flags for Florida

• Missing or inconsistent “start” and “end” dates

  • Examples:

    • A damages period ending earlier than it starts.
    • A blank “incident/start date” field that your allocation logic relies on.

• Non-Florida SOL inputs

  • If your sheet carries a limitation period assumption from another jurisdiction (even if the numbers look plausible), the checker can flag mismatches when the jurisdiction context doesn’t align.

• Damages periods that extend beyond Florida’s general SOL lookback

  • Florida’s general/default civil limitations rule used in this guide is:

    • 4 years (general SOL period)
    • Referenced via **Florida Statute § 775.15(2)(d)
  • Since no claim-type-specific sub-rule was found, the checker applies the general 4-year period as a default baseline.

• Date formatting errors

  • Dates stored as text (e.g., 01/02/24 as a string) can cause silent failures:

    • wrong comparisons,
    • incorrect arithmetic,
    • or empty/incorrect result rows.

• Row-level drift

  • Spreadsheets sometimes update only part of the data when a date changes:

    • e.g., 120 invoices reflect a new incident date, but 7 rows were left behind.
  • The checker looks for inconsistencies that suggest the “same” date logic wasn’t applied consistently across rows.

• Inconsistent treatment of partial periods

  • If one column uses month-level granularity while another uses day-level granularity for the “same” damages window, the checker can detect the mismatch that leads to allocation differences.

Pitfall to avoid: A damages allocation can appear mathematically correct while being legally stale. A single damages window that should be limited under Florida’s general 4-year SOL can inflate totals—especially if the calculator is faithfully computing against an overlong period.

To be useful, the checker should validate the exact date fields that DocketMath Damages Allocation consumes (not just “date columns in general”). When the checker reports a problem, the goal is to correct the data that drives the calculator’s jurisdiction-aware windowing.

When to run it

Run the spreadsheet checker before you launch /tools/damages-allocation.

A practical workflow:

1. Finalize the date columns in your spreadsheet

   • Make sure you have the fields that define the damages window (for example: incident/start date and damages end date).

2. Normalize date formats

   • Convert date-like entries into true spreadsheet dates (not text). This reduces the chance of faulty SOL comparisons.

3. Run the checker

   • Fix any rows it flags.
   • Re-run until the checker passes cleanly.

4. Run DocketMath Damages Allocation

   • Once the checker approves your inputs, the allocation output is driven by the same date logic that your sheet actually contains.

Re-run the checker immediately if you change any of the following

• incident/start date
• damages end date
• any “lookback window” or date-derived field
• the column/rule that decides which rows fall inside vs. outside the SOL window

Florida baseline applied by this workflow:

• General SOL Period: 4 years
• Statute: **Florida Statute § 775.15(2)(d)
• Source: https://www.flsenate.gov/Laws/Statutes/2004/775.15?utm_source=openai

And because no claim-type-specific sub-rule was found, treat this as a default baseline, not an attempt to exhaustively classify every claim category. (This guidance is about spreadsheet integrity and default window application—not legal advice.)

Try the checker

Use DocketMath’s Damages Allocation tool only after your spreadsheet passes the jurisdiction-aware checks. You can start here: /tools/damages-allocation.

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

What you’ll provide (spreadsheet inputs)

The checker will typically be concerned with:

• Jurisdiction selector / context: set to **Florida (US-FL)
• Damages start date (or incident/start date, depending on your sheet)
• Damages end date
• Optional row mapping (if your sheet breaks damages into multiple windows/periods)

How the checker findings affect your allocation output

Think of the checker as protecting the calculator’s assumptions. When it flags something, it usually prevents one of these outcome shifts:

Florida baseline used by this checker (general/default)

This workflow applies:

• General SOL Period: 4 years
• Referenced via: **Florida Statute § 775.15(2)(d)
• Source: https://www.flsenate.gov/Laws/Statutes/2004/775.15?utm_source=openai

Because no claim-type-specific sub-rule was found, the checker does not branch by claim label. It uses the general/default 4-year period as the baseline for the damages window you provide.

Quick “before you allocate” checklist

If your sheet is clean, you’ll be able to trust that the calculator is allocating damages across the windows your spreadsheet actually specifies—using the Florida general/default 4-year baseline logic.

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