How to calculate Settlement Allocator in Nevada

Quick takeaways

Run this scenario in DocketMath using the Settlement Allocator calculator.

• In Nevada, the “settlement allocator” calculation in DocketMath is about how you distribute settlement proceeds across claims/time horizons—it doesn’t change Nevada’s substantive rights or whether a claim is legally valid.
• Nevada’s general statute of limitations (SOL) is 2 years under NRS § 11.190(3)(d), and this 2-year default applies unless a different, claim-type-specific SOL governs.
• If you use DocketMath to allocate based on when facts accrued or when key events occurred (notices, contracts, turnover/refusal events), your results depend heavily on getting your dates and claim groupings consistent.
• The most common Nevada allocation errors are:

  • using the wrong SOL assumption (treating the 2-year default as claim-type-specific),
  • mixing accrual dates across claim buckets (apples-to-oranges timing),
  • and forgetting that the 2-year rule is a general/default baseline.

Inputs you need

Before you run DocketMath’s settlement-allocator for Nevada (US-NV), gather inputs that let you allocate settlement value in a jurisdiction-aware way.

Use this intake checklist as your baseline for Settlement Allocator work in Nevada.

• jurisdiction selection
• key dates and triggering events
• amounts or rates
• any caps or overrides

If any of these inputs are uncertain, document the assumption before you run the tool.

A. Settlement and allocation structure

• Total settlement amount (for example, $850,000)
• Number of buckets you want to allocate across (for example: “timely vs. time-barred,” “damages category A vs. B,” or “period 1 vs. period 2”)
• Claim mapping: which claims (or which portions of damages) belong in each bucket

B. Date inputs (Nevada SOL-aware)

Because Nevada’s general/default SOL is 2 years under NRS § 11.190(3)(d), you’ll typically need:

• Accrual date(s) or trigger date(s) for each claim/bucket

  • If you have multiple accrual dates, allocate per claim group and then aggregate.
• Settlement date (or your chosen “as-of” date for the model)
• Key milestones your model uses as proxies for accrual (for example: last day of conduct, last invoice date, last refusal date)

C. Optional weighting inputs (if you use them)

Depending on how you configure the allocator, you may also provide:

• Weights by claim strength (if you model uncertainty)
• Weights by damages type (if you have a damages breakdown)
• Probability factors (if you adjust allocations for likelihood of recovery)

Keep in mind: if you later apply probability factors, make sure they aren’t duplicating the same “SOL risk” concept already reflected in your timeliness split.

How the calculation works

DocketMath’s settlement-allocator workflow turns your inputs into an allocation output. The Nevada “jurisdiction-aware” part is primarily the SOL window applied during allocation.

DocketMath applies the Nevada rule set to the inputs, then runs the calculation in ordered steps. It validates the trigger date, applies rate or cap logic, and produces a breakdown you can audit. If you change any one variable, the tool recalculates the downstream outputs immediately.

1. Apply Nevada’s general/default SOL window

For Nevada, the relevant default SOL period is:

• General SOL period: 2 years
• **Statute: NRS § 11.190(3)(d)
• Source: https://law.justia.com/codes/nevada/chapter-11/statute-11-190/

How it affects your allocation:

• If your allocator separates timely vs. time-barred exposure, then any claim/bucket whose accrual date falls more than 2 years before the settlement “as-of” date will typically be treated as outside the general/default SOL period.
• If your allocator uses SOL more like a scaling factor (graded reduction rather than a strict cutoff), the 2-year window still anchors how the allocation changes as time moves further away from the SOL expiration.

Important: The 2-year period is the general/default SOL. If a specific claim has a different SOL, you should substitute that claim-specific SOL in your mapping/logic instead of applying NRS § 11.190(3)(d) automatically.

2. Compute a SOL “timeliness” measure for each bucket

For each bucket (or each mapped claim group), the allocator compares:

• Days from accrual to the as-of date (settlement date or your model’s as-of date) vs.
• the 2-year window (Nevada default)

A common “timeliness” approach is:

• Timely: accrual is within 2 years
• Time-barred (general default): accrual is more than 2 years before the as-of date

Depending on configuration, you may get:

• a binary split (timely vs. time-barred), or
• a graded split (proportional reduction as you go further beyond 2 years)

3. Allocate settlement dollars across buckets

After DocketMath assigns each bucket a timeliness factor (binary or scaled), it distributes the settlement total.

Common internal allocation patterns include:

• Proportionate to timeliness weights

  • Example: Bucket A has weight 0.8 and Bucket B has weight 0.2 → Bucket A gets 80% of the amount allocated across those buckets.
• Proportionate to your damages mix, then adjusted by timeliness

  • Example: You input an initial damages breakdown; DocketMath then adjusts by the timeliness factor.

To keep results defensible:

• Use one consistent as-of date across all buckets.
• Use one definition of “accrual” (or document your approximation) per bucket type.

4. Sanity-check outputs against the Nevada SOL anchor

After running the allocator, verify the results match the intended SOL logic.

Quick checks:

• If all accrual dates are within 2 years of the as-of date, you shouldn’t see major shifts of value into a “time-barred” bucket.
• If one bucket’s accrual dates are clearly older by multiple years, that bucket’s allocated share should decrease (binary or graded).

DocketMath supports iteration: adjust dates (only when necessary), re-run, and compare how allocation shifts.

Common pitfalls

Even a well-prepared case can produce misleading outputs. These are the biggest issues for Nevada allocations using the general/default SOL.

• missing a required input
• using a stale rate or rule
• ignoring calendar or holiday adjustments
• skipping documentation of assumptions

1. Treating NRS § 11.190(3)(d) as claim-type-specific

Nevada’s 2-year rule in NRS § 11.190(3)(d) is the general/default baseline. If a claim category has a different SOL, the allocator should reflect that instead.

2. Inconsistent accrual triggers across buckets

If one bucket uses “last day of conduct” as accrual, while another uses “first denial,” your timing comparisons become apples-to-oranges.

Prevent it with:

• Same accrual definition across buckets you compare
• Clear documentation of whether accrual is event-based, invoice-based, or refusal-based
• Consistent date/timezone conventions

3. Mixing settlement date and as-of date

If you input:

• execution date in one run, but
• payment date (or a later as-of date) in another,

then the 2-year cut can change the allocation substantially.

Best practice:

• Pick one as-of date for the model.
• Re-run only when you intend to change that as-of date.

4. Assuming allocation determines liability

Settlement allocation outputs are usually for internal reporting, tax allocation support, claims administration, or settlement processing. They do not replace a legal determination of validity, enforceability, or entitlement.

Gentle disclaimer: Use the calculator as a structured allocation model; a qualified professional should evaluate any legal consequences of classifications.

5. Overweighting probability factors (double-counting risk)

If you add probability weights, ensure they aren’t compensating for the same risk already reflected through SOL/timeliness.

Quick control:

• Run once with only SOL/timeliness.
• Run again with probability weights.
• Compare deltas to confirm the probability layer adds insight rather than duplicating reductions.

Sources and references

• Nevada Revised Statutes: NRS § 11.190(3)(d) (general SOL period of 2 years)
  https://law.justia.com/codes/nevada/chapter-11/statute-11-190/

Start with the primary authority for Nevada and confirm the effective date before relying on any output. If the rule has been amended, update the inputs and rerun the calculation.

• Primary authority reference

Next steps

1. Open the tool: /tools/settlement-allocator
2. Enter:

   • total settlement amount
   • your bucket structure
   • accrual dates per bucket
3. Select the Nevada (US-NV) jurisdiction-aware setting that uses the general/default 2-year SOL from NRS § 11.190(3)(d).
4. Run and verify:

   • Identify which buckets fall inside vs. outside the 2-year window
   • Confirm the as-of date used is consistent
   • If dates are uncertain, adjust and re-run to see how sensitive results are
5. If any claim might not follow the general default, re-check your mapping before finalizing the model (use the correct SOL rather than relying only on the 2-year baseline).

Related reading

• Settlement Allocator Guide for Alabama
• Settlement Allocator Guide for Arizona
• Settlement Allocator Guide for Colorado