Inputs you need for Structured Settlement in Connecticut
5 min read
Published April 15, 2026 • By DocketMath Team
Inputs you will need
A structured settlement in Connecticut is typically modeled using two buckets of information: (1) the payment structure and (2) the legal/timing context. With DocketMath’s structured-settlement calculator, you can standardize the cash-flow inputs you’ll need—then keep your results aligned with jurisdiction-aware timing assumptions.
Before you run anything, gather these inputs:
**Settlement / agreement date (or anticipated agreement date)
- Needed to anchor timing calculations and the projection timeline.
Payment start date
- The first scheduled distribution date under the proposed structure.
Payment frequency
- Example: monthly, quarterly, or annual.
Number of payments
- Or, if your plan is date-based, the end date of the stream.
**Payment amount(s)
- If uniform: one recurring amount.
- If staged: collect separate amounts for each stage (for example, different amounts for “years 1–3” vs. “years 4+”).
Discount rate / present value assumptions (if your model requires it)
- Use the rate consistent with your internal valuation method. DocketMath’s structured-settlement workflow uses the inputs you provide to compute value over time, so the discount-rate choice directly affects present value outputs.
**Payment type (as modeled)
- For example, whether your structure should be treated as level payments vs. step payments (i.e., different payment amounts at different intervals).
Connecticut timing context: applicable statute of limitations (SOL) period
- Connecticut’s general/default SOL period is 3 years under Conn. Gen. Stat. § 52-577a.
- No claim-type-specific sub-rule was found in the provided jurisdiction data, so this 3-year period is the baseline/default to use unless you have separate, claim-specific authority that changes the period.
Note: This 3-year figure comes from Connecticut’s general/default statute cited above (Conn. Gen. Stat. § 52-577a). Structured settlements often intersect with settlement timing and dispute posture, so it helps to keep the SOL baseline visible while you model and document cash flows.
Where to find each input
Use this checklist to locate what you already have and identify what you may still need.
Most inputs live in the case file, contracts, or docket entries. Dates usually come from the triggering event notice; rates and caps come from governing documents or statute; and amounts come from the ledger or judgment. Record the source for each value so the run is reproducible.
Agreement / case timeline inputs
- Source examples: draft settlement term sheet, mediator communications, or last agreed-upon term date.
- Source examples: annuity schedule request, structured settlement proposal draft, or proposed schedule language in the term sheet.
Payment design inputs
- Source examples: the proposed payment schedule, annuity product description, or schedule cadence language.
- Source examples: the schedule table in your proposed structure (or a stated end date).
- Source examples: the same schedule table, or separate stage definitions.
- If there are step-ups/step-downs: collect each stage’s amount and its duration.
Valuation / modeling inputs
- Source examples: internal financial valuation notes, prior modeling, or any assumptions required by your DocketMath structured-settlement workflow.
Connecticut SOL context input (timing anchor)
- Use: 3 years under Conn. Gen. Stat. § 52-577a (default/general period as provided).
- Source: statute text via the Justia link in Related reading.
To keep everything consistent, store your dates in a single format. For example:
| Input you’re collecting | Recommended format | Used for |
|---|---|---|
| Settlement / agreement date | YYYY-MM-DD | Anchors projection timeline |
| Payment start date | YYYY-MM-DD | Determines first cash-flow timing |
| Payment frequency | Monthly/Quarterly/Annual | Builds payment schedule |
| Number of payments / end date | Count or YYYY-MM-DD | Defines stream length |
| Discount rate | Percent | Drives present value calculations |
Run it
Once your inputs are ready, run DocketMath’s structured-settlement calculator using the primary CTA:
- Go to: /tools/structured-settlement
Then, map your inputs to the calculator fields (in a consistent order, so you don’t rebuild the timeline repeatedly):
- Set the timeline
- Enter the settlement/agreement date and the payment start date.
- Define the payment stream
- Choose frequency.
- Enter either:
- Number of payments and payment amount(s), or
- End date with the relevant recurring/staged amounts.
- Apply valuation assumptions
- Enter your discount rate (if the workflow prompts for it).
- Review the computed outputs
- Confirm the schedule aligns with your expectations—especially around first payment timing and any step changes in payments.
How outputs change when you adjust inputs
Use DocketMath to stress-test your assumptions quickly:
- Later payment start date → lower present value
- Even if total dollars are the same, the payments occur further in the future, so discounting generally reduces present value.
- More payments / longer duration → more projected payments
- Total projected dollars typically increase; present value can rise or fall depending on discount rate and payment timing.
- Higher discount rate → lower present value
- Future payments are valued more conservatively.
- Step payments → present value reflects timing of the step changes
- Earlier higher payments generally have a larger impact on present value than later increases.
Finally, keep the Connecticut timing anchor connected to your workflow:
- Connecticut’s general/default SOL period is 3 years under Conn. Gen. Stat. § 52-577a.
- Since the provided jurisdiction data did not identify claim-type-specific exceptions, treat 3 years as the baseline/default unless you have separate claim-specific authority.
Disclaimer: DocketMath helps you model the payment structure and calculations, but it doesn’t replace legal analysis. For SOL issues, keep Conn. Gen. Stat. § 52-577a visible in your review process so your workflow doesn’t accidentally rely on an incorrect timing assumption for the specific matter.
