Spreadsheet checks before running Damages Allocation in Pennsylvania

What the checker catches

Before you run Damages Allocation in DocketMath for a Pennsylvania matter (US-PA), a spreadsheet “pre-flight” can prevent avoidable downstream errors. This is especially true when timing determines whether claimed damages are potentially recoverable.

DocketMath’s damages-allocation calculator depends on the spreadsheet inputs you provide—typically dates, amounts, and allocation logic—being internally consistent. A spreadsheet-checker step helps you catch issues that can look like “allocation mistakes,” when the real root cause is data integrity.

Here are the common problems the Pennsylvania spreadsheet checker is designed to flag:

• Incorrect or missing date fields

  • Missing “event date,” “filing date,” or “damage period start/end” entries.
  • Date cells stored as text (for example, 03/15/2023 entered as a string), which can break comparisons and lead to misleading results.

• Date order errors

  • Damage period start date after the damage period end date.
  • Discovery date (if your model uses it) earlier than the occurrence/trigger date.
  • Claim filing date earlier than the first damages date used in your model.

• **Out-of-bounds damages periods (SOL-aware baseline)

  • Damages allocated to time windows that conflict with Pennsylvania’s general statute of limitations framework.
  • For this checker, you should treat the limitation window as general/default, because no claim-type-specific sub-rule was found in the provided jurisdiction data.
    In other words: the checker applies the 2-year general baseline, not specialized limitation periods that may apply to particular claim types.

• Suspiciously large or negative amounts

  • Negative damages line items (often caused by sign conventions or accidentally entered negative numbers).
  • Currency/number formatting mismatches (for example, mixing dollars and cents, or thousands separators causing numeric conversion issues).

• Inconsistent units

  • Mixing calendar days with workdays without adjusting the allocation math.
  • Using an allocation rate defined “per month” while the sheet computes days as if they were yearly (or vice versa).

• Formula drift

  • Cells referencing the wrong row/column after copy/paste operations.
  • Allocation totals that don’t reconcile to the sum of component rows (a classic “one-row shifted” spreadsheet failure).

When to run it

Run the checker right before you execute DocketMath → /tools/damages-allocation. In practice, that means running it at the point where your spreadsheet is “date-stable” and “reconciliation-ready,” but before you commit outputs to a final report or narrative.

A practical workflow:

1. Normalize dates and numbers

   • Ensure all relevant date columns are real dates (not text).
   • Confirm amounts are numeric and in a consistent unit (for example, dollars).

2. Run the spreadsheet checks

   • Fix flagged cells, then re-run the checker until the sheet is clean.

3. Only then run Damages Allocation

   • Use the corrected spreadsheet to allocate damages to the portions of your modeled period.

Why timing matters here: Pennsylvania’s general statute of limitations provides a baseline time boundary for many civil claims. Under the jurisdiction baseline used by this checker:

• General SOL period: 2 years
• Citation: 42 Pa. Cons. Stat. § 5552
  Source: https://www.legis.state.pa.us/WU01/LI/LI/US/PDF/2000/0/0136..PDF

Because the jurisdiction data provided includes only the general/default period (and no claim-type-specific sub-rule), the checker should apply the general 2-year baseline rather than assume specialized timing rules.

Jurisdiction rule the checker uses (US-PA)

This is a practical spreadsheet QA guide, not legal advice. Claim-specific limitations may differ, and you should confirm applicability separately for your particular facts and claim types.

Try the checker

If you want to see how it works in DocketMath, start from the calculator entry point and validate your sheet first:

• Open Damages Allocation: /tools/damages-allocation
  (Tip: use the spreadsheet-checker first in your workflow, then re-run after any fixes.)

Here’s a practical checklist for inputs that most often cause failures or confusing results in damages allocation spreadsheets:

Minimum input fields to verify (before running)

What the outputs change when the checker finds issues

Use these expected effects to interpret results confidently:

• If dates are out of order:
  The checker helps prevent allocation to an inverted or impossible damages window, which otherwise can shift sums into the wrong bucket.

• If the modeled damages window exceeds the 2-year baseline:
  Damages allocated to periods outside the general 2-year SOL window may be flagged or excluded—depending on how your allocation logic is configured in the sheet.

• If numeric conversions fail:
  The calculator may default to blanks/zeros or propagate 0/NaN outcomes. The checker catches those before you lose time reconciling output totals.

A quick sanity test (10 seconds)

After fixing flagged cells, re-check totals:

1. Sum your component damages rows manually (or via spreadsheet total).
2. Compare that sum to the “total damages” value you send to DocketMath.
3. Ensure totals match within expected rounding (for example, cents).

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