How to run Damages Allocation in DocketMath for Arizona

Step-by-step

Run this scenario in DocketMath using the Damages Allocation calculator.

This guide walks you through running Damages Allocation in DocketMath for Arizona (US-AZ), using jurisdiction-aware rules. DocketMath uses the jurisdiction profile to apply the general/default statute of limitations (SOL) when it’s the controlling rule for your scenario.

1) Open the calculator

1. Go to DocketMath’s Damages Allocation tool here: /tools/damages-allocation
2. Confirm your jurisdiction context shows Arizona (US-AZ).

   • If there’s a jurisdiction selector, choose US-AZ.

2) Add the parties and timeline inputs

Damages Allocation typically depends on who is owed/liable and when the relevant events occurred. Enter the dates that the UI requests, such as:

• Key event / claim initiation date(s) (for example, incident date or date the claim accrued—use whatever label matches your workflow)
• Filing date (or the date you’re modeling against)
• Any additional date fields the UI requests (for example, “discovery,” “last payment,” or “termination,” if present)

What to watch in Arizona: the calculator will treat the limitation window as 24 months (2 years) based on the jurisdiction profile.

3) Select allocation/damages components (if prompted)

If DocketMath lets you split damages into buckets, choose the categories that match your workflow.

For each category:

• Enter the amount (or range, if supported)
• Use any include/exclude toggles to control what the allocation logic should consider

How outputs change: the limitations-window logic can affect which portions are included or flagged. For example, amounts tied to time periods outside the limitations window may be reduced, excluded, or reported with warnings—depending on how the tool displays the results.

4) Run the calculation

Click Calculate (or the tool’s equivalent).

DocketMath will generate:

• An allocation breakdown across your selected categories and/or time slices (based on the tool’s structure)
• A limitations-window result applying Arizona’s general 2-year SOL
• Any warnings surfaced by jurisdiction-aware logic

5) Review the limitations-window logic

After the results load, locate the section summarizing the SOL logic (it may appear as a “Jurisdiction rules” panel, a “SOL check,” or a “Limitation window” summary).

For Arizona in this workflow, you should see:

• General SOL: 2 years
• Statute citation: **A.R.S. § 13-107(A)
• No claim-type-specific exception applied (because this run uses the general/default period)

6) Adjust inputs and re-run to compare outcomes

To model “what if” scenarios, change one variable at a time:

• Adjust the filing date by a few days/weeks to see boundary effects near the 2-year mark.
• Update the key event date if you’re testing a different accrual assumption in your dataset (avoid legal advocacy—this is just modeling).
• Toggle or modify damages categories included to see how allocation shifts.

Practical approach: run 2–3 scenarios:

• Run A: earliest plausible date
• Run B: your primary assumed date
• Run C: latest plausible date

This gives you a quick sensitivity view around the 2-year SOL window.

7) Export or capture results

If DocketMath provides download/print options:

• Export the output (CSV/PDF, if available)
• Save screenshots of the SOL summary and the allocation table

If the tool includes an “audit trail” style view, capture it too—jurisdiction-aware calculators are most useful when you can clearly explain why numbers changed between runs.

Common pitfalls

Watch for these issues when running Damages Allocation in Arizona:

• Using the wrong SOL rule in the model

  • For this calculator run, the applicable rule is Arizona’s general/default SOL: 2 years under A.R.S. § 13-107(A).
  • No claim-type-specific sub-rule was identified for this workflow, so the calculator shouldn’t swap to a different limitation period unless you change the jurisdiction/rule settings that govern the run (if the UI provides such settings).

• **Date mix-ups (the #1 driver of SOL outcomes)

  • Entering incident/claim/accrual date as the filing date, or vice versa, can flip results from “within window” to “outside window.”
  • If the tool asks for multiple dates, make sure each date goes into the correct field label.

• Forgetting to rerun after changing categories

  • If you toggle damages components on/off and don’t click Calculate again, you may interpret stale totals.
  • Always recalculate after editing inputs.

• Treating outputs as legal conclusions

  • DocketMath results are best understood as calculation outputs for workflow analysis, not legal advice.
  • Use the statute citation and SOL summary as modeling inputs/outputs, and keep your internal documentation consistent.

Pitfall to keep in mind: if your key date lands close to the 2-year boundary, small data-entry differences (even a month) can change what portion of damages falls inside vs. outside the 2-year window under the general SOL logic.

Try it

Use this quick checklist for a first run:

• SOL period: 2 years
• **Authority: A.R.S. § 13-107(A)
• General/default period applied (no claim-type-specific exception found for this run)

To sanity-check your output:

• Review the limitations-window summary to ensure the comparison is using your dates as intended.
• If your allocation seems unexpectedly low or reduced, the most likely reason is that the calculator is excluding or limiting portions tied to periods outside the 2-year window under the general SOL 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