Spreadsheet checks before running Damages Allocation in Virginia

5 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Damages Allocation spreadsheets are deceptively fragile: a single swapped column, an out-of-order date, or a misapplied jurisdiction rule can cascade into incorrect allocations across claims. DocketMath’s damages-allocation checker is designed to flag spreadsheet issues before you run the allocation calculation in Virginia (US-VA).

Here are the most common problems the checker is built to catch:

  • Column mapping mismatches

    • Detects when required fields are missing (for example, claim amount, allocation bucket/category, or responsibility fields).
    • Flags duplicated or unlabeled columns that can shift data into the wrong variable.
  • Format and type errors

    • Identifies numeric fields stored as text (common after copy/paste from PDFs or court exports).
    • Flags currency values with hidden characters (commas, non-breaking spaces, “$” prefixes) that can prevent correct arithmetic.
  • Date integrity problems

    • Catches invalid dates and inconsistent ordering when dates drive rule selection (e.g., trial date vs. filing date).
    • Highlights blank date cells where the allocation logic expects a value.
  • **Rule gating issues (Virginia-aware)

    • Ensures spreadsheet inputs align with US-VA selection logic so the calculator doesn’t apply the wrong branch of rules.
    • Prevents contradictory inputs (for example, a “selection/election” toggle that doesn’t match the presence/absence of supporting amounts).
  • Internal consistency checks

    • Verifies that allocated totals reconcile to the source totals within an allowable tolerance (so rounding doesn’t quietly drift).
    • Flags negative or zero allocations where worksheet logic expects positive values.
  • Row-level anomalies

    • Detects duplicate claim rows.
    • Flags unusually high/low amounts relative to the rest of the dataset.
    • Flags missing line items that would distort proportional allocation.

Pitfall: Your spreadsheet totals may “look right,” but claim-level amounts can still fail reconciliation after running the allocation—often due to text-formatted numbers or mis-mapped columns that pass a casual review but fail a computational integrity check.

Quick output preview (what changes after the checker)

When the checker finds an issue, it typically changes what you do next in one of three ways:

  1. Blocks calculation if required fields are missing or mapped incorrectly.
  2. Flags warnings (non-blocking) for rounding tolerances, suspicious magnitudes, or unusual distributions.
  3. Suggests normalization (for example, converting currency strings to numbers) by pointing to the specific cells/rows involved.

Inputs you’ll validate

Use this checklist to confirm your spreadsheet has the essentials the checker expects:

When to run it

Run the spreadsheet checker before you execute Damages Allocation in Virginia. Also run it at two additional high-risk points during revisions.

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.

Best times to run

  • After initial data import

    • Copy/paste, CSV conversion, and column reordering are some of the highest-error pathways.
  • Immediately after any formula edits

    • Even small changes to totals, rounding, or normalization can shift allocation outputs.
  • Before exporting results to a hearing package

    • Early detection keeps you from having to explain or reverse spreadsheet errors after distribution.

Practical rule of thumb

If you touched any of the following, re-run the checker:

  • Columns moved (even temporarily)
  • Date cells edited or reformatted
  • Currency/amount fields pasted in
  • Allocation percentages or weights updated
  • Any “total” or “sum” row recalculated

Warning: Damages Allocation spreadsheets can still “compute” while inputs are wrong (e.g., text numbers that coerce unexpectedly). The checker is there to help you validate correctness before trusting outputs.

Try the checker

You can run the DocketMath damages-allocation tool here:

When you try it, use a workflow that minimizes rework:

  1. Run the checker first
    • Confirm worksheet structure and data types before performing allocation.
  2. Review flagged rows/cells
    • Correct the specific cells/rows identified—especially numeric-as-text issues and date blanks/formatting.
  3. Re-run after edits
    • Validate immediately after each correction; don’t assume the fix “stuck.”
  4. Only then run the allocation
    • At that point, you’re allocating based on inputs that have passed integrity checks.

Input-to-output expectations (so you know what to look for)

After the checker passes, your Damages Allocation output should reflect:

  • Reconciled totals
    • Allocated sums should match the spreadsheet totals within the tool’s tolerance.
  • Consistent bucket distribution
    • Allocations should follow your selected categories/inputs without “bucket drift.”
  • Stable rule selection under US-VA logic
    • The calculator should follow the correct branch based on your worksheet’s presence/absence of rule-driving inputs.

If you see warnings instead of blocking errors, treat them like a QA gate—not as “safe to proceed.” A warning about rounding or distribution can still affect presentation-quality outputs.

Minimal “do this now” checklist

Related reading