Spreadsheet checks before running Damages Allocation in Arkansas

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Running Damages Allocation in Arkansas with DocketMath works best when your spreadsheet inputs are consistent, complete, and mathematically coherent. The Spreadsheet checker is built to catch common “garbage-in/garbage-out” problems before the damages-allocation calculator runs—especially when you’re aggregating multiple line items (for example: principal, interest, fees, and costs) into allocation buckets.

Here are the main categories of issues the checker is designed to flag:

• Date problems

  • Missing dates in any required date column (for example: incident date, accrual start/end, judgment date, depending on your sheet layout).
  • Invalid dates (for example: 02/31/2024) that spreadsheets may silently treat as blank/incorrect.
  • Out-of-order date ranges, such as an end date earlier than a start date—this can distort any time-window logic used by the allocation model.

• **Jurisdiction-aware limitations checks (Arkansas default)

  • The checker looks for time-based inputs that appear to fall outside Arkansas’ default/general statute of limitations (SOL) period.
  • Arkansas’ general default SOL is 6 years under Ark. Code Ann. § 5-1-109(b)(2).
  • No claim-type-specific sub-rule was found. That means this checker applies the general/default 6-year period rather than automatically switching timelines based on a claim category.

  Practical effect: if your sheet includes dates that are “close but wrong,” the allocation outputs can become internally inconsistent because the SOL-based window may include/exclude amounts differently than you intended.

• Arithmetic and structure errors

  • Text where numbers are expected, such as currency values stored as strings (e.g., "$12,500" instead of a numeric 12500).
  • Totals that don’t tie to components, such as a “Total damages” line that doesn’t equal the sum of principal/interest/fees/costs lines.
  • Duplicate rows (often caused by copy/paste), which can inflate totals and skew allocation results.

• Allocation integrity issues

  • Percentages not summing correctly, such as allocation weights that don’t add up to 100% (or don’t match your model’s expected convention).
  • Negative allocations when the model expects non-negative amounts.
  • Unassigned remainder, such as percentages summing to 97% (leaving 3% nowhere to go), which can cause mismatched bucket totals.

Quick takeaway: The checker doesn’t only warn you that something is off—it aims to point to the specific rows/columns most likely responsible, so you can correct the inputs rather than guessing after outputs are produced.

When to run it

Run the Spreadsheet checker whenever you want to reduce the chance that formatting issues, missing data, or inconsistent totals will distort the allocation. A good workflow is to check at the highest-risk moments—before outputs become costly to fix.

Use these timing triggers:

1. Before you run Damages Allocation

   • This is the best first step: import or paste damages line items, then run the checker before allocation.

2. After you update any date columns

   • Date edits are one of the most common causes of subtle SOL/window mismatches.
   • If you change even one date field, rerun the checker so you can catch out-of-order ranges or missing/invalid dates early.

3. **After you revise line items (even small ones)

   • Adding or changing a component amount (e.g., expert fees, interest, costs) can affect:

     • arithmetic totals, and
     • any time-based logic that depends on the dated nature of inputs used in the allocation model.

4. Before exporting or sharing results

   • Do a final “sanity pass” so the values you share or file reflect the intended spreadsheet logic.

Arkansas SOL context your checker applies

Because this checker uses Arkansas’ general/default SOL, it applies the 6-year period from Ark. Code Ann. § 5-1-109(b)(2) when evaluating whether time-based inputs appear out of range.

• It does not automatically select alternative SOL periods by claim type.
• This is because no claim-type-specific sub-rule was found for this process.

Not legal advice. This is a spreadsheet validation workflow to help reduce calculation and input errors; for case-specific legal assumptions, confirm separately.

Try the checker

You can try the workflow by starting at the Damages Allocation entry point and running the Spreadsheet checker first.

• Go to: /tools/damages-allocation
• Run the Spreadsheet checker step
• Fix any flagged items it highlights
• Re-run Damages Allocation to see how outputs change

Fast input checklist (aim for “green”)

To get to clean inputs quickly, verify:

How outputs typically change after fixes

When the checker helps you correct inputs, allocation results usually shift in one or more of these ways:

• Included vs. excluded time-based amounts

  • If corrected dates move activity inside/outside the 6-year default window under Ark. Code Ann. § 5-1-109(b)(2), the allocation may increase or decrease the portions tied to those dates.

• Redistributed bucket splits

  • If percentages/weights were wrong, fixing them changes how total damages are distributed across allocation buckets.

• Reconciled totals

  • Fixing numeric formatting (e.g., string → number) often changes totals significantly because spreadsheets may previously have ignored or misread values.

If you’re testing, make one controlled change at a time (for example, correct a single date or convert one currency column to numeric), then rerun the checker and allocation. This makes it easier to see exactly what the model is sensitive to.

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