Inputs you need for Damages Allocation in Massachusetts
5 min read
Published April 15, 2026 • By DocketMath Team
Inputs you will need
Run this scenario in DocketMath using the Damages Allocation calculator.
To allocate damages in Massachusetts using DocketMath (jurisdiction code US-MA), you’ll want to gather the inputs that control how the tool splits damages between (1) the applicable time window and (2) the category/component structure you provide.
A practical way to think about it: DocketMath can only allocate what you give it—so the completeness and consistency of your dates and damage amounts directly affect the outputs.
Use this checklist before you run /tools/damages-allocation:
The date you use as the start point for the damages window in your workflow. The cutoff date for the allocation period (often the filing/report/settlement date you’re working from). Either a single total or category subtotals (depending on how your worksheet is structured). For example: past vs. future damages, or other components supported by your model/category table. Whatever the tool prompts for—such as weighting rules, time-phasing basis, or category split parameters. Provide amounts and dates so the tool can net damages consistently. Such as principal-only vs. inclusion of interest; and any rate and interest start date details the tool requires. Examples: invoices, billing ledgers, pay stubs, contracts, account statements, expert exhibit tables—anything that ties clearly back to each category amount.
Timing rule (Massachusetts): use the general/default SOL unless you have a reason to deviate.
Massachusetts uses a 6-year general SOL for many civil claims under Mass. Gen. Laws ch. 277, § 63. For this workflow, treat that as the general/default limitations period because no claim-type-specific sub-rule was found in the provided materials.
Note: This guide is for workflow setup, not legal advice. If you believe a specific claim type uses a different limitations rule, confirm before relying on the default 6-year approach.
Where to find each input
Below are practical places to pull each input from, plus what to extract so your entries are consistent with your damages structure.
| Input | Common place to find it | What to extract exactly |
|---|---|---|
| Claim/event start date | Demand letter, complaint, contract breach memo, incident report | The date of the underlying conduct or the operative event date you’re using as the start point |
| End date / report date | Complaint filing date, case status memo, settlement timeline | The date through which you’re allocating damages |
| Total claimed damages | Damages spreadsheet, demand package summary, expert exhibit | The total you want allocated (or the subtotals by category you plan to feed into DocketMath) |
| Damages categories | Exhibit tables, spreadsheet tabs, billing summaries | Category labels + each category’s total (keep naming consistent across your inputs and model) |
| Allocation weights / time-phasing basis | Methodology notes or expert assumptions | The basis DocketMath needs to time-phase or weight your allocation (e.g., monthly burn rate, quarterly totals) |
| Payments/credits | Settlement agreements, ledger entries, invoices showing offsets | Credit amounts and their dates so you can net consistently |
| Interest inputs (if prompted) | Settlement agreement terms, internal policy, calculation sheet | Interest rate and start date (and whether interest should be included or treated separately) |
Alignment tip (important):
Before entering numbers into /tools/damages-allocation, align your date logic with how your damages were built.
- If your damages are derived from invoice dates, your selected start/end dates should reflect how you intend the tool’s time window to apply.
- If you mix “event-based” windowing with “invoice-based” amounts without consistency, you may see period mismatch in the allocation results.
Pitfall: Avoid double-smoothing. If you already bucketed damages into monthly/quarterly amounts, pass those buckets (or bucket totals) rather than averaging and then time-phasing again inside DocketMath.
Run it
After your checklist is complete, run DocketMath at /tools/damages-allocation. The workflow is typically:
- Confirm jurisdiction (US-MA)
Select Massachusetts (US-MA) or confirm the tool’s jurisdiction detection. - Enter key dates
- Start date (claim/event date you’re using)
- End/report date (allocation cutoff)
- Provide damages inputs
- Total damages or category totals
- The allocation method parameters DocketMath requests (weights/time-phasing/category split settings)
- Credits/payments if you are netting
- Use the Massachusetts SOL logic for the timing window
In this workflow, apply the general/default 6-year SOL under Mass. Gen. Laws ch. 277, § 63.
Because no claim-type-specific sub-rule was found, treat 6 years as the applicable limitations period unless you identify a reason to use something else.
What to check after running
Review the two main output dimensions:
- Windowed damages allocation:
How much of your inputs fall inside the applicable time window determined by your dates and the 6-year default SOL. - Category/component split:
How DocketMath allocates damages across the categories and/or time-phasing structure you provided.
How inputs change outputs (practical examples)
- Tighten the start date:
You may allocate more damages within the window because earlier amounts may shift outside the window less (or not at all). - Move the end/report date later:
You may capture additional periods in-range, increasing windowed allocation totals even if category totals stay the same. - Add/remove credits:
Net damages can change sharply even when gross category totals do not—credits are often a major driver of differences. - Change category granularity:
Providing more detailed category totals generally yields a more precise breakdown; providing one lump sum yields a broader allocation.
Reminder (not legal advice): This is a calculation workflow. If your inputs are incomplete or if your legal assumptions about timing differ, the outputs will follow those assumptions.
When results look right, export/capture the output so you can reconcile it back to your supporting exhibit calculations.