Why Structured Settlement results differ in Philippines
5 min read
Published April 15, 2026 • By DocketMath Team
The top 5 reasons results differ
If you’re using DocketMath’s structured-settlement calculator for the Philippines (PH) and noticing that outcomes don’t match what you expected, the mismatch usually comes from how the calculator is parameterized versus how the actual settlement agreement is drafted. Structured settlements in PH may look similar at a high level, but the cashflows can diverge quickly once the specific rules and assumptions are applied.
Here are the top 5 reasons results differ:
**Payment schedule mismatch (timing and frequency)
- A “monthly” stream versus “lump sum at milestones” can swing totals because discounting depends on when payments occur.
- Even small timing changes (e.g., first payment at month 0 vs month 1) can materially affect present value.
Different interest/discount assumptions
- Structured settlements typically rely on a growth/discount rate (sometimes stated directly, sometimes implied by product design).
- In DocketMath, outputs change materially when you adjust the rate used to discount future payments into a present value.
Tax and withholding treatment assumptions
- If your model assumes gross payments while the real arrangement nets out withholding or deductions, your net proceeds (and effective value) will differ.
- DocketMath will reflect whatever tax/withholding inputs you enter—so using placeholder values that “seem reasonable” can produce surprisingly different outputs.
Inflation or escalation in future payments
- Some settlements include step-ups (e.g., annual increases tied to CPI or a fixed percentage).
- Without escalation, later payments look smaller in real terms; with escalation, totals and present value can move upward.
Inflation-linked or currency/FX considerations
- If amounts are denominated in a way that implies future conversion or currency-sensitive escalation, the same headline numbers may not map cleanly into a single-rate model.
- DocketMath’s PH jurisdiction-aware rules can only reproduce the structure you input—so currency assumptions can shift results.
Gentle note (not legal advice): A common “feels wrong” moment happens when people compare agreement headline amounts (like total award and term) to a calculator present value figure without aligning the discounting method, escalation, and whether amounts are gross or net.
How to isolate the variable
To isolate what’s driving the discrepancy, use DocketMath as a controlled diagnostic tool: change one input factor at a time, keeping everything else constant, and watch which output metric changes the most.
Use the DocketMath calculator here:
Step-by-step isolation approach
Run a baseline
- Enter the settlement structure exactly as you currently understand it.
- Record the key outputs you’re comparing (especially whether you’re comparing nominal totals vs present value).
Then adjust only one factor per test Keep these fixed during each test:
- term length / number of payments
- payment frequency (monthly/quarterly/etc.)
- payee/benefit type (as represented in your scenario)
- escalation toggle (on/off)
Perform targeted tests
- Timing test
- Shift the first payment date by 1–2 periods (e.g., month 0 → month 1).
- If present value changes noticeably, timing is likely the culprit.
- Rate test
- Adjust the discount/interest rate by a small step (e.g., ±1%).
- If the output swings strongly, the model is rate-sensitive.
- Tax-netting test
- Compare runs using gross vs net payments (or the relevant deduction/withholding inputs).
- If net proceeds move while gross structure stays similar, taxes/withholding assumptions are driving the gap.
- Escalation test
- Turn escalation on/off while holding base payment constant and keeping frequency the same.
- If later cashflows dominate the difference, escalation is likely the driver.
- FX/currency test
- If the agreement implies conversion or currency-sensitive adjustments, run inputs that mirror that wording.
- If differences persist even after small timing changes, currency modeling may be the issue.
Use a simple comparison table
Track each change so you can see which variable produces the biggest move in output:
| Variable you change | What you hold constant | What to watch in output |
|---|---|---|
| First payment timing | Rate, escalation, net/gross | Present value movement |
| Discount/interest rate | Timing, escalation, net/gross | Present value slope |
| Withholding/tax handling | Timing, rate, escalation | Net proceeds delta |
| Escalation/escalator | Timing, rate, net/gross | Total and PV increase |
| Currency/FX assumption | Timing, rate, escalation | Persistent offset |
Next steps
Once you identify the dominant variable, translate it into concrete workflow actions:
Audit the agreement’s cashflow mechanics
- Confirm payment frequency and first/last payment dates.
- Check whether payments escalate (and how: fixed %, CPI/index-linked, or no escalation).
Align DocketMath inputs to the agreement’s wording
- Enter the discount/interest assumption that matches the agreement’s implied or stated design.
- Decide whether your expected figure is gross award value or net proceeds after deductions, then model the same basis.
Run a structured three-scenario sanity check
- Scenario A: your current baseline inputs
- Scenario B: adjust only timing
- Scenario C: adjust only rate/escalation
- The scenario that moves closest to your expectation indicates what needs correction.
Keep a change log
- Save the exact values used in each run.
- This prevents comparing results from different input versions (a very common source of confusion).
Pitfall to avoid: Comparing a nominal “sum of payments” from the agreement to a calculator present value output will almost always look inconsistent because discounting reduces the value of later payments. Make sure you compare like-for-like output metrics.