Spreadsheet checks before running Damages Allocation in Alabama

5 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Before you run a Damages Allocation workflow in DocketMath for Alabama (US-AL), a spreadsheet-based review can prevent common allocation failures—especially when spreadsheets are edited, exported, or partially copied between drafts.

This checker is designed to validate the data assumptions your allocation calculator relies on, not to judge liability. In practice, it catches issues that would otherwise distort the output, such as:

  • Inconsistent case-level totals
    • Example: your spreadsheet shows $50,000 in “total damages,” but the line items sum to $49,250 due to a copied row truncation.
  • Category mismatches
    • Example: “medical,” “lost wages,” and “other” are used as labels inconsistently (e.g., “Lost Wage” vs. “Lost wages”), causing the allocation logic to treat items as different buckets.
  • Non-numeric or formatted numbers
    • Example: currency values stored as text (often from imported PDFs) or numbers formatted with commas in a way that makes them non-numeric (e.g., "10,500" treated as text).
  • Negative values where they shouldn’t appear
    • Example: a line item carries a negative amount because an adjustment column was accidentally included in the amount set.
  • Missing required fields
    • Example: a claimant row exists but lacks a required value (like “share” or “basis”) needed for allocation.
  • Out-of-bounds “weights” / shares
    • Example: shares don’t add up to the expected total (commonly 1.00 or 100%), or a row has a share greater than 1.00.
  • Chronology / period overlap errors
    • Example: damages period Jan–Mar 2024 overlaps with Feb–May 2024, double-counting time-based categories.
  • Duplicate records
    • Example: the same transaction appears twice after a re-export, inflating totals and skewing allocation.
  • Jurisdiction-aware mapping assumptions that break quietly
    • Example: Alabama-specific expectations for how the sheet defines “damages components,” and how your workbook maps them to calculator inputs, doesn’t match what damages-allocation expects—leading to partial or misrouted calculations.

Note: This is an accuracy and consistency check of spreadsheet structure and math. It’s not legal advice and shouldn’t be treated as a determination of entitlement—just a way to confirm your inputs are compatible with DocketMath → Damages Allocation.

Quick view: common failure types vs. what the checker reports

Spreadsheet issueTypical symptom in allocation outputChecker’s likely detection
Totals don’t match sum of partsAllocation amounts look “off” with no obvious errorSum checks + reconciliation warnings
Shares don’t add to 1.00/100%Allocation distributes too much/too littleShare normalization checks
Amounts are textOutputs become zero/blank or unexpectedly unchangedType/format validation
Duplicate rowsOver-allocation to a categoryDuplicate key + row fingerprint checks
Missing basis fieldRun fails or produces partial resultsRequired-field completeness checks
Overlapping date rangesTime-based categories inflateDate overlap validation

When to run it

Run the checker right before you execute DocketMath → Damages Allocation (Alabama / US-AL). Also run it after any spreadsheet operation that changes values, structure, or formatting.

A practical cadence that reduces rework:

  • After importing or copying data
    • Examples: paste from Excel into Google Sheets, re-export from a document management system, or convert CSV/PDF tables into a workbook.
  • After any column reordering or renaming
    • Allocation tools can be sensitive to mapping. Renaming “basis” to “Basis $” (or changing capitalization) can cause mismatches.
  • After you adjust line items
    • Especially if you update only totals but forget to update detail rows that drive allocation.
  • After you normalize shares
    • If you convert percentages to decimals (or vice versa), run the checker to confirm shares still sum correctly.
  • After adding a new claimant/defendant row
    • Missing fields or inconsistent category labels are most likely at this point.

A good rule of thumb: if you changed any of the following, run the checker again:

  • Amounts (currency columns)
  • Shares / weights
  • Category labels
  • Date ranges or periods
  • Column headers used by the allocation mapping
  • Any “total” cells used for reconciliation

Warning (practical): the most expensive error is running the allocation on a sheet that looks clean but contains text-formatted numbers or shares that sum to 0.98 instead of 1.00. The checker is meant to catch that before the run.

Try the checker

Open DocketMath Damages Allocation here: /tools/damages-allocation.

If your workflow supports a preliminary validation step, use the spreadsheet-checker within this tool first. The goal is to confirm your workbook’s structure matches what damages-allocation expects for US-AL, before any calculated outputs are generated.

Inputs to review in your sheet (what the checker cares about)

Use this checklist to prepare your spreadsheet so the checker has what it needs:

How outputs change when issues are present

When the checker finds problems, you’ll typically see effects like:

  • Allocation results shift (sometimes by a few percent or more) due to corrected sums or share normalization.
  • Certain rows may be excluded if required fields are missing or categories fail mapping.
  • Totals may no longer match previously “successful” runs if earlier outputs were based on incorrect formatting (like text numbers) or shares that weren’t truly normalized.

After you fix issues, re-run the checker and confirm the allocation run produces results that reconcile with your intended total structure.

Related reading