Spreadsheet checks before running Damages Allocation in Arizona

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Running a Damages Allocation spreadsheet in Arizona is only as reliable as the inputs you feed it. Even if DocketMath’s Damages Allocation calculator looks straightforward, spreadsheet structure issues (like date fields stored as text, shifted columns, or missing values) can silently distort results.

The spreadsheet checker is built as a pre-flight validation step—so you can catch common problems before you run the calculation.

Here’s what the checker helps validate for Arizona (US-AZ), using the jurisdiction-aware default/general timing rule for limitations:

• Blank or malformed date fields

  • Checks for missing “incident/date of accrual” (or your model’s equivalent) and for date fields that aren’t valid dates (for example, invalid formatting or unparseable entries).

• **SOL gating errors (default/general rule)

  • Applies the general/default SOL period of 2 years.
  • This is grounded in A.R.S. § 13-107(A).
  • Important: Your brief did not identify any claim-type-specific sub-rule. Because none was found, the checker uses the general/default 2-year period rather than attempting specialized timing variants.

• Inconsistent timeline fields

  • Flags cases where timeline inputs don’t follow a logical order—such as a “filing date” that appears earlier than the “accrual/incident date” (unless your spreadsheet model explicitly supports that scenario).
  • Also checks for internal consistency across any additional trigger dates you track (for example, served date, payment dates—if present).

• Numeric field sanity checks

  • Detects negative damages (and highlights sign-convention issues), swapped entries, or non-numeric text in amount fields.
  • Helps avoid “looks right” inputs that actually break calculation logic.

• Allocation column integrity

  • Verifies that allocation buckets (or percentage columns) behave as expected for your spreadsheet model.
  • For percentage-based structures, it can highlight when totals don’t reconcile (for example, totals that don’t sum to 100%).

• Unit and currency mismatches

  • Helps catch cases where one part of your spreadsheet is in dollars and another part is in cents, or where a line item appears duplicated under inconsistent labels.
  • These issues can produce results that are numerically precise—but conceptually wrong.

Pitfall to watch: If your spreadsheet stores a date as a plain number (Excel serial date) or as text, the calculator may still compute something. But the SOL gate can flip from “in range” to “out of range,” which can change which damages components are treated as allowable—leading to a different allocation outcome.

Arizona SOL rule used by the checker (default/general)

The checker uses the general/default SOL period of 2 years based on:

• A.R.S. § 13-107(A) — general statute of limitations period of 2 years
  Source: https://www.findlaw.com/state/arizona-law/arizona-criminal-statute-of-limitations-laws.html?utm_source=openai

When to run it

Treat the checker like a pre-flight checklist. You’ll get the most value when you run it right as you move from spreadsheet inputs to the allocation calculation.

Run the checker in these situations:

• Before your first Damages Allocation run

  • Especially if you’re importing or assembling a model from prior cases, templates, or copy/pasted spreadsheets.

• After any timeline edits

  • Whenever you change:

    • incident/accrual date
    • filing-related date(s)
    • any other trigger/timeline fields that could affect SOL gating

• After adding, removing, or renaming allocation columns

  • Any spreadsheet structure change can break mapping (for example, a renamed column that no longer aligns with what the calculator expects, or shifted columns).

• After copying data across cases

  • Copy/paste is a common source of misalignment—especially with spreadsheet column order and hidden formatting differences.

A quick “run cadence” you can adopt

• Step 1: Run the spreadsheet checker immediately after importing your data.
• Step 2: Run again after you adjust dates or recalculate values.
• Step 3: Run a final time right before exporting or finalizing outputs.

Output impact: what changes when checks fail

If the checker flags an issue, your allocation results may change in practical ways, such as:

• SOL gating

  • The tool may determine whether damages fall within an allowable timing window (“in range” vs “beyond SOL”), which can change which components are included in the allocation.

• Re-interpretation of amounts

  • If it detects unit/currency mismatches or swapped inputs, you may need to correct the underlying values before the allocation distribution can be trusted.

• Allocation totals

  • If allocation buckets don’t reconcile (for example, percentages not summing as expected), the calculator may distribute amounts incorrectly.

Note: This is not legal advice. It’s a data-integrity guardrail to help you avoid spreadsheet-driven errors.

Try the checker

You can run the checker as part of the workflow here: /tools/damages-allocation

When you open the Damages Allocation tool, use a checker-first approach:

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

Inputs to prepare (Arizona-aware)

To get the best validation results, make sure your spreadsheet has clean values for:

• Accrual/incident date (or the equivalent field your model uses)
• Filing-related date (the date you compare against the SOL timing rule)
• Damages amounts

  • total damages (if applicable)
  • any breakdown buckets you allocate (past/future, categories, or other grouping)
• Allocation structure

  • consistent column labeling that matches the model’s expected inputs

What to look for in the checker results

Use the checker output to confirm:

• Dates parse correctly

  • No blanks; no text-based dates where dates are required.
• SOL comparison uses the default 2-year rule

  • The checker applies the general/default 2-year period from A.R.S. § 13-107(A) (because no claim-type-specific sub-rule was found in the brief).
• Allocation columns and numeric fields are internally consistent

  • Percent totals reconcile (when your model uses percentages), and amounts align with the expected structure.

Quick troubleshooting checklist (fast wins)

When the tool reports issues, try these quick actions:

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