Common Damages Allocation mistakes in Arizona

The top mistakes

Run this scenario in DocketMath using the Damages Allocation calculator.

Damages allocation in an Arizona case can fail for reasons that look “administrative,” but they often decide which numbers the parties can credibly support. Below are common mistakes teams make when they run calculations in DocketMath using Arizona (US-AZ) jurisdiction-aware rules—especially when the case involves time-based damages or multiple damage categories.

1) Using the wrong statute of limitations (SOL) window

A frequent failure is filtering or computing damages over the wrong time span. In Arizona, the general/default SOL period is 2 years under A.R.S. § 13-107(A).

When teams assume a different period for a specific claim type without verifying, they can accidentally include damages from months (or years) that fall outside the operative window.

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

Important modeling rule for this article: The brief states that no claim-type-specific sub-rule was found, so DocketMath should treat the general/default 2-year period as the governing assumption unless case-specific authority indicates otherwise.

2) Mixing “date of event” vs. “date of filing” vs. “date of discovery”

Another common allocation error is inconsistent date selection. Even in a straightforward damages model, the output changes sharply depending on which date you use as the start/end of the eligible period.

Typical error patterns:

• Start date pulled from the incident date, but the model uses filing date as the end date (or vice versa) without a clear eligibility rule.
• Discovery date used in one category and not another.
• A single global date applied to all categories despite differing evidence.

3) Applying SOL reduction after the fact (instead of as an input rule)

Teams sometimes compute full damages first, then “subtract” what they believe is time-barred. That can create avoidable inconsistencies—especially if you later revise inputs, categories, or daily/period rates.

In DocketMath, the cleaner approach is:

• feed the correct eligible date range into the calculator up front, and
• keep category-level logic aligned with that same eligible window.

4) Incorrectly aggregating categories with different measurement units

Allocation breaks when categories don’t share units but are combined as if they do.

Examples:

• One category modeled as a monthly amount but treated as a daily amount.
• Another category modeled as a flat fee but spread across time by error.
• Service-life or rate assumptions accidentally reused across categories.

This often happens when the calculator output is “close enough” numerically, masking the unit mismatch.

5) Double-counting the same component across categories

A classic bookkeeping error:

• the same loss component appears both as part of “direct damages” and again as “consequential damages,” or
• the model includes both “past damages” and a “total damages” figure that already includes past amounts.

DocketMath can help if you explicitly separate:

• each input component, and
• each output category target.

6) Assuming Arizona SOL rules automatically apply the way you expect for every claim label

Because damages allocation depends on what is actually being claimed and how it’s pleaded, teams sometimes rely on claim labels as a proxy for the SOL rule.

For purposes of this jurisdiction snapshot, you’re using only the general/default SOL period referenced via A.R.S. § 13-107(A). If a case involves special pleading or special statutory schemes, the “default” may not match reality—so the allocation should be grounded in operative authority reflected in the record.

How to avoid them

If you’re using DocketMath to run Arizona (US-AZ) damages allocation, you can reduce mistakes by tightening inputs, keeping date logic consistent, and aligning category math with measurement units.

Open DocketMath here: /tools/damages-allocation

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

1) Lock the SOL window to Arizona’s general/default rule (2 years)

Because no claim-type-specific sub-rule was found in the provided jurisdiction snapshot, model Arizona using the general/default 2-year period:

• Governing SOL assumption: 2 years
• Statute: A.R.S. § 13-107(A)
• Reference note: treat this as default unless you have case-specific authority indicating a different period

In DocketMath, this typically means:

• selecting the eligible start date so the calculation range does not exceed the 2-year window, and
• ensuring the eligible end date is consistent across categories.

2) Choose one explicit date logic and reuse it across categories

Pick one rule set and apply it uniformly. A common pattern is to treat “eligible damages” as those counted only between your chosen [start date] and [end date] under the SOL model.

Checklist:

3) Prevent unit drift by normalizing rates and amounts

Before you run the calculation, normalize:

• daily vs. monthly vs. flat amounts
• start-of-period vs. end-of-period assumptions
• whether a “rate” is already included in a “total”

Practical workflow:

4) Use DocketMath category boundaries to avoid double-counting

Create a clear mapping:

• Direct damages: separate inputs
• Consequential damages: separate inputs
• Fees/costs: separate inputs (only if your workflow models them that way)

Then verify:

5) Keep revisions consistent—update inputs, not just outputs

When new facts arrive (e.g., a revised event date), avoid “hand edits.” Instead:

• re-run DocketMath with updated date inputs,
• re-check category subtotals, and
• confirm the SOL-filtered eligibility range changed as expected.

6) Document the governing rule used for the allocation run

Even without providing legal advice, you can improve modeling transparency by recording:

• the SOL assumption used (general/default 2-year period),
• the statute citation: A.R.S. § 13-107(A),
• the eligibility date window selected in DocketMath.

Pitfall to avoid:

If you select an SOL window that implicitly exceeds the 2-year default while citing A.R.S. § 13-107(A), your allocation can become internally inconsistent—especially if someone later audits category-level date filtering.

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