What each output means

Run this scenario in DocketMath using the Structured Settlement calculator.

When you run DocketMath’s Structured Settlement calculator with Alabama (US-AL) selected, the results generally convert a structured settlement payment schedule into decision-ready figures. Exact labels can vary a bit by calculator version, but you can interpret the outputs in a consistent way:

• Total scheduled payments: The sum of the settlement’s stated payments (for example, $X per month/quarter/year for Y years, plus any lump sum amounts).

  • Use this to understand the face value of what the agreement is scheduling—i.e., the amounts as they’re written to be paid over time.

• Present value (PV): The calculator discounts future payments back to “today,” using the calculator’s discount assumptions and the payment timing you entered.

  • PV is usually the most useful output when comparing a structured stream to a lump-sum cash option, because it accounts for the time value of money.

• Discounted PV vs. total payments gap (delta): The difference between the scheduled total payments and PV (often shown as a gap or implied discount effect).

  • Practically, this answers: how much value is lost (or effectively reduced) because some money arrives later and is discounted back to today?
  • A bigger gap typically means a larger portion of value sits farther in the future.

• Periodic payment equivalence (if shown): Some versions express the schedule as an equivalent monthly/annual figure in today’s dollars (or under the calculator’s conversion method).

  • This helps when comparing schedules that have different payment frequencies (monthly vs. annual) or different structures that otherwise feel “uneven.”

• Indexing / growth assumptions (if shown): If your structure includes inflation indexing or guaranteed step-ups/growth, DocketMath incorporates those inputs into the payment stream used to calculate PV.

  • If indexing is not part of the structure you entered, treat growth as zero unless the inputs you used specify otherwise.

• Time-to-first-payment / start date impacts: The timing of when payments begin (immediately vs. after several months) can meaningfully affect PV.

  • Earlier first payment dates generally increase PV because more value is received sooner. Later start dates usually decrease PV because more of the stream is pushed into discounted future periods.

Alabama-specific interpretation cues (US-AL)

In Alabama (US-AL), structured settlement discussions often turn on timing, payment terms, and how the settlement is actually drafted and administered. DocketMath’s jurisdiction-aware setup (US-AL) is mainly there to help you apply consistent, context-appropriate interpretation to the structure’s mechanics—without changing the underlying concept that PV depends on discounting and timing.

In practical terms, the Alabama selection is most relevant when you’re cross-checking how the schedule you entered aligns with how the parties may describe or manage those payments in Alabama-related processes and negotiations—especially where when and under what conditions payments start or change matters.

If you want to run the calculator, start here: /tools/structured-settlement.

What changes the result most

PV can move a lot from relatively small input changes. If you want the fastest path to understanding, focus on these levers first:

1) Discount rate / assumed returns

• Why it matters: PV is highly sensitive to the discount rate because that rate changes how strongly future payments are discounted.
• Typical direction:

  • Higher discount rate → lower PV
  • Lower discount rate → higher PV
• Action you can take: If your agreement (or funding assumption) provides a specific rate or method, match it in DocketMath. If you’re testing scenarios, keep assumptions consistent so your comparisons remain meaningful.

2) Payment timing (start date and intervals)

• Why it matters: Delays can reduce PV more than most people expect.
• What to check in your inputs:

  • Start date (time until first payment)
  • Frequency (monthly vs. quarterly vs. annual)
  • Any step-ups (e.g., payments increase after year 5)

3) Total number of payments (duration)

• Why it matters: Extending a stream from (say) 10 to 15 years can increase PV substantially—especially if later payments still have strong “present-day weight” under the discount curve.
• Quick comparison rule:

  • Same payment amount, longer duration → PV usually increases (though the incremental effect can vary with discounting).

4) Lump sum vs. installment mix

• Why it matters: A lump sum paid sooner typically produces a higher PV than the same nominal value spread out into later installments.
• How to read outputs: If two structures have similar total scheduled payments but different timing of lump sum components, PV will likely differ.

5) Indexing / escalation terms

• Why it matters: If payments increase over time (inflation indexing, contractual step-ups), PV can rise because later nominal payments become larger.

• Actionable input tip:

  • If your agreement says payments are fixed, ensure indexing/growth is set to none.
  • If it says payments are indexed, enter the index/escalation method you have (as stated) so DocketMath models what you actually expect to receive.

• Common interpretation error to avoid: entering “net” amounts after deductions without aligning when those deductions occur. DocketMath reflects what you input; if your net/gross timing doesn’t match the schedule mechanics, your PV comparisons can be distorted.

6) Scenario changes: compare side-by-side

Instead of changing everything at once and trying to “average” the impact:

• Scenario A: baseline schedule as written
• Scenario B: adjusted start date (e.g., 3 months later)
• Scenario C: different discount assumption
• Scenario D: with vs. without escalation/indexing

Then compare:

• PV changes
• PV-to-total-payments gap changes
  This tells you whether the outcome shifts primarily because of timing, discounting, or growth/escalation.

Next steps

Use this workflow to interpret your DocketMath results for US-AL in a practical, actionable way:

1. Confirm your schedule inputs

   • Payment amount(s)
   • Payment frequency
   • Start date (time to first payment)
   • End date / number of payments
   • Lump sum components (if any)
   • Any escalation/indexing terms

2. Start interpretation with PV

   • PV answers: what does this payment stream equal in today’s dollars under the calculator’s assumptions?
   • When comparing options, PV is typically the most consistent basis for comparison.

3. Use total scheduled payments as a reality check

   • If PV feels unexpectedly low compared to total scheduled payments, it usually means the schedule is heavily weighted toward later years (and thus discounted more).

4. Measure sensitivity by changing one lever at a time

   • Try just two “highest impact” variations first:

     • start date
     • discount rate
   • Note which lever causes the largest PV change.

5. Write a short result summary

   • PV (today’s dollars)
   • Total scheduled payments (face value)
   • Key schedule features (start date, duration, lump sum)
   • The assumptions you used (discount/indexing)

If you want, you can share the key inputs you used (start date, frequency, payment amounts, duration, lump sum, and discount assumption) along with your PV and total scheduled payments, and you can sanity-check what’s driving the difference between those figures.

Related reading

• Browse the blog

What each output means

The calculator returns these outputs so you can explain the result and audit the path.

• primary result
• supporting breakdown
• notes or assumptions

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

What changes the result most

These inputs have the biggest impact on the final number. Adjust them one at a time if you need a sensitivity check.

• date range
• rate changes
• assumption changes

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

Next steps

Run the Structured Settlement calculator now and save the inputs alongside the result so the workflow is repeatable. You can start directly in DocketMath: Open the calculator.

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

Related reading

• Structured Settlement Calculator Guide for Arizona
• Structured Settlement Calculator Guide for Colorado
• Structured Settlement Calculator Guide for Connecticut