Spreadsheet checks before running Damages Allocation in Michigan

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Before you run Damages Allocation in DocketMath for Michigan (US-MI), you want to verify that your spreadsheet isn’t quietly forcing the calculator into a wrong allocation path. The spreadsheet-checker focuses on issues that commonly distort downstream damages results—especially when you’re working from payment schedules, repair invoices, or repeated claims lines.

Below are the high-value checks it targets for Michigan workstreams.

1) “Stale” damages windows (statute of limitations gating)

Michigan’s default general limitations period is 6 years for claims governed by MCL § 767.24(1). The checker flags datasets that appear to include damages outside that 6-year lookback window based on your date columns.

Because your jurisdiction note indicates no claim-type-specific sub-rule was found, the checker applies the general/default period rather than a specialized limitation rule. That means:

• If your spreadsheet includes line items more than 6 years before the event/trigger date you’ve supplied, totals may include amounts that would be outside the general SOL window.
• If your dates are missing, inconsistent, or entered as text, the checker can’t reliably determine whether a line item falls inside or outside the window—so it will mark those rows for review.

2) Date formatting mismatches

Even correct amounts can become unreliable when dates aren’t machine-readable. The checker looks for:

• Mixed formats (e.g., 01/02/2023 vs 2023-01-02)
• Date columns stored as plain text
• Empty dates on lines that include amounts
• “Lookback anchor” ambiguity (for example, multiple event dates)

When a date problem is detected, you’ll typically see warnings tied to affected rows and a downstream effect: the allocation output may exclude uncertain lines or treat them as out-of-window—depending on how you configure inputs to DocketMath.

3) Duplicate or overlapping line items

Allocations can be inflated when a spreadsheet accidentally double-counts the same expense across multiple rows—for example, an invoice entered once in “repairs” and again in “labor.”

The checker surfaces likely duplicates by reviewing combinations such as:

• Same invoice identifier
• Same vendor + same date
• Same description + same amount

Use this before running Damages Allocation to help ensure the calculator allocates distinct amounts.

4) Incorrect sign conventions (credits vs. charges)

A frequent source of allocation errors is the treatment of negative values:

• Refunds/credits entered as positive amounts
• Costs entered with the wrong sign
• Total rows added both manually and via formula

The checker highlights sign inconsistencies and totals that don’t reconcile with line items, reducing the chance that DocketMath allocates a net amount incorrectly.

5) Broken formulas and subtotal drift

If subtotals are off by even 1–2 dollars, allocation results can drift—particularly when proportional allocation depends on totals.

The checker detects common spreadsheet problems:

• Subtotals that don’t match summed lines
• Formulas referencing the wrong column
• Hardcoded totals that conflict with computed totals

A typical output is a list of “reconciliation failures,” so you can correct the spreadsheet before running the calculator.

When to run it

Run the spreadsheet-checker immediately before you start Damages Allocation in DocketMath, and again whenever you make changes that affect the calculation inputs.

Use these timing triggers:

• Before first run: to establish a clean baseline and avoid compounding errors.
• After importing or pasting data: date formats and sign conventions often change during import.
• After updating any anchor dates: the “event/trigger” date determines the 6-year window under MCL § 767.24(1).
• After editing line items: duplicates, missing dates, or formula breaks can appear after manual adjustments.
• Before exporting results for review: catching issues early keeps your review cycle focused on substance rather than spreadsheet mechanics.

Practical workflow (fast)

1. Clean the spreadsheet structure (columns, headers, date formats).
2. Run the checker; only proceed if it returns no blocking issues.
3. If the checker flags items, fix rows first, then rerun.

Try the checker

You can test the workflow directly in DocketMath via:

• Primary CTA: /tools/damages-allocation

While you’re testing, pay close attention to three spreadsheet input categories—because they directly influence the checker’s ability to validate the Michigan 6-year general period under MCL § 767.24(1):

Inputs to align

• Event/trigger date (single anchor preferred)
  The checker uses this to determine the 6-year lookback window.
• Line item date column
  Each damages line needs a valid date to determine whether it likely falls inside the default period.
• Amount column with correct sign
  Charges should be positive; credits/refunds should be negative (or consistently handled per your setup).

What outputs should change when fixes are made

Use these “before/after” confirmations to make sure you corrected the underlying problem—not just moved warnings around:

If you want the quickest validation loop, fix one issue category at a time (dates first, then signs, then duplicates). This makes it easier to see that the checker is responding correctly and that damages-allocation output is stabilizing.

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