Spreadsheet checks before running Structured Settlement in Arkansas

What the checker catches

Run this scenario in DocketMath using the Structured Settlement calculator.

Running a Structured Settlement in Arkansas is often less about whether the payment structure is “allowed” and more about whether the underlying claim is still within the time window to be asserted. The DocketMath structured-settlement calculator can’t decide liability—but a spreadsheet-focused checker can help you avoid a common procedural failure: building settlement terms around claims that may be time-barred.

Use DocketMath spreadsheet checks before you finalize schedules to catch issues like these:

• Statute of limitations (SOL) mismatch

  • Arkansas’s general SOL period for many civil claims is 6 years.
  • This checker uses the general/default rule: Ark. Code Ann. § 5-1-109(b)(2) (general SOL period: 6 years).
  • Important: No claim-type-specific sub-rule was found for this workflow, so the checker treats 6 years as the default. If your case facts point to a different SOL theory, you’ll want to confirm that separately.

• Date-field defects that skew the SOL calculation

  • Missing or incorrectly formatted dates (for example, entering a “filing date” value into a “settlement date” cell).
  • Confusion over which “start” date your model uses:

    • incident date vs. accrual/trigger date (the date your team treats as when the claim accrued or became actionable in the model), and
    • filing date vs. demand/notice date (the “assertion” or comparison date used to test timeliness).

• Off-by-one logic errors

  • Spreadsheet formulas sometimes use “less than or equal to” (<=) where the intended comparison is strict (“<”).
  • That can move borderline timing into “allowed” vs. “barred” territory—exactly the kind of issue spreadsheet checks are meant to surface.

• Inconsistent “start date” and “end date” across tabs

  • Teams may compute SOL in one sheet but reuse a different date column in the structured settlement module.
  • The checker helps you detect when the settlement schedule is based on a different timeline than the one used to test timeliness.

• Term-sheet drift

  • If your settlement spreadsheet updates proposal dates without recalculating SOL flags, you can end up with:

    • stable math (annuity/present value calculations still running), but
    • outdated eligibility or timeline assumptions in the workflow.

Gentle disclaimer: This is a process and spreadsheet accuracy checklist, not legal advice and not a guarantee that a claim is legally viable. Use the output as a screening signal, then validate with case facts and the relevant procedural posture.

What the checker needs (inputs you should verify)

Before running, verify that your spreadsheet inputs align with your Arkansas SOL screening setup:

• SOL start date (your model’s chosen “accrual/trigger” date for the workflow)
• Relevant comparison date

  • typically the date the claim was filed, demanded, or otherwise asserted—depending on how your team defines “timely assertion” in the sheet
• Assumed SOL period

  • for this Arkansas workflow: 6 years under Ark. Code Ann. § 5-1-109(b)(2) (general/default)

The checker then evaluates whether the timeline implied by your chosen dates lands inside or outside that 6-year window—based on your chosen start date and comparison date logic.

When to run it

Timing matters. Run the checker when your spreadsheet is most likely to “go stale” or drift from reality:

1. Before you draft the structure

   • Run once your core dates are set (your chosen SOL start/accrual/trigger date and your assertion/comparison date), and before you lock in payment frequency, principal breakdown, or purchase timing.

2. After any timeline edits

   • If anyone changes the incident/accrual/trigger date, service date, demand date, or filing date, rerun immediately.

3. Before sharing settlement terms

   • When producing a counterparty or client term sheet, confirm the SOL assumption matches the spreadsheet’s date logic first.

4. When converting between spreadsheet versions

   • Exports/imports and template changes can alter:

     • date formats,
     • column mappings,
     • and worksheet references.
   • Rerun after version changes to avoid silent spreadsheet drift.

Quick decision checklist (use as a workflow gate)

If any box is unclear or “no,” rerun before proceeding.

Try the checker

You can run this workflow in DocketMath using the structured-settlement tool (primary CTA: /tools/structured-settlement):

1. Open DocketMath: Structured Settlement at /tools/structured-settlement
2. Enter (or confirm) the same timeline inputs that your spreadsheet uses:

   • the SOL start date in your model
   • the comparison/assertion date you’re measuring against
3. Confirm the SOL period used matches the Arkansas general/default rule:

   • 6 years under **Ark. Code Ann. § 5-1-109(b)(2)
4. Review the output:

   • If it indicates the timeline is outside the SOL window, treat it as a spreadsheet-process red flag for your modeled settlement timing.
   • If it indicates inside, treat it as a “date logic ok” result—not proof of ultimate claim viability.

How outputs change when inputs change (practical “what to look for”)

• Move the comparison/assertion date later
  The result can flip from “inside” to “outside.”
• Move the SOL start date earlier
  The window shifts, and the checker may flag “barred.”
• Use different date columns across tabs
  The checker’s consistency checks help reveal cases where:

  • the SOL screen tab uses one date set, but
  • the structured settlement schedule tab uses another.

For the fastest validation, run twice:

• once with your current dates, and
• once after a controlled one-variable test (e.g., move the SOL start date by 30–60 days) to confirm the checker responds as expected.

Related reading

• Structured Settlement Calculator Guide for Alabama
• Structured Settlement Calculator Guide for Arizona
• Structured Settlement Calculator Guide for Colorado