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.
- General SOL period: 0.5 years
- Neb. Rev. Stat. § 13-919 (general rule for certain civil actions)
Source: https://law.justia.com/codes/nebraska/chapter-13/statute-13-919/
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):
| Component | Amount input | Timing treatment | Allocated result |
|---|---|---|---|
| Bucket A (past) | $120,000 | Within default SOL window at filing | $120,000 |
| Bucket B (future/expected) | $80,000 | Included 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
| Scenario | Filing date | Within default 0.5-year SOL window? | Allocated total (illustrative) |
|---|---|---|---|
| A | 2024-04-01 | Yes | $200,000 |
| B | 2024-07-01 | Borderline/at edge | $200,000 |
| C | 2024-08-15 | No (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.
