Why Pre Post Offer Damages Split results differ in Philippines

The top 5 reasons results differ

Run this scenario in DocketMath using the Pre Post Offer Damages Split calculator.

If you run the DocketMath pre-post-offer-damages-split calculator for the Philippines (PH), you may notice the “pre” and “post” damages split results change even when your narrative facts feel identical. That gap usually comes from jurisdiction-aware modeling choices and input alignment—particularly when offers, dates, and interest concepts are mapped into a single computation slightly differently than you expect.

Here are the top 5 reasons results differ in PH runs:

1. **Offer date alignment (cutoff mismatch)

   • The split commonly turns on a specific offer-related date (a cutoff/boundary that defines what counts as “pre” vs “post”).
   • If you enter:

     • the wrong “offer sent” date, or
     • a date that reflects receipt vs. dispatch,
   • DocketMath’s pre vs. post boundary shifts, changing totals and the ratio.

2. Interest treatment assumptions

   • In PH contexts, damages calculations may involve legal interest and/or interest-like components depending on what you input and how the calculator applies interest “pre” and/or “post.”
   • Small changes to:

     • the interest start date, or
     • whether interest runs through a judgment date (or another end point),
   • can materially alter the split.

3. Different mapping of “damages” vs. “entire award” components

   • Many workflows have multiple “bases” that get labeled as damages:

     • principal only, or
     • principal + interest already embedded, or
     • principal + expenses/other components.
   • If one run inputs “total award” while another inputs “principal,” the pre/post split diverges because DocketMath allocates different underlying buckets across time.

4. Payment/offset handling

   • If your inputs include payments, partial settlements, or offsets, the order of operations can change outcomes.
   • For example:

     • Are offsets applied to pre-offer amounts first?
     • Are they applied after interest accrues?
     • Are certain offsets excluded from the post-offer portion?
   • Even if the story is the same, different offset workflow assumptions can shift magnitudes and ratios.

5. **Case timeline inputs (judgment date, maturity/valuation date, valuation/end date)

   • The PH timeline drives how long amounts accrue.
   • If your “same facts” still differ in one date field across runs—such as judgment date, valuation date, or another end/stop date—DocketMath will compute different accrual periods and therefore a different split.

How to isolate the variable

Use a controlled diagnostic approach in DocketMath. Your goal is to change one variable at a time and see which output actually moves. This turns “my results are different” into a reproducible cause.

• 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 isolation checklist

• Lock one “offer date” and reuse it across all comparison runs.

  • If you’re unsure whether the calculator expects dispatch vs. receipt, choose one definition (whichever matches your workflow) and stay consistent while testing.

  • Keep judgment/end/valuation dates identical across runs.

  • Only modify the suspected variable (e.g., interest start date, or the offer cutoff definition).

  • Enter:

    • principal/award base as one input basis (where applicable),
    • interest or interest-like amounts as separate inputs (where applicable),
    • or exclude interest-related inputs if the calculator applies interest automatically.

  • Then compare outputs after each change so you can identify whether the change is coming from the base vs the interest logic.

  • Run once with offsets/payments set to zero (or disabled).

  • Run again with offsets enabled.

  • If the split ratio swings sharply, the offset workflow—not your narrative facts—is likely driving the difference.

Quick comparison table (copy into your notes)

Interpretation rule of thumb

• If both pre and post move together → likely interest/timeline changes.
• If only the boundary between pre and post moves → likely offer date definition mismatch.
• If only post changes sharply → likely offer-related interest application or offset ordering/workflow differences.

Next steps

1. Reconcile your key dates

   • Confirm which date you should use as the offer cutoff in your worksheet:

     • dispatch vs. receipt,
     • offer expiration vs. acceptance (whatever your scenario maps to).
   • Keep that definition consistent across all scenarios.

2. Standardize your damages basis

   • Pick one input basis and stick to it while testing:

     • principal-only vs. principal-plus-interest.
   • Then rerun the calculator using the same basis to ensure the model isn’t comparing different “starting numbers.”

3. Do a two-run sanity test

   • Baseline run: your current settings.
   • One controlled run: change only the offer cutoff.
   • If the split flips or changes drastically, you’ve likely found the driver.

4. Document your assumptions

   • Record the exact values you typed for:

     • offer cutoff date,
     • interest start and end,
     • offsets/payment amounts.
   • This makes future re-runs consistent and helps you explain differences internally.

If you want to revisit the tool directly, start here: /tools/pre-post-offer-damages-split.

Related reading

• Why Pre Post Offer Damages Split results differ in Alabama — Troubleshooting when results differ
• Why Pre Post Offer Damages Split results differ in Alaska — Troubleshooting when results differ
• Why Pre Post Offer Damages Split results differ in Arizona — Troubleshooting when results differ