Why Structured Settlement results differ in Maryland
5 min read
Published April 15, 2026 • By DocketMath Team
The top 5 reasons results differ
Structured settlement results in Maryland can look “inconsistent” when they’re actually responding to different inputs and different timing assumptions inside the calculation. With DocketMath (structured-settlement), the most common reasons outputs differ are usually traceable to a single misaligned variable—not “better” math.
Statute of limitations (SOL) timing is measured against the claim filing window
Maryland’s general civil SOL period is 3 years, under Md. Code, Cts. & Jud. Proc. § 5-106. DocketMath uses the SOL-related dates you provide to determine whether the scenario falls within the default general window.- Importantly, in the jurisdiction data available for this diagnostic, no claim-type-specific sub-rule was found. So the 3-year general SOL is the baseline rule used for the Maryland scenario.
How this changes the output: if two people use different “clock start” assumptions (for example, incident date vs. discovery date vs. filing date), the model may treat one scenario as timely and the other as not—or treat them differently in how it positions the timeline.
Cash-flow timing (start date, payment frequency, and deferral) changes the discounting
Even when the total nominal dollars over the full payment period are similar, present value can change materially when payments start at different times. Differences in:- first payment date
- payment frequency (monthly vs. annual)
- deferral period before payments begin
all alter the timing inputs that affect discounting inside DocketMath.
Interest/discount assumptions (rate inputs) create nonlinear differences
Structured settlement modeling commonly uses discounting to reflect the time value of money. Small changes to the rate/discount inputs (and sometimes the compounding approach, if exposed) can produce larger-than-expected swings in:- present value
- effective yield
- “front-load” vs. “back-load” appearance of the stream
Allocation between lump sum and periodic payments
Many scenarios model a combination of a lump sum plus periodic payments. If one set of inputs allocates more value to the lump sum—or starts it earlier—the result can differ even if the later periodic totals look roughly comparable.Input alignment failures (the “same case, different data” problem)
In practice, two runs often differ because the underlying facts were translated into inputs differently, such as:- settlement start year vs. payment start year
- net vs. gross amounts
- inflation-adjusted vs. fixed-dollar payments
- level vs. step-up payment structures
Pitfall: Two people may both say they used “Maryland’s 3-year SOL,” but if their timelines use different triggering dates, DocketMath can legitimately output different results—without either person making a math error.
How to isolate the variable
Treat this like debugging: hold everything constant except one input category, rerun DocketMath, and observe what changes. This isolates the driver quickly and reduces guesswork.
Step-by-step isolation checklist
Confirm the Maryland SOL rule used
DocketMath should apply the general/default 3-year SOL under Md. Code, Cts. & Jud. Proc. § 5-106. Based on the jurisdiction data available for this diagnostic, no claim-type-specific sub-rule was identified—so use the general default as the baseline.Normalize the payment schedule
Ensure these match across scenarios:- payment frequency
- first payment date
- deferral period (if any)
Normalize the rate/discount settings
Use the same rate inputs (and compounding conventions, if applicable/available). Re-run only after these are aligned.Normalize the split
If there is a lump sum in one scenario, ensure there’s a corresponding lump sum in the other run—and that the lump sum start date matches.
Quick “minimal runs” method
Run these in order, changing only one factor category per run:
| Run | Change made | Expected effect if this is the driver |
|---|---|---|
| 1 | Align SOL-related dates (clock start + timeline) | Outputs converge if SOL timing was the cause |
| 2 | Align payment schedule (frequency + first payment + deferral) | Present value shifts should diminish if timing mattered |
| 3 | Align rate/discount inputs | Results should converge if discounting assumptions drove divergence |
| 4 | Align lump sum allocation and start | Outputs should converge if front-loading differed |
Next steps
Use a “single source of truth” input sheet
Record the exact DocketMath inputs you used (dates, payment frequency, lump sum amount/date, rate/discount settings).Re-run DocketMath with identical inputs
When comparing results, verify:- the jurisdiction is set to Maryland
- the general 3-year SOL baseline is being used (default under Md. Code, Cts. & Jud. Proc. § 5-106)
- payment timing and discounting assumptions match
Identify the first point where outputs diverge
If results match after Step 1 but diverge after Step 2, you’ve effectively narrowed the issue to SOL timing vs. payment schedule, and so on.Keep expectations practical (and avoid over-relying on the tool)
DocketMath can help explain why numbers changed given a set of inputs. It’s not a substitute for legal determinations about claim-specific triggers. For case-specific guidance, consider consulting a qualified professional.
To calculate your own scenario, start here: /tools/structured-settlement.