Spreadsheet checks before running Damages Allocation in Colorado

What the checker catches

Before you run a Damages Allocation calculation in Colorado with DocketMath, a spreadsheet-only set of checks can help prevent the most common “garbage in, garbage out” failures. The goal isn’t to second-guess your legal strategy—it’s to validate that your spreadsheet structure and assumptions won’t produce misleading allocation outputs.

Use the DocketMath /tools/damages-allocation workflow after the checker flags any issues below.

Data integrity problems (the “allocation won’t match reality” group)

These are the issues that most often come from how data is entered, copied, or structured:

• Example: one component entered as negative while your totals and downstream logic assume positive values

Colorado-specific workflow issues (the “jurisdiction-aware rules” group)

Even though the checker is spreadsheet-focused, it should enforce Colorado workflow assumptions that commonly affect how allocation outputs are computed and reported:

• If your sheet includes a jurisdiction indicator, ensure it’s tied to the allocation parameters—not left only in free-text.
• Colorado dockets often involve spreadsheets that mix per-claim damage lines with one global adjustment. The checker should ensure each adjustment is mapped to the correct claim scope.
• For example, if you track “eligibility” flags or an “allocation basis” field, the checker should verify those exist for every relevant claim row.
• If your workflow expects consistent Colorado-style reporting behavior, the checker can help confirm your spreadsheet isn’t rounding early in one column and late in another.

Output plausibility checks (the “doesn’t pass the smell test” group)

These checks validate that outputs make sense mathematically and structurally, even when the spreadsheet “runs”:

These plausibility checks are especially helpful after updates from discovery, amended disclosures, or revised damage schedules.

When to run it

Run the checker at two high-leverage moments: before you calculate and after you revise inputs.

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.

Recommended timing checklist

1. Before the first run

   • Confirm your spreadsheet columns and mappings align with what DocketMath’s damages-allocation calculator expects.
   • Ensure claim identifiers, category names, and adjustment fields are fully populated.

2. After any of these changes

   • You paste in new damages figures (even if you believe formatting stayed the same)
   • You add or delete rows
   • You change rounding settings or switch between “gross/net” columns
   • You edit any “rule flags” (for example, eligibility indicators or allocation basis selections)

3. After importing or syncing

   • If your workflow uses exports from another system, run the checker immediately—imports can convert numbers to text or reorder columns.

A quick rule of thumb

If you changed anything in a column that feeds totals, rerun the checker. Allocation calculations magnify small spreadsheet issues into large downstream discrepancies.

Pitfall to avoid: It’s easy to update only the “Total Damages” column while leaving component rows unchanged. The checker should enforce component-to-total consistency so the spreadsheet can’t silently fall out of sync.

Try the checker

You can test the workflow using DocketMath’s jurisdiction-aware damages allocation tooling.

1. Open DocketMath and go to the calculator here:
   **damages allocation
2. Set jurisdiction context to Colorado (US-CO) inside the tool (if prompted).
3. Paste or upload your spreadsheet values into the appropriate input mapping.
4. Run the spreadsheet checker step (preflight) before the allocation calculation.
5. Review flagged items and fix in this general order:

   • Data type and alignment (numbers-as-text, shifted rows)
   • Missing fields (blank eligibility/category columns)
   • Sum/percent plausibility (component totals and allocation percentages)
6. Re-run after fixes until:

   • Components roll up cleanly to totals
   • Allocation percentages behave consistently with your rounding approach
   • No “unallocated remainder” remains unless you intentionally model one

Inputs that most often change outputs

The checker should prioritize these areas because small edits can cause large allocation shifts:

How to interpret checker results (actionable next steps)

When the checker reports an issue, decide between these response types:

• Correct the spreadsheet input (recommended when a data issue is detected)
• Update your mapping/rule fields (when the issue is structural—e.g., missing flags or wrong scope)
• Recompute after rounding changes (when totals are consistent but formatting/display differs)

Gentle note: This guidance helps you validate spreadsheet mechanics and output consistency. It’s not legal advice, and it can’t replace reviewing your underlying assumptions and sources.

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