Spreadsheet checks before running Damages Allocation in Illinois

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Before you run Damages Allocation in Illinois with DocketMath, use a spreadsheet pre-check to catch the issues that most often cause allocation outputs to be wrong (or to fail). This spreadsheet-checker step is designed to verify that your inputs align with Illinois’ general statute of limitations (SOL) rules—so you don’t allocate damages that are plainly time-barred.

Illinois SOL baseline the checker applies (general/default)

Illinois’ general limitations period for many civil actions is 5 years under:

• 720 ILCS 5/3-6 (general statute of limitations) — the default period used here, because no claim-type-specific sub-rule was identified in the underlying jurisdiction rules for this checker.

Common spreadsheet problems it detects

Use the checklist below as a mental model—these are the exact categories that typically break allocation math when SOL gating is introduced.

• Date field integrity

  • Missing incident/transaction date or filed/served date
  • Dates stored as text (e.g., 04/15/2023 typed as a string)
  • Inconsistent date formats across tabs

• Wrong “start date” for SOL math

  • Using a discovery date when your spreadsheet also includes an event date (or vice versa)
  • Pulling the start date from the wrong column after copying/pasting rows

• Unit and numeric consistency

  • Amounts entered as strings (e.g., "$12,500" instead of 12500)
  • Percent fields entered as 25 instead of 0.25 (or the opposite)
  • Mixed currency/amount scales across categories (thousands vs. dollars)

• Allocation logic alignment

  • Totals that don’t reconcile (category sums ≠ grand total)
  • Negative values where you expect only non-negative damages components
  • Percent allocations that sum to something other than 100% (or don’t match the calculator’s assumed basis)

• Rows that should be excluded

  • Claims marked “dismissed,” “settled,” or “not pursued,” but still included in totals
  • Docket entries duplicated due to repeated imports

Output signals you should watch for

After the checker runs, look for these practical indicators:

When to run it

Run the spreadsheet-checker at two high-leverage moments—once before you calculate anything, and once after you import or revise the dataset.

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.

1) Before running Damages Allocation

Do it immediately after you assemble the spreadsheet and before you generate allocation outputs. This catches:

• SOL gating errors (e.g., a date column accidentally copied from the wrong sheet)
• numeric parsing problems that would quietly distort allocations

2) After any data import or structural change

Trigger a re-check if you:

• add new rows (new allegations, incidents, or damages categories)
• change column names or rearrange tabs
• refresh from a docket export or CSV

A good operational rule:

• Run check #1 right after the data lands in your working sheet.
• Run check #2 right before finalizing allocation outputs for review.

What SOL the checker uses (so you can audit quickly)

The checker’s timing decision is anchored to the Illinois 5-year default SOL under 720 ILCS 5/3-6 (general/default period). In other words, if your spreadsheet’s relevant date pairing indicates more than 5 years have elapsed under the checker’s timing inputs, the row is treated as out of the baseline SOL window.

Try the checker

You can run the Damages Allocation workflow in DocketMath here: /tools/damages-allocation.

If you’re using this post as a process guide, follow a tight workflow:

• Step 1: Confirm your spreadsheet has one clear “start” date column and one clear “comparison” date column.
• Step 2: Ensure amount fields are numeric (no currency symbols, no stray commas).
• Step 3: Confirm allocation fields (percentages or weights) follow one consistent scale.
• Step 4: Run the spreadsheet-checker and review flags:

  • any SOL range alerts
  • any date parse failures
  • any totals/percent reconciliation problems
• Step 5: Only then run Damages Allocation in DocketMath and reconcile totals back to your source data.

Inputs that most affect SOL outcomes

To prevent the two most common “SOL looks wrong” issues, verify these:

• The start date column you intend for SOL calculations
• The end/reference date column you intend for the comparison
• Whether the spreadsheet uses the same date basis for every row (no mixed sourcing)

Outputs that should change when you correct inputs

After you fix the flagged cells, expect these shifts:

• Rows previously marked out-of-SOL may become in-range if the corrected date moves within 5 years under the general baseline.
• Allocation totals should stabilize if numeric parsing and percent basis were previously inconsistent.
• Category reconciliation should improve once formulas reference the correct ranges.

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