Spreadsheet checks before running interest in Maine

What the checker catches

Run this scenario in DocketMath using the Interest calculator.

Before you run interest in Maine, the biggest time-saver is catching spreadsheet issues that silently corrupt the math. DocketMath’s interest calculator assumes your inputs are clean—so your “sanity-check” spreadsheet should verify the numbers and dates that feed the interest computation.

Below are the most common failure points a checker can catch in a Maine-focused worksheet.

• Wrong date types or formats

  • Dates entered as text (e.g., 01/15/2024 stored as "01/15/2024") can break day-count logic.
  • Check that your spreadsheet’s date column is truly date-typed, not text.

• Mismatched start/end dates

  • Interest depends on the period you’re computing over. If the start date is later than the end date, your sheet may output negative/zero days or nonsense.
  • Your checker should flag:

    • Start date > End date
    • Missing start or end
    • End date accidentally set to the wrong “as of” date (e.g., today instead of your intended cutoff)

• Day-count inconsistencies

  • Some sheets use 365 vs 366, or they mix methods (e.g., “actual days” in one place, “assumed days” in another).
  • If your interest logic needs an actual day difference, enforce a single rule like:

    • days = end_date - start_date using spreadsheet date serials
  • Then confirm the computed days equals the “visible” date difference you expect.

• Unintended units for the principal and rate

  • Principal scaling mistakes are common:

    • 10000 (dollars) vs 100.00 (cents expressed as dollars) can drastically change results.
  • Rate format mistakes are also common:

    • 8 instead of 0.08 can multiply interest by 100x.
  • A checker should validate:

    • principal looks like dollars (not cents-as-dollars), and
    • rate is in the format your worksheet expects (often a decimal like 0.08 for 8%)

• Rate frequency mismatches

  • You may have inputs stated “per year,” but the sheet might implement monthly compounding—or vice versa.
  • Your checker should confirm your model is consistent:

    • Simple vs. compound
    • If compound: compounding cadence (monthly, annual, etc.)

• Accidental rounding drift

  • Rounding too early (before intermediate steps) can shift totals.
  • A simple guardrail is comparing:

    • a “round only at the end” version vs.
    • a “round each line/period” version
  • If totals differ meaningfully, keep the higher-precision approach and only round the final output (or use a tolerance threshold).

• **Statute-of-limitations period used incorrectly (Maine baseline)

  • This is the “looks fine but is wrong” category.
  • For Maine’s general (default) rule, the statute provides a 0.5-year general SOL period under Title 17-A, § 8:
    https://legislature.maine.gov/statutes/17-a/title17-asec8.html?utm_source=openai
  • Important: This is the general/default period. If later you determine there’s a claim-type-specific sub-rule, the general rule may not control.
  • Pitfall: A spreadsheet can look correct while applying the SOL window to the wrong dates (or using the wrong cutoff boundaries). Build a checker that confirms the exact dates/timeline you feed into your SOL logic are the same ones used in the interest calculation.

Quick checklist your spreadsheet can enforce

Use this as a guardrail before you run the calculator:

Gentle note: This is spreadsheet validation, not legal advice. If your situation requires claim-type-specific analysis, confirm the correct rule before relying on any computed numbers.

When to run it

A checker should run at moments where spreadsheets are most likely to get edited or misunderstood. For a Maine interest workflow, that typically means:

1. Right before you run DocketMath’s interest calculator

   • Treat the checker like a pre-flight step.
   • Fix “hard checks” first (date types, start/end order, units, rate format).

2. After any manual date edits

   • Common scenarios:

     • switching “as of” dates
     • correcting an event date (delivery date, breach date, payment date)
   • Run the checker immediately after edits so you don’t propagate errors.

3. After copying formulas across rows

   • Spreadsheet copy/paste can break references.
   • Your checker should verify each row’s computed day count and rate application are consistent.

4. When you apply any SOL cutoff logic

   • Maine’s general/default SOL period is 0.5 years under Title 17-A, § 8 (see link above).
   • If your spreadsheet uses that 0.5-year window to limit a calculation window, ensure you apply it to the correct timeline boundaries and don’t apply the same filter twice.

A practical workflow that reduces risk:

• Build your timeline (dates + event markers)
• Compute the interest period (days) from those dates
• Run the checker to confirm period math and units
• Feed the clean inputs into DocketMath → interest
• Save the final output with the exact inputs used so results are reproducible

Try the checker

Here’s a quick “try it” approach you can implement directly in your spreadsheet before plugging values into DocketMath. The goal is to catch spreadsheet bugs early—especially date handling, unit mistakes, and inconsistent day-count logic.

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Step 1: Add a validation tab (or validation block)

Create a small section that tests assumptions and shows a pass/fail status:

• Date validity

  • If start/end are blank → flag
  • If start > end → flag
• Unit validity

  • Principal must be > 0 (unless your scenario legitimately supports 0)
  • Rate must be in the expected range for your model (example: 0 to 0.25 if you expect 0%–25%)
  • If your sheet sometimes stores rate as a whole number (like 8), either:

    • convert to decimal (0.08), or
    • flag it clearly so it can’t be used silently
• Day-count consistency

  • Compute days = end_date - start_date
  • Confirm the computed days matches what you expect from the displayed dates

Step 2: Compare two outputs to catch model drift

Even without changing the legal logic, you can detect spreadsheet bugs by comparing a “quick” vs. “full” computation:

• Quick method (example): simple annual assumption
• Full method: your worksheet’s intended model (simple or compound)

If the two outputs diverge beyond a tolerance you choose (for instance, > 1% difference), flag “model mismatch” for review.

Step 3: Confirm the Maine SOL baseline logic (and label it clearly)

If your sheet includes SOL-related cutoff logic, anchor it to Maine’s general/default baseline:

• 0.5 years under Title 17-A, § 8
  https://legislature.maine.gov/statutes/17-a/title17-asec8.html?utm_source=openai

Also label in your spreadsheet that this is the general/default rule. If you later learn a claim-type-specific sub-rule applies, you’ll need to adjust the model rather than keep the general window unchanged.

Step 4: Run DocketMath → interest with checked inputs

Once the checker shows green checks, run DocketMath’s interest tool using your validated inputs:

• principal (dollars, per your sheet convention)
• annual interest rate (as a decimal if that’s your convention)
• start date / end date (or your tool’s expected structure)

Primary CTA: /tools/interest

Related reading

• Common interest mistakes in Rhode Island — Common errors and how to avoid them
• Inputs you need for interest in North Carolina — Input checklist with sourcing guidance
• Worked example: interest in Vermont — Worked example with real statute citations