Spreadsheet checks before running Damages Allocation in New Jersey

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Running a Damages Allocation in New Jersey is often decided before anyone touches the numbers—because spreadsheet structure, unit consistency, and timing logic can silently distort totals. With DocketMath’s damages-allocation calculator and jurisdiction-aware rules for US-NJ, the pre-flight “spreadsheet checker” is built to catch issues that commonly lead to incorrect allocation outputs.

Use this checklist to understand what the checker flags and how each fix can change what you ultimately allocate.

Spreadsheet issues the checker should detect (US-NJ)

• Date inconsistencies

  • Missing dates for “start,” “end,” or “event” periods.
  • Dates formatted inconsistently (for example, MM/DD/YYYY mixed with YYYY-MM-DD), which can shift allocation day counts.
  • “End” dates earlier than “start” dates, which can create negative or zero-duration buckets.

• **General timing logic (New Jersey default)

  • The checker applies the general/default statute of limitations period as the baseline for SOL-related timing gates and reporting logic.
  • No claim-type-specific sub-rule was found for this automation step, so the checker uses the general period as the default framework.

• Statutory period used for SOL gating

  • New Jersey’s general limitations period for certain contract-related damages is 4 years under N.J.S.A. 12A:2-725 (General SOL Period: 4 years).
  • Source: https://law.justia.com/codes/new-jersey/title-12a/section-12a-2-725/
  • Practically, this means your spreadsheet inputs may be marked for review or excluded from timing-based gates depending on how your workflow treats items outside the 4-year window.

  Note: This content uses the general/default SOL period because a claim-type-specific sub-rule was not identified for the checker. If your case uses a different limitation framework, you’ll want your workflow to reflect that separately.

• Numeric hygiene

  • “Damages” entered as text (common when copying from PDFs).
  • Mixed currency notation (for example, commas for thousands, parentheses for negatives).
  • Units mismatch (monthly vs. daily rates without conversion), which can scale allocation results by the wrong factor.

• Allocation integrity

  • Totals not reconciling (for example, sum of line items ≠ computed total).
  • Percent allocations not summing to 100% (or summing to more/less due to rounding).
  • Overlapping time slices that double-count the same days.

Quick reconciliation table (use before you run the allocator)

A well-run checker reduces rework: fix structure and inputs first, then trust the allocation math.

When to run it

Treat the checker as a workflow step, not a one-time activity. The best time to run it is whenever changes could alter dates, timing windows, or the math the allocator relies on.

Run the checker before importing a spreadsheet into the Damages Allocation workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

Run it

• Before your first Damages Allocation run (initial model build)
• After any column/rate/date changes
• Whenever you import data from a spreadsheet, discovery export, or OCR output
• Before you export results for filing, mediation, or internal sign-off
• After you adjust SOL-related filters in your workflow (because changing what counts will change outputs)

Why “before” matters for New Jersey SOL logic

Because the checker uses the general/default 4-year period under N.J.S.A. 12A:2-725 (General SOL Period: 4 years), date formatting problems can cascade into timing-based inclusion/exclusion decisions.

A practical pattern:

• If you input event dates incorrectly, the checker may classify items as inside vs. outside the 4-year window.
• That classification can change whether allocations are included in totals, isolated for review, or flagged.

Try the checker

Use DocketMath to run the pre-flight checks in the Damages Allocation workflow.

1. Open DocketMath Damages Allocation
2. Use the checker step to validate:

   • Date parsing (consistent formats, correct order)
   • Numeric fields (no text numbers; correct signs/commas)
   • Allocation math (percent sums and reconciled totals)
   • SOL gating inputs using the 4-year general/default period under N.J.S.A. 12A:2-725
3. Resolve any flagged items, then re-run until the checker output is clean.
4. Only then proceed to the final allocation results you intend to use.

To jump straight into the workflow, use: /tools/damages-allocation

If you want related tooling context, you can also browse: /tools

Inputs to prepare (so outputs behave)

To get stable, dependable results, standardize these spreadsheet fields:

• Start date and end date for each allocation slice
• A clear event date field (if your workflow distinguishes event vs. accrual)
• Damage amount per slice (or rate + duration, but don’t mix those representations without conversion)
• Allocation basis:

  • Percent splits OR
  • Category weights with normalization defined in your sheet logic

Once those inputs are consistent, the checker’s outputs function as a “model health” gate—helping you catch spreadsheet errors before they become allocation errors.

Gentle disclaimer: This guidance is designed to improve spreadsheet accuracy and workflow consistency. It is not legal advice, and it can’t substitute for case-specific legal analysis.

Related reading

• Damages Allocation Guide for Alabama — Comparative Fault Rules
• Damages Allocation Guide for Alaska — Comparative Fault Rules
• Damages Allocation Guide for American Samoa — Comparative Fault Rules