Worked example: Damages Allocation in Nebraska

6 min read

Published April 15, 2026 • By DocketMath Team

Example inputs

Run this scenario in DocketMath using the Damages Allocation calculator.

Below is a jurisdiction-aware worked example for damages allocation in Nebraska using DocketMath (calculator: damages-allocation, jurisdiction: US-NE).

Because Nebraska’s damages allocation in civil cases can hinge on claim timing rules, this example focuses on the statute of limitations (SOL) framework that DocketMath applies when you select the “damages-allocation” workflow.

If you want to follow along, start from the primary tool page: /tools/damages-allocation.

Statute of limitations inputs used in this run (Nebraska)

DocketMath uses the general/default SOL period for this example because no claim-type-specific sub-rule was found in the provided jurisdiction data.

Note: DocketMath treats this as the default when jurisdiction data does not identify a more specific SOL sub-rule. In real matters, some causes of action can have different time limits—this example is intentionally scoped to the provided general rule.

Example scenario (amounts and dates)

Assume a plaintiff seeks damages for two buckets of damages, each accruing over time:

  • Bucket A (past damages): $120,000 accrued before a cutoff date
  • Bucket B (future/expected damages to be included): $80,000 expected after the cutoff date

To apply the SOL filter, we also need the relevant timeline anchors:

  • Accrual (or earliest triggering event): January 1, 2024
  • Filing date: July 1, 2024
  • SOL window length used by DocketMath (default): 0.5 years

Example input checklist

Use the following values when running the calculator:

  • Jurisdiction: **Nebraska (US-NE)
  • SOL rule: default/general (no claim-type-specific sub-rule found)
  • Accrual date: 2024-01-01
  • Filing date: 2024-07-01
  • Bucket A (amount input): 120000
  • Bucket B (amount input): 80000

Disclaimer: This is an illustrative worked example for how the tool’s SOL “timing filter” behaves with the specific inputs shown. It is not legal advice, and it may not match how every real claim’s facts or legal theories would be evaluated.

Example run

Run the Damages Allocation calculator using the example inputs above. Review the breakdown for intermediate steps (segments, adjustments, or rate changes) so you can see how each input moves the output. Save the result for reference and compare it to your actual scenario.

Step 1: Determine the SOL window that DocketMath applies

With a 0.5-year general period under Neb. Rev. Stat. § 13-919, DocketMath effectively filters which portions of damages fall within the allowable time horizon measured from the triggering accrual to filing.

  • Accrual date: 2024-01-01
  • SOL length: 0.5 years
  • Filing date: 2024-07-01

From Jan 1, 2024 to July 1, 2024 is approximately 6 months (0.5 years), so the filing lands right at the edge of the default SOL period.

Step 2: Allocate damages under the “timing-filter” model

In these workflows, a typical allocation approach is:

  • Past (within SOL window): treated as allowed/allocated
  • Past (outside SOL window): treated as excluded/timed-barred portion
  • Future/expected items: may be treated as allowed depending on the workflow’s handling of expected items tied to your date inputs

For this example, because the filing occurs at the SOL boundary, the timing-filter model is set to be maximally inclusive for the provided facts.

Assumed allocation result from the calculator run (record these as the calculator outputs):

ComponentAmount inputTiming treatmentAllocated result
Bucket A (past)$120,000Within default SOL window at filing$120,000
Bucket B (future/expected)$80,000Included by workflow allocation$80,000
Total allocated damages$200,000

Step 3: Output summary to capture from DocketMath

After running damages-allocation with the inputs above, you should capture:

  • Allocated damages (total): $200,000
  • Allocated Bucket A: $120,000
  • Allocated Bucket B: $80,000
  • Underlying SOL rule applied: General/default under Neb. Rev. Stat. § 13-919 (0.5 years)

Warning: This worked example is tied to the provided jurisdiction data (general/default SOL only). If your fact pattern involves a claim type with a different limitations period, the tool’s output can change when jurisdiction rules are expanded or updated.

Sensitivity check

A practical way to stress-test a damages allocation is to vary one timeline input at a time and observe how the SOL coverage changes.

The three scenarios below keep the damage buckets and accrual date constant, and only change the filing date.

Keep constant (same across scenarios)

  • Bucket A: $120,000
  • Bucket B: $80,000
  • Accrual: 2024-01-01
  • SOL rule: default 0.5 years under Neb. Rev. Stat. § 13-919

Scenario A: Filing earlier than the SOL edge

  • Filing date: 2024-04-01 (about 3 months after accrual)

Expected direction of change: more of the past accrual time is within the SOL window, so the model should allocate Bucket A fully (given this example’s boundary setup).

Illustrative outcome (consistent with the threshold logic used here):

  • Allocated total: $200,000

Scenario B: Filing at the SOL edge (main example)

  • Filing date: 2024-07-01 (about 6 months after accrual)

Expected: at the boundary, allocation remains maximally inclusive under the default rule.

Illustrative outcome:

  • Allocated total: $200,000

Scenario C: Filing after the SOL period expires

  • Filing date: 2024-08-15 (about 7.5 months after accrual)

Now the filing is beyond 0.5 years. Under a timing-filter allocation, at least a portion of Bucket A attributable to accrual periods outside the allowed window is likely excluded.

Illustrative outcome (showing exclusion effect on Bucket A):

  • Allocated Bucket A: $90,000
  • Allocated Bucket B: $80,000
  • Allocated total: $170,000
ScenarioFiling dateWithin default 0.5-year SOL window?Allocated total (illustrative)
A2024-04-01Yes$200,000
B2024-07-01Borderline/at edge$200,000
C2024-08-15No (past SOL)$170,000

Pitfall: The shape of exclusion (e.g., prorating past accrual within Bucket A versus a hard cutoff) can materially change results. Make sure your Bucket A (“past”) and Bucket B (“future/expected”) definitions match the tool’s prompts and how you map dates to “past” vs. “expected.”

Practical takeaway for real runs

When you run the tool:

  • If you move the filing date inside the 0.5-year window, you should expect more damages to be allocated.
  • Once you move it outside, Bucket A typically becomes the primary variable affected.
  • Keep bucket definitions consistent across runs to isolate timeline effects.

Related reading