How to interpret Damages Allocation results in Arizona

6 min read

Published April 15, 2026 • By DocketMath Team

What each output means

Run this scenario in DocketMath using the Damages Allocation calculator.

If you ran DocketMath’s “Damages Allocation” calculator for an Arizona matter, the output is meant to (1) split a total damages number into allocation buckets (such as economic losses, noneconomic losses, and/or other components) and then (2) apply an Arizona-aware timeliness lens based on the general statute of limitations (SOL).

Because results depend on your inputs, start by confirming that the dates you entered in the tool (for example, incident/event dates and the date used as the “trigger” point in the calculator) match your case timeline.

Arizona SOL rule used in this workflow (general/default)

For Arizona, the calculator’s interpretation uses the general/default SOL period:

Important: No claim-type-specific sub-rule was found for the Damages Allocation logic here. That means you should treat the SOL portion of the output as applying the general/default 2-year rule unless you separately confirm a different limitations rule should control.

Disclaimer: This is for interpretation and workflow understanding, not legal advice. Limitations rules can be nuanced and may vary by claim and facts.

How to read the main output pieces

In practical terms, the Damages Allocation output typically communicates four ideas:

  1. Total allocated damages

    • This is the sum of the components/buckets after applying any allocation percentages, weights, or category parameters you selected.
  2. Component breakdown (allocation buckets)

    • Each bucket shows how the calculator distributed the overall number across the categories you configured.
  3. SOL impact (timeliness adjustment)

    • After the calculator applies Arizona’s 2-year general SOL logic under A.R.S. § 13-107(A), it reflects that impact when the triggering timeline suggests the matter is outside the limitation window.
  4. Net effect after SOL (“bottom line”)

    • This is the amount that remains once the SOL step is applied to the allocation model the calculator selected.

Quick reading strategy (most users find this fastest)

  • Step 1: Look at the Net / After SOL figure first—this is the result after the general Arizona SOL assumption is applied.
  • Step 2: Compare it to Pre-SOL / Total allocated damages (if shown) to see how much the timeline assumption changed the number.
  • Step 3: Review each bucket to identify whether the output changed mostly because of timing or because of allocation/category inputs.

Why the timeline matters under A.R.S. § 13-107(A)

Under A.R.S. § 13-107(A), the general SOL period used here is 2 years. In interpretation terms, you’re essentially asking:

  • Did the triggering event date fall more than 24 months before the calculator’s date reference point?
  • If yes, the calculator’s SOL adjustment step will reduce (or potentially disallow) the portion it treats as untimely—depending on the specific allocation logic selected in the tool.

Because this workflow uses a general/default rule (not a claim-specific sub-rule), treat the SOL-sensitive “net” result as scenario-based: it is only as accurate as your assumption that this general 2-year period governs your situation.

What changes the result most

In most Damages Allocation runs for Arizona (using the general 2-year SOL baseline under A.R.S. § 13-107(A)), the biggest changes come from a small set of inputs.

These inputs have the biggest impact on the final number. Adjust them one at a time if you need a sensitivity check.

  • date range
  • rate changes
  • assumption changes

1) Date inputs (largest effect when crossing the 2-year line)

Small date changes can flip whether the SOL step treats portions as timely.

  • ≤ 2 years from triggering reference date: SOL adjustment is typically lighter.
  • > 2 years: SOL adjustment is typically heavier (and the Net after SOL drops more).

Verification tip: If your Net after SOL declines sharply compared to Total allocated damages, timing is likely driving the difference—not the damage category mix.

2) Allocation percentages / component weights (largest effect when dates are the same)

Even if the SOL treatment stays the same, category inputs change how the calculator allocates the total into buckets.

Examples of inputs that commonly drive differences:

  • economic vs. noneconomic splits
  • “other” components
  • any user-selected weighting/multiplier parameters

Verification tip: If you rerun with the same dates but different allocations, the component breakdown should change first; the net figure will follow based on how the tool treats those buckets under its SOL adjustment approach.

3) Which buckets are effectively “adjusted” in the calculator

Some configurations adjust:

  • the entire total once SOL applies, or
  • only certain buckets, depending on tool settings.

So, two runs with identical dates and totals can still differ if you change which categories the tool is set to treat as SOL-sensitive (if that option exists in your run).

4) Whether the calculator is using the general/default SOL rule

This workflow is designed around the general/default 2-year period under A.R.S. § 13-107(A), with no claim-type-specific sub-rule identified for this logic.

Warning: If your scenario is governed by a different limitations rule than the general default, the Damages Allocation output may overestimate or underestimate the SOL impact.

Practical comparison checklist (use between runs)

What you changed between runsExpected biggest differenceHow to verify
Event date or trigger/reference dateSOL-adjusted (“net”) figureCompare before SOL vs after SOL
Allocation % for a bucketBucket totals and their sumCheck each bucket and the reported total
Which buckets are SOL-adjusted (if configurable)Net composition and net amountCompare “After SOL” by bucket

Next steps

To use the Damages Allocation output responsibly (and avoid surprises), follow these practical steps:

  1. Reconcile the timeline you entered
    Confirm your event/date inputs match what you believe the calculator treats as the start vs. trigger/reference point.

    • If you are near the 2-year threshold, consider rerunning a scenario only if you can support an alternative justified date basis.
  2. Audit category/bucket inputs
    Review whether your economic/noneconomic/other buckets are set up the way you intend to characterize damages.

    • If the result feels “off,” it’s often allocation weighting rather than SOL timing.
  3. Diagnose whether SOL is the driver
    Compare:

    • Total allocated damages (pre-SOL) vs.
    • Net after SOL (post-SOL).
      If the gap is small, timing may not be the major factor. If it’s large, the general 2-year rule under A.R.S. § 13-107(A) is likely doing most of the work in the calculator’s logic.
  4. Document what you assumed
    Save the calculator settings and outputs so you can compare versions later (e.g., different dates or different allocation models).

If you want to rerun with consistent jurisdiction-aware assumptions, start at /tools/damages-allocation.

Related reading