Spreadsheet checks before running Damages Allocation in Washington

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Running a Damages Allocation workflow in Washington is only as reliable as the numbers you feed it. Before you commit hours of allocation logic, DocketMath’s spreadsheet checks help you catch common spreadsheet defects that can silently corrupt results—especially when you later apply Washington’s 5-year general statute of limitations using RCW 9A.04.080.

This Washington-focused checker is designed to flag issues that commonly affect whether damages categories are time-eligible for inclusion in allocation calculations.

Common problems the checker surfaces

• Date-field defects

  • Missing or malformed dates (e.g., “/” vs “-”, blank cells, or dates stored as text)
  • Inconsistent date columns (incident date vs. event date vs. accrual date)
  • Ranges that extend beyond the applicable lookback window

• Time-window misalignment

  • Using an incorrect “start date” for the SOL lookback period
  • Mixing “transaction date” with “accrual/notice date” across rows

• Category and amount inconsistencies

  • Totals that don’t reconcile to allocation breakdowns (row sum ≠ category total)
  • Negative values where only positive amounts make sense for your model
  • Units mismatch (e.g., dollars vs. cents, or monthly vs. lump sum)

• Coverage gaps in the allocation sheet

  • Rows with a category label that isn’t recognized by your damages-allocation template mapping
  • Categories present in the source sheet but not included in the allocation ruleset

• Cross-sheet reference errors

  • Broken links after copy/paste
  • Using the wrong column index when pulling amounts into allocation inputs

How the checker changes your output

When the checker finds an issue, it typically does one or more of the following in DocketMath:

• Stops the run if it detects missing required inputs (e.g., blank dates, non-numeric amounts).
• Flags rows that fall outside the 5-year SOL lookback window, so you can exclude or separate them.
• Highlights reconciliation problems (like category totals that don’t match line-item sums), which can otherwise distort allocation proportions.

When to run it

Run the checker before you start Damages Allocation calculations, and again after any spreadsheet edits that touch dates or amounts. A good rhythm is to integrate it into your workflow at three points.

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.

1) After you import or paste data

Use the checker immediately after:

• Copy/pasting line items into your template
• Importing from billing, logs, or accounting exports
• Adding new damages categories or additional rows

2) After you normalize date columns

If you convert date formats, create an “accrual date,” or fill missing dates, run the checker right after normalization. Date normalization is where many lookback/SOL eligibility errors originate.

3) After you adjust amounts or category mappings

Any time you:

• Edit amounts
• Reclassify categories
• Change how rows map into damages-allocation buckets

…run the checker before allocation.

Practical SOL tie-in for Washington (RCW 9A.04.080)

Your general lookback concept should be anchored to a consistent measurement you control in the sheet (often a “case filing/filing date” or a chosen reference date). The checker compares each damages row date to the 5-year general period under RCW 9A.04.080.

Try the checker

You can run the Washington-focused damages spreadsheet checks directly in DocketMath via the Damages Allocation tool:

• Primary CTA: /tools/damages-allocation

Suggested workflow:

1. Open the Damages Allocation calculator (/tools/damages-allocation).
2. Select or load your spreadsheet.
3. Run spreadsheet checks first.
4. Fix flagged items (dates, numeric fields, category mappings, totals).
5. Re-run checks after each batch of fixes.
6. Only then run the allocation.

Inputs to prepare in your sheet (so checks pass)

Use consistent column meanings across rows. At minimum, your Damages Allocation sheet should include:

• Row date used for SOL screening (the checker will compare it against the 5-year general window in RCW 9A.04.080)
• Reference date you’re measuring backward from (e.g., case filing date—whatever you choose consistently in the model)
• Damages category (must map to the tool’s allocation categories)
• Amount as a numeric value (dollars or cents—just be consistent)

If your sheet uses additional columns (like descriptions or subtypes), that’s fine—just ensure the core fields above are unambiguous.

What outputs to expect from the checks

After you run the checker, review:

• Error/Blocker list (e.g., missing dates, non-numeric amounts)
• Row-level flags (e.g., rows outside the 5-year default window under RCW 9A.04.080)
• Reconciliation notes (e.g., mismatched totals)

Then correct items in the sheet and re-run until:

• No blocker items remain
• Reconciliation balances
• The date fields are uniform and comparable across rows

Gentle reminder (not legal advice): Don’t treat checker flags as final legal determinations. If you see SOL-related flags, use them to confirm your data mapping and eligibility logic, and consider obtaining legal guidance for case-specific questions.

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