Common interest mistakes in Delaware

The top mistakes

Run this scenario in DocketMath using the Interest calculator.

When you run interest calculations in Delaware with DocketMath, the most common errors usually come from misunderstanding Delaware’s default statute of limitations (SOL) rule for “an action to recover damages” and from small input choices that quietly change the output.

Delaware’s general/default SOL period is 2 years. The rule is in Title 11, § 205(b)(3), and Delaware applies it as the baseline when no claim-type-specific rule applies. In this brief, no claim-type-specific sub-rule was identified, so the default 2-year period is what you should treat as the starting point for your interest window. (Source: https://delcode.delaware.gov/title11/c002/index.html?utm_source=openai)

Below are the mistakes we see most often when people calculate interest “for a period” in Delaware.

1. Using the wrong SOL window (or forgetting the SOL concept entirely)
   Many calculations accidentally assume an open-ended interest accrual period.
   If your interest calculation is tethered to the recoverable period under the general SOL, Delaware’s baseline is 2 years under 11 Del. C. § 205(b)(3). If you skip the SOL window, your result can be materially overstated.

2. Letting inconsistent dates drive accrual
   Teams sometimes calculate interest from different dates in the same workflow, such as:

   • date of breach
   • invoice date
   • date suit was filed
   • date of settlement
     When each scenario uses a different start/end date, the numbers stop being comparable. A good rule of thumb: pick a single accrual trigger and reuse it consistently across every run in DocketMath.

3. Using inclusive/exclusive day counts inconsistently
   Interest math can hinge on how you treat the start and end dates—whether your model counts:

   • the start date as day 0 vs. day 1
   • the end date as included vs. excluded
     Even a one-day shift can be noticeable with large balances or high rates. The fix is to standardize your day-count convention before you run scenarios.

4. Entering an incorrect principal or mixing principal with prior interest
   A frequent spreadsheet failure is reusing a prior “balance including prior interest” as the new principal. That can unintentionally produce compounding or double-counting, depending on what your model is intended to do.
   Practical takeaway: keep principal and accumulated interest separate unless you specifically intend to model compounding.

5. Rounding early or rounding differently across steps
   Rounding after each intermediate step (for example, daily rate → daily interest → monthly totals) can drift from rounding once at the end. That drift may make outputs look “close” but fail reconciliation.
   To reduce surprises, keep intermediate precision where possible and round in one controlled step (or at least use the same rounding strategy every time).

6. Using the wrong interest rate format
   Input format mismatches are easy to miss:

   • entering “10” meaning 10% when the tool expects “0.10” (or vice versa)
   • providing an annual rate but expecting a daily/monthly rate conversion
     A quick validation step before running multiple scenarios can prevent order-of-magnitude errors.

Gentle note: This is general guidance on common calculation pitfalls—not legal advice. Always confirm how the underlying claim and accrual rules apply to your specific facts and filings.

How to avoid them

You can reduce interest-calculation mistakes in Delaware by tightening your workflow around inputs, date rules, and output checks. The checklist below is aligned to Delaware’s general 2-year SOL default under 11 Del. C. § 205(b)(3).

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

1) Lock the Delaware time window up front (default = 2 years)

Because the general/default SOL is 2 years, your interest “recoverable period” logic should explicitly follow that baseline when no claim-type-specific rule is used.

• Delaware baseline: 2 years
• Statute: 11 Del. C. § 205(b)(3)
• Reference: https://delcode.delaware.gov/title11/c002/index.html?utm_source=openai

If later you identify a claim-type-specific SOL, then you’d update the period logic. Until then, use the default 2-year window consistently across all runs.

2) Choose one accrual trigger and reuse it everywhere

Pick one controlling event for the accrual start date, then apply it consistently in every scenario:

• Accrual start date = the same event in every run (e.g., invoice date, due date, or breach date—whatever rule you are modeling)
• Accrual end date = the same measurement point (e.g., end of the SOL window, filing date, or settlement date)

When you run scenarios, change one variable at a time (like rate or principal), not date logic and principal logic simultaneously.

3) Standardize day-count rules (and document them next to results)

Decide your convention for:

• whether the end date is included or excluded
• how the start date is treated (day 0 vs. day 1)

Then write a one-line note next to each DocketMath output that records the convention used. This makes it far easier to reconcile differences when people compare results.

4) Separate “principal-only” from “balance including prior interest”

A clean modeling approach:

• store principal as the original amount
• store accumulated interest as its own field
• feed principal-only into DocketMath for each run unless you intentionally model compounding

This prevents the common “interest-on-interest by accident” issue.

5) Validate interest rate units before you calculate

Do a quick pre-flight check:

• If your rate is “12%,” convert it to the format DocketMath expects (decimal vs. percent format).
• Confirm you’re using the right basis (annual vs. daily/monthly conversion assumptions).

If your tool uses a different rate basis than your inputs, your totals can shift dramatically.

6) Use sanity checks on outputs

Before exporting or finalizing:

• If principal doubles, interest should roughly double (for linear/simple interest).
• If the number of days halves, interest should roughly halve.
• Look for unit-driven anomalies (for example, rate entered as “10” instead of “0.10”).

These quick checks catch most avoidable errors before they become disputes.

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