Spreadsheet checks before running Damages Allocation in Alaska

What the checker catches

Before you run Damages Allocation in DocketMath for Alaska (US-AK), your spreadsheet can quietly introduce errors that still look “math-correct,” but undermine the timeline logic that allocation readiness depends on. The Spreadsheet checker is designed to catch the most common spreadsheet defects that cause downstream allocation outputs to be misleading—especially when the workflow includes a 2-year general statute of limitations (SOL) screen.

For Alaska, the checker’s baseline rule is the general/default limitations period. No claim-type-specific sub-rule was found for this automation path, so the checker applies the general rule consistently rather than varying it by category. The general baseline is:

• Alaska Statutes § 12.10.010(b)(2): 2 years (general SOL period)
  Source: https://law.justia.com/codes/alaska/title-12/chapter-10/section-12-10-010/?utm_source=openai

Concretely, the checker focuses on spreadsheet problems that can affect whether your matter can be evaluated within that 2-year timeline window, including:

• Missing or blank date fields

  • Examples: claim date, event/incident date, last accrual date, or “date filed” columns.
• Date mis-typing

  • Dates stored as text (for example, entering 01/15/2024 as a string). This can lead to incorrect comparisons or wrong sorting.
• Inconsistent date sources across tabs

  • One worksheet uses “Date of incident,” another uses “Date received.” If the wrong anchor is referenced, the SOL/timing evaluation can drift.
• Wrong sign conventions

  • Negative damages, reversed offsets, or credits entered as charges (e.g., a “credit” treated like an “expense” in the allocation math).
• Column alignment problems

  • Swapping columns such as “principal” vs. “interest,” or mixing allocation buckets so the distribution no longer reconciles.
• Percentage totals that don’t net to ~100%

  • Rounding can explain small differences, but large gaps often indicate mis-keyed or mis-mapped percentage cells.
• Non-numeric entries in numeric columns

  • Text like N/A, —, or currency symbols that prevent proper calculations.
• Accidental unit mismatches

  • One column in dollars and another in cents, or interest input in months while principal uses days.

Because the checker is jurisdiction-aware, it applies the Alaska general baseline (2 years) from AS § 12.10.010(b)(2). Since no claim-type-specific rule was identified for this workflow, the checker remains consistent with the general/default period rather than branching by claim type.

When to run it

Run the Spreadsheet checker at the highest-leverage point in your workflow: right before you run Damages Allocation. This timing prevents you from spending time interpreting allocation outputs that were computed using flawed inputs.

A practical cadence:

1. After populating date and damages inputs

   • Fill all date anchors and damage components first.
2. Immediately before starting Damages Allocation

   • Use the checker as a “gate” step to validate timeline readiness.
3. After any edits that touch timing or math

   • Re-run if you changed:

     • incident/trigger dates
     • accrual-related dates
     • filing date inputs
     • interest start/end dates
     • the definitions of allocation buckets (what each row/column represents)
4. After copy/paste operations

   • Copy/paste is a frequent source of subtle formatting drift (especially for dates and currency fields).

Quick decision table:

Gentle note: this is a tooling workflow safeguard—not legal advice.

Try the checker

Use DocketMath’s Damages Allocation workflow like this:

1. Open the tool: /tools/damages-allocation
2. Load or map your spreadsheet fields into the tool’s input areas.
3. Run the Spreadsheet checker before allocation calculations.
4. Review what it flags and iterate until:

   • all SOL-relevant date fields are present and properly formatted
   • numeric cells parse cleanly
   • your allocation percentages reconcile (allowing only small rounding differences where appropriate)
5. Proceed to Damages Allocation only after the checker passes.

Inputs the checker typically validates (checklist)

How outputs change when checks fail

When the checker finds issues, the impact is often predictable:

• SOL/timing flags can appear inconsistent or missing if dates aren’t valid.
• Allocation buckets can be wrong due to misalignment (for example, interest landing in a principal bucket).
• Reconciliation totals may not match expectations if numeric parsing fails.
• You may still get “reasonable-looking” results that are based on the wrong anchor dates—this is exactly why date validation matters most.

If you want a fast sanity test, duplicate your spreadsheet, fix only the flagged cells (especially date formatting), then re-run the checker and Damages Allocation. The output differences will show you whether the issues were materially affecting the allocation view.

Related reading

• Damages Allocation Guide for Alabama — Comparative Fault Rules
• Damages Allocation Guide for American Samoa — Comparative Fault Rules
• Damages Allocation Guide for Arizona — Comparative Fault Rules