Why interest results differ in Delaware

5 min read

Published April 8, 2026 • By DocketMath Team

This article is for informational purposes only and does not constitute legal advice. Laws change frequently — verify all citations with current official sources.

The top 5 reasons results differ

Run this scenario in DocketMath using the Interest calculator.

If you’re seeing mismatched interest results in Delaware, the difference usually comes from a small set of inputs or Delaware-default rules. Below are the top five causes I see most often when running the DocketMath interest calculator for US-DE workflows.

Important note (default SOL): Delaware’s general/default statute of limitations (SOL) period is 2 years. Delaware law for the general/default SOL is Title 11, §205(b)(3). For this brief, no claim-type-specific sub-rule was found—so use 2 years as the general baseline when a time window is derived from SOL.
(Source: https://delcode.delaware.gov/title11/c002/index.html)

1) The start date and end date were not the same

Interest is extremely sensitive to dates. Even a 1–7 day shift can move totals materially depending on the rate and whether the calculator prorates by days.

Common mismatches:

“Filed date” vs “breach date”
“Demand date” vs “judgment date”
Payment date treated as inclusive vs exclusive

What to check in DocketMath: that both runs use the same “from” date and the same “to” date (and that you’re not accidentally swapping which document date represents each).

2) A time window longer than Delaware’s 2-year default got used

When your workflow uses an SOL-derived interest period, you need consistent boundaries.

Delaware’s general/default SOL period is 2 years under 11 Del. C. §205(b)(3), and—per this brief—there’s no claim-type-specific sub-rule identified. So for diagnostics based on SOL-derived timing, treat 2 years as the baseline.

How it causes mismatches: one run may apply ~365 days and another may apply ~730 days. Even if the rest of the inputs match, that difference can produce a large change in interest totals.

3) Rate type mismatch (annual vs periodic)

Another frequent error is feeding an annual rate into a calculation that expects a periodic rate (or vice versa).

Check whether your interest inputs in DocketMath are:

expressed as % per year (annual), or
converted to a daily/monthly equivalent, or
treated as a fixed rate vs a variable schedule (if your scenario implies variability)

Rule of thumb: if one output looks “wildly too high” or “wildly too low,” the rate format/unit is often the culprit.

4) Compounding assumptions changed

Some interest outputs differ because one run effectively uses:

simple interest (principal × rate × time), or
compounded interest (interest is added back into the base each interval)

If your inputs switched from “simple” to “compound,” the delta can grow as the time span increases—so mismatches become more noticeable over longer periods.

What to check: ensure the same compounding setting (or default behavior) is used in both runs.

5) Rounding and day-count conventions differ

Even with the same dates and rate, totals can change based on:

rounding at each interval vs rounding only at the end
day-count convention (e.g., actual/365 vs actual/360)
inclusion/exclusion of boundary dates

These differences usually create “small-to-medium” deltas—but depending on the rate and duration, they can still be meaningful.

How to isolate the variable

Use DocketMath as a controlled experiment. The goal is to change one input at a time while holding everything else constant.

You can start with the calculator here: /tools/interest.

Freeze the jurisdiction and tool settings so both runs use the same rule set.
Compare one input at a time (dates, rates, amounts) and re-run after each change.
Review the breakdown to see which segment or assumption drives the difference.

Step-by-step diagnostic checklist

Quick comparison table

Input you changed	What to look for in the output	Likely cause
Start date	Output shifts proportionally with time	Date boundary mismatch
End date	Output shifts proportionally with time	Cutoff mismatch
Rate format	Output jumps dramatically	Annual vs periodic error
Compounding on/off	Output grows faster than expected	Compounding assumption
Rounding/day-count	Small-to-medium differences	Convention mismatch

Pitfall: If your interest period depends on SOL, don’t compare results unless both runs apply the same window logic. The Delaware general/default SOL baseline is 2 years under 11 Del. C. §205(b)(3), but it won’t fix mismatches if one run uses a different date window for other reasons.

Next steps

Re-run using DocketMath with a “frozen” input set
- Keep rate, compounding, and conventions identical.
- Only change one variable at a time until the results converge or you find the mismatch driver.
Record the effective interest window
- Write down the exact start and end dates used in each run.
- If your window came from SOL, document that you used Delaware’s general/default 2-year baseline under 11 Del. C. §205(b)(3).
Verify date provenance
- Confirm what each date represents in your source documents (e.g., demand vs breach vs filing).
- Align semantics so the calculator is measuring the same time span both times.
Sanity-check the direction of change
- If the rate is the same, doubling the time window (e.g., 1 year → 2 years) should roughly increase simple-interest calculations proportionally.
- If it doesn’t, compounding or day-count conventions may differ.

Gentle reminder: this is a practical diagnostic—not legal advice. If you’re determining rights or obligations, consider getting advice from a qualified professional.