Spreadsheet checks before running interest in Delaware

What the checker catches

Before you run interest calculations in Delaware, spreadsheet errors can quietly distort outputs—especially when input dates, day-count conventions, or the “lookback window” are off by even a single day. DocketMath can help you compute the interest, but your spreadsheet still needs sanity-checks first so you’re feeding the calculator consistent, correct inputs.

This checklist focuses on issues that commonly affect Delaware interest runs tied to the general statute of limitations (SOL) period. Delaware’s general SOL is 2 years under Title 11, § 205(b)(3). No claim-type-specific sub-rule was found, so the guidance below treats the 2-year general/default SOL as your baseline.

Use these checks to catch the most common spreadsheet problems before you plug numbers into the interest calculator:

• Date integrity

  • Confirm each date is a real date (not text).
  • Verify there are no “late” end-date truncations (for example, accidental cutoffs like mm/dd/yyy truncation, or strings that parse incorrectly).
  • Spot-check that your start date is actually earlier than your end date for each row you plan to calculate.

• Off-by-one day mismatches

  • Delaware interest computations often depend on day counts. A spreadsheet that uses a convention like DAYS360 (360-day style) versus actual day difference can shift results.
  • Check whether your sheet includes the start date or excludes it—and stay consistent with the method you intend to use.

• SOL window misalignment

  • If your spreadsheet trims or caps the calculation to a 2-year window, verify that trimming is applied to the correct timeline (for example, from the correct “anchor/trigger” date to the correct “calculation end” date).
  • Confirm you are actually using 2 years as the baseline, as required by the general/default SOL: Title 11, § 205(b)(3)—not a shorter/longer period left over from an older template or different jurisdiction.

• Negative or zero duration scenarios

  • Watch for swapped dates or wrong references that produce duration values that are zero or negative.
  • Add a guardrail: if End Date < Start Date (or the computed day count ≤ 0), flag the row and stop rather than letting the spreadsheet silently calculate nonsense.

• Rate unit confusion

  • Confirm whether your spreadsheet stores rates as:

    • a percent (e.g., 5 meaning 5%), or
    • a decimal (e.g., 0.05 meaning 5%).
  • A percent/decimal mismatch can multiply interest by 100×, which can look superficially “plausible” and still be completely wrong.

• Compounding vs. simple interest toggles

  • If you have a column for compounding frequency (annual/monthly/etc.), confirm the setting matches what your interest computation expects.
  • Inconsistent flags can create results that look smooth and reasonable but are systematically off.

• Rounding behavior drift

  • Check when rounding happens:

    • each period,
    • only at the end, or
    • per-line-item before summing.
  • If you want auditability and repeatability, move rounding to a single, consistent step (or at least make it explicit and consistent).

• Row filtering and hidden blanks

  • Verify filters aren’t excluding the exact rows you intended to include.
  • Empty cells can cause formulas to output blanks that later get coerced into zeros (especially during copy/paste or export).

When to run it

Run the spreadsheet checker before you execute the Delaware interest run and after you finalize dates and rate inputs. In practice, two passes helps:

Run the checker before importing a spreadsheet into the Interest workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

Pass 1: Pre-calculation validation (same day you set inputs)

Trigger this check when you:

• update any date (start, end, event/trigger dates),
• change interest rate assumptions,
• modify interest/day-count formulas, or
• add new rows for additional components.

Minimum outputs to review:

• total interest
• total principal (if you track it separately)
• total days used (or capped days used, if applicable)
• any rows flagged by guardrails (like negative duration)

Pass 2: Pre-export validation (right before using results)

Do this after you:

• apply filters,
• copy/paste ranges,
• consolidate tabs/schedules, or
• export values into DocketMath (or into a separate calculation worksheet).

Focus on:

• confirming exported values match the visible table,
• ensuring no hidden rows were dropped,
• checking that date and rate columns didn’t shift during copy/paste.

Quick “trigger list” for re-running the checker

Try the checker

Use DocketMath as your calculation engine—but treat the spreadsheet checker as the guardrail ensuring your inputs driving Delaware interest computations are consistent with the general 2-year SOL baseline in 11 Del. C. § 205(b)(3) (Delaware Title 11, § 205(b)(3)). For Delaware, the general SOL is the default period unless your specific analysis identifies a different applicable rule.

Here’s a practical workflow for sanity-checking with spreadsheet structure and controlled tests:

Step 1: Make inputs explicit with clear columns

Add or verify the following columns (even if you already have them under different names):

Step 2: Add “duration must be positive” guardrails

At the row level:

• If End Date < Start Date, flag the row.
• If Day Count <= 0, stop calculations for that row and review the dates.

This prevents the most expensive failure mode: incorrect date direction that turns into silent incorrect totals.

Step 3: Sanity-check the 2-year SOL baseline logic

Because you’re using the general/default SOL (not a claim-type-specific rule), your spreadsheet logic should anchor to:

• SOL = 2 years under **11 Del. C. § 205(b)(3)

One of these approaches should be implemented clearly in your sheet:

• Compute a SOL Cutoff Date explicitly (Start Date + 2 years), or
• Compute a capped day count using the smaller of:

  • actual day count, and
  • the day count corresponding to 2 years.

Either method can be fine—the key is consistency and auditability.

Step 4: Confirm units and rounding with a controlled test

Before running the Delaware interest calculation:

1. Verify Rate matches what your calculation expects (percent vs decimal).
2. Run a single test row using:

   • a simple rate (e.g., 5%),
   • a small day count (e.g., 30 days).
3. Compare spreadsheet output with DocketMath’s output for that same row.

If mismatches are consistent across multiple test rows, you likely have a day-count convention or unit issue—not a random arithmetic glitch.

Step 5: Run DocketMath with controlled inputs

Once the spreadsheet checks pass, run your final interest calculation in DocketMath using the same inputs you validated.

If you want to start directly in DocketMath, use: /tools/interest .

Related reading

• Interest rule lens: Maine — The rule in plain language and why it matters
• Common interest mistakes in Rhode Island — Common errors and how to avoid them
• Worked example: interest in Maine — Worked example with real statute citations