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 issue | Typical symptom in allocation output | Checker’s likely detection |
|---|---|---|
| Totals don’t match sum of parts | Allocation amounts look “off” with no obvious error | Sum checks + reconciliation warnings |
| Shares don’t add to 1.00/100% | Allocation distributes too much/too little | Share normalization checks |
| Amounts are text | Outputs become zero/blank or unexpectedly unchanged | Type/format validation |
| Duplicate rows | Over-allocation to a category | Duplicate key + row fingerprint checks |
| Missing basis field | Run fails or produces partial results | Required-field completeness checks |
| Overlapping date ranges | Time-based categories inflate | Date 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.
