Spreadsheet checks before running Damages Allocation in North Dakota

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Before you run Damages Allocation in North Dakota with DocketMath, a spreadsheet-check pass can prevent “quiet” errors that later look like disputes. The spreadsheet checker is designed to validate the structure and arithmetic assumptions that the damages-allocation calculator relies on, using jurisdiction-aware rules so your allocation behaves consistently with a North Dakota workflow—even when case facts come from different parties or messy exports.

Here’s what it typically catches, tied to the inputs that drive a damages allocation calculation:

• Missing or mismatched line items

  • Example: a contract claim section lists “principal” rows, but your damages allocation sheet expects matching categories for each claim.
  • Common outcome: rows get silently skipped or grouped into the wrong allocation buckets.

• Bad or inconsistent identifiers

  • The checker looks for claim IDs, party IDs, and/or unique row keys that are:

    • blank,
    • duplicated, or
    • formatted differently (e.g., A-01 vs A01).
  • Common outcome: totals may be distributed across the wrong claim bucket, producing an internally consistent—but incorrect—result.

• Totals that don’t reconcile

  • The checker verifies that:

    • subcategory sums equal their category totals, and
    • grand totals match the “inputs to allocation” totals your sheet is feeding into the model.
  • Common outcome: you can end up with outputs that seem plausible, but are internally inconsistent once you audit the underlying math.

• **Numeric format issues (the “looks right” trap)

  • Spreadsheet tools often store numbers as text (for example, "1,200" or "5000 "), or include symbols in numeric fields (like "25%" in a field that expects decimals).
  • The checker flags issues such as:

    • numbers stored as text,
    • unexpected negative values (which may be valid in some contexts, but should be reviewed),
    • percent signs included in decimal fields.
  • Common outcome: computations may treat values as zero, mis-scale them, or otherwise change the meaning of the numbers without an obvious error message.

• Date-related mismatches

  • Many allocation models depend on timing (e.g., when damages accrued or when payments were applied).
  • The checker flags:

    • invalid/unparseable dates,
    • inconsistent date columns across tabs,
    • chronological ordering conflicts when the template expects start/end periods.
  • Common outcome: time windows shift, and the allocation can “move” even though everything still totals cleanly.

• **Allocation basis errors (percentages or basis weights)

  • If your model allocates using percentages, the checker confirms:

    • percentages sum to 1.00 (or 100% depending on your sheet’s setup),
    • there are no overlapping bases that double-count the same amount.
  • Common outcome: results may balance but distribute incorrectly across categories.

• Unit and currency inconsistencies

  • The checker looks for signals like:

    • mixed units (thousands vs dollars),
    • mixed currencies (if your workbook includes them),
    • columns that appear numeric but are labeled inconsistently across tabs.
  • Common outcome: totals can be off by factors such as 1000, even while downstream arithmetic still “reconciles.”

When to run it

Run the checker at three specific points. This timing catches the most preventable issues without adding too much friction:

1. Before the first Damages Allocation run

   • Best when you import a spreadsheet from discovery, a CRM export, or accounting records.
   • Purpose: catch formatting, missing rows, and reconciliation failures immediately.

2. After any edits to allocation inputs

   • Examples:

     • updating damages categories,
     • changing allocation percentages,
     • revising payment application dates,
     • adding a late-discovered line item.
   • Purpose: confirm downstream totals still reconcile with the updated inputs.

3. After consolidating multiple sources

   • If you merge multiple tabs (e.g., “Labor,” “Materials,” “Interest” into a combined damages table), run it:

     • after the merge,
     • before any allocation calculation.
   • Purpose: prevent duplicates, partial merges, and identifier mismatches.

Rule of thumb: If you touched any column that feeds the Damages Allocation calculator—categories, claim IDs, dates, amounts, or basis/percent fields—rerun the checker before trusting outputs.

What the checker output tells you

Expect two types of feedback:

• **Hard stops (must-fix before allocation)

  • Examples:

    • blank claim IDs,
    • non-numeric values in required amount fields,
    • totals that cannot reconcile due to missing or mis-mapped source rows.

• **Warnings (likely to affect allocation correctness)

  • Examples:

    • percentages sum to 0.97 instead of 1.00,
    • dates fall out of the expected order,
    • negative values that may be valid but should be reviewed.

Use this to decide whether you can proceed or need to revise the sheet first.

Try the checker

You can use DocketMath to run a North Dakota–aware spreadsheet check before executing the Damages Allocation calculator.

Start here: /tools/damages-allocation

Then follow this practical sequence:

• Step 1: Prepare your workbook using DocketMath’s Damages Allocation template

  • Confirm required tabs and column headers are present.

• Step 2: Run the spreadsheet checker

  • Fix hard stops first.
  • Review warnings with extra attention to:

    • percentages/basis fields,
    • identifiers,
    • date ordering.

• Step 3: Run Damages Allocation

  • Compare category totals before vs. after allocation.
  • If you see unexpected shifts:

    • go back to the checker results,
    • trace the issue to the specific row(s) or column(s) it flagged,
    • rerun after updates.

If you want a quick validation routine before you run anything, use this checklist inside your spreadsheet:

Reminder (not legal advice): This kind of checker helps with spreadsheet integrity, not case strategy. Always review outputs for factual accuracy and assumptions—especially when inputs come from multiple sources or were manually edited.

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