Common Damages Allocation mistakes in Indiana
5 min read
Published April 15, 2026 • By DocketMath Team
The top mistakes
Run this scenario in DocketMath using the Damages Allocation calculator.
If you’re using DocketMath’s damages-allocation calculator for Indiana (US-IN), the most common failures aren’t about math—they’re about mapping the facts to the right damage components. The tool can only allocate the numbers you provide.
Below are the mistakes we most often see when teams prepare a worksheet for an Indiana case involving damages.
1) Using a statute-of-limitations period other than Indiana’s general 5-year rule
Indiana’s general statute of limitations for many civil claims is 5 years under Indiana Code § 35-41-4-2 (this is the “general/default” period). The key point for this article is that no claim-type-specific sub-rule was found in the provided jurisdiction data, so you should treat the 5-year period as the baseline for SOL filtering in this context.
Why this breaks allocation work: teams sometimes filter which invoices, payments, or damages are “time-eligible” using an incorrect cutoff date. That changes the amounts fed into DocketMath, and can shift distributions across categories even if the calculator is working perfectly.
Note: DocketMath can help calculate and present allocations, but it can’t determine which facts are legally time-eligible. You still need to apply the statute-of-limitations logic yourself before entering numbers.
2) Entering totals but not breaking them into allocatable damage categories
A frequent workflow error is entering a single “total damages” figure when the calculator expects separate inputs (for example: damage components like categories A, B, and C). Even if the UI accepts a total somewhere, you often lose control of how each component is treated.
Typical result: one component ends up understated (or zeroed out), and the remaining categories absorb the difference—creating a distortion that can persist into drafts, exhibits, or settlement narratives.
3) Mislabeling overlapping damage concepts (double-counting risk)
In Indiana practice, labels affect allocation consistency. Teams may accidentally record the same underlying money multiple times under different headings—especially when numbers are pulled from spreadsheets that already contain derived totals.
Common double-count pattern:
- “Back pay” entered once as wages actually owed, and
- again as an “interest” or “incidental costs” line that was already included in the first spreadsheet total.
Effect in DocketMath: double-counted inputs inflate the allocable base, and the downstream percentages may look precise—while being built on duplicated data.
4) Failing to reconcile chronology (service dates vs. payment dates)
Allocations often depend on date windows—particularly when applying a statute-of-limitations cutoff. A common error is using:
- payment dates for some categories,
- service/performance dates for others,
- then applying the same cutoff mechanically to both.
Why it matters: the eligible window can change depending on which event triggers accrual under the relevant theory—even when you’re using the general 5-year SOL baseline.
5) Omitting offsets, credits, or repayments from the allocable base
Many damages allocations should reflect net amounts after offsets (when applicable). Teams sometimes ignore:
- reimbursements received,
- partial settlements,
- mitigation-related credits, or
- repayments.
Effect in DocketMath: if you compute allocations on gross amounts, the output can appear internally consistent while the underlying “should-have-been-net” base is wrong.
6) Feeding inconsistent units (monthly vs. lump sum)
Another high-impact issue is unit mismatch. For example:
- rent calculated monthly ($1,500/month) but entered as a lump sum ($1,500 total), or
- damages computed daily but entered as monthly.
Outcome: allocations can be numerically consistent with the inputs, but wrong relative to the intended economic calculation.
How to avoid them
The goal isn’t to make fewer spreadsheets—it’s to make each input traceable. Here’s a practical workflow you can follow with DocketMath. If you want to try it directly, start 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.
Step 1: Lock your Indiana SOL baseline before allocating
Start with the general/default 5-year period. Use Indiana Code § 35-41-4-2 as the baseline rule in this context because no claim-type-specific sub-rule was identified in the provided jurisdiction data.
Checklist:
Warning: Don’t feed DocketMath totals until you’ve done SOL cutoff filtering. If the eligible window is wrong, allocation percentages will inherit the error.
Step 2: Break damages into components before calculating
Instead of entering “$X total,” enter separate lines for each allocatable category your model supports.
Practical structure:
If your calculator takes “category amounts,” avoid derived totals that already include other categories.
Step 3: Reconcile sources to prevent double-counting
Before using DocketMath, build a quick reconciliation table to verify each worksheet number has exactly one “owner” source.
Practical reconciliation approach:
Rule of thumb:
- Feed raw or single-layer numbers.
- Avoid subtotal lines unless you can prove they exclude other category inputs.
Step 4: Align dates to the event being measured
Create a short “date basis” note for each category.
Checklist:
Step 5: Ensure offsets are handled consistently
If you intend to model net damages:
Reminder: DocketMath can’t validate whether netting is legally required for your theory; it will reflect whatever numbers you provide.
Step 6: Validate units and totals with a “sanity pass”
Before finalizing:
A simple sanity check often catches the most expensive mistakes (unit errors and subtotal/reconciliation issues).