Worked example: Structured Settlement in Arizona

6 min read

Published April 15, 2026 • By DocketMath Team

This article is for informational purposes only and does not constitute legal advice. Laws change frequently — verify all citations with current official sources.

Example inputs

This worked example shows how DocketMath’s structured-settlement calculator applies Arizona’s general criminal statute of limitations when you’re working with a structured settlement schedule that creates multiple payment dates.

Before you run the numbers, two jurisdiction facts matter for this demo:

Arizona general SOL period (criminal): 2 years
General statute: A.R.S. § 13-107(A) (general/default limitations period)

Also, the jurisdiction dataset for this example indicates no claim-type-specific sub-rule was found. That means this demo uses the general/default 2-year period (rather than a different, claim-type-specific carve-out). In other words, the example below assumes the same 2-year limitations window applies for the scenario modeled here.

Note: Structured settlements typically involve a sequence of scheduled payments. Statute of limitations analysis can turn on timing, and structured schedules can include multiple “trigger-like” dates you may want to compare. This example focuses on how DocketMath handles timing inputs and comparisons, not on every legal nuance that could arise in real situations. For actual case strategy, consult a qualified attorney.

Scenario (for calculation)

Assume a claimant is modeling a structured settlement with payments that begin after a settlement agreement is signed. The practical question the calculator is modeling is:

If the complaint/filing is measured from a selected “start date,” does the filing date fall within Arizona’s general 2-year SOL window?

DocketMath helps you model that timing consistently across multiple payment dates—useful when you want a timeline view rather than doing ad hoc date arithmetic.

Inputs used in this example

Run these through DocketMath’s structured settlement tool: /tools/structured-settlement .

Input	Value in this example	Why it matters
Jurisdiction	US-AZ	Applies Arizona general SOL rules (A.R.S. § 13-107(A))
General SOL period	2 years	Baseline default window (since no claim-type-specific rule was found)
Start date (measured from)	2024-01-15	The “clock start” date for comparing deadlines
Payment 1 date	2024-06-15	First modeled comparison point on the timeline
Payment 2 date	2025-06-15	Second modeled comparison point on the timeline
Payment 3 date	2026-06-15	Stress-tests how payment timing lands relative to the 2-year mark
Payment cadence logic	Annual after first payment	Keeps the demo schedule simple and repeatable
Filing date to test	2026-01-20	A single filing/test date used for the window “inside vs. outside” comparison

Example run

DocketMath’s structured-settlement calculator is effectively checking the same baseline idea each time:

Given a 2-year SOL from the selected start date under A.R.S. § 13-107(A), does the tested filing date fall inside or outside the limitations window? It then helps you view how each modeled payment date lines up relative to that same baseline deadline.

Step 1: Compute the baseline 2-year deadline from the start date

Start date: 2024-01-15
2-year end date (baseline deadline): 2026-01-15

This baseline matters because the jurisdiction data in this demo indicates the calculator should use the general SOL period as the default when no claim-type-specific rule is identified.

Step 2: Compare the test filing date to the baseline

Filing date: 2026-01-20
Baseline deadline: 2026-01-15

Result:

2026-01-20 is after 2026-01-15, so the filing date falls outside the general 2-year SOL window.

Step 3: Evaluate modeled payment dates against the same baseline window

The structured settlement timeline view is useful when you want to see how scheduled payments “line up” with the limitations deadline. Using the same baseline deadline (2026-01-15):

Payment date	Position relative to 2-year deadline (2026-01-15)	Interpretation for timing comparison
2024-06-15	Before deadline	Inside the general SOL window
2025-06-15	Before deadline	Still inside the window
2026-06-15	After deadline	Outside the general SOL window

Even though the modeled payments span multiple years, the key baseline is anchored to the start date selected for the limitations analysis. Payment dates are timeline data points that help you visualize timing relationships, but in this demo setup, the filing date vs. baseline deadline is what determines the inside/outside outcome.

Output you should expect conceptually in DocketMath

Depending on the exact UI, DocketMath typically provides outputs like:

A computed SOL deadline (start date + 2 years)
A within/outside determination for the tested filing date
A timeline mapping each payment date relative to the deadline

In this example, the expected core results are:

**Filing date: Outside general SOL (by 5 days)
Payments 1 and 2: Inside the general SOL timeline
Payment 3: Outside the general SOL timeline

Sensitivity check

Small changes to inputs can materially affect results—especially when dates are near the boundary. This sensitivity check shows how the result can change when you adjust key dates.

To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.

Sensitivity A: Move the filing date earlier by 10 days

New filing date: 2026-01-10
Baseline deadline remains: 2026-01-15

Expected shift:

2026-01-10 is within the general 2-year window
The calculator’s “outside/inside” determination flips from outside to inside

This is a classic boundary effect: a small adjustment can reverse the outcome.

Sensitivity B: Keep filing date fixed; move the start date later by 1 month

Filing date stays: 2026-01-20
New start date: 2024-02-15
New baseline deadline: 2026-02-15