How to run Pre Post Offer Damages Split in DocketMath for Philippines

Step-by-step

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

This guide shows how to run a Pre Post Offer Damages Split in DocketMath for the Philippines (PH) workflow, using jurisdiction-aware rules in the calculator. The goal is to split damages into pre-offer and post-offer amounts based on the timeline you provide, then generate figures you can use in your case presentation.

1) Open the right calculator in DocketMath

• Go to: /tools/pre-post-offer-damages-split
• If the tool prompts you for jurisdiction, select PH (Philippines).

Quick start: you can also go directly to /tools/pre-post-offer-damages-split.

2) Choose what “damages” the calculator is splitting

DocketMath needs clarity on what base figure you want apportioned across time periods—typically a damages principal amount tied to your claim.

Enter:

• Total damages (principal basis): the amount you want split into pre-offer vs post-offer
• Offer date: when the settlement offer was made (or deemed made in your workflow)
• Start date: the beginning of the period you want counted as “pre-offer”
• End date: the cutoff date for the “post-offer” computation

Tip: Check the labels carefully. Some calculators use “from/to” wording, while others use “start/end”—the concepts are usually the same, but the exact boundary you intend must match the tool’s UI.

3) Confirm the PH pre vs post split boundary logic

In this PH workflow, DocketMath uses your timeline to allocate amounts into two segments:

• Pre-offer segment: from Start date up to (but not including) the Offer date
• Post-offer segment: from Offer date through End date

Because the precise boundary handling can affect totals, make sure your Offer date aligns with how that offer is documented in your case timeline (e.g., what date the offer is considered “made” versus when it is received).

4) Enter rate inputs (only if the tool prompts for them)

Many damages split models require an interest/rate assumption (or a computation basis). If DocketMath asks for any of the following, enter them consistent with the approach you’re modeling:

• Interest rate (e.g., annual rate)
• Compounding / annualization method (if applicable)
• Interest basis (e.g., simple vs compound)

If the calculator does not request a rate, it may be performing a time apportionment split without interest components—still, your date inputs will be what drive the split.

5) Run the calculation and review outputs

After you submit, DocketMath should display:

• Pre-offer damages amount
• Post-offer damages amount
• A total check (often the sum of both, or a reconciliation view)

If the tool also provides details such as:

• Effective day counts
• Time fractions
• Interest component breakdowns

…confirm those match what you expect based on your Start → Offer and Offer → End ranges.

Quick validation checklist:

• Verify the day counts correspond to your intended ranges.
• Verify reconciliation: usually Pre + Post = Total, unless the tool explicitly separates principal and interest.

6) Tune inputs and observe how outputs change

To reduce mistakes, do at least two runs:

• Iteration A (baseline): Use your best timeline dates.
• Iteration B (stress test): Change Offer date by ±1–3 days.

What you should typically see:

• If the calculator includes an interest or time-based component, moving the offer date earlier increases post-offer time (and moving it later decreases it).
• Small date changes can produce meaningful shifts when interest is modeled.

This is especially useful for catching:

• swapped dates
• incorrect cutoff date (End date)
• boundary confusion around the offer date

7) Export/capture results so you can reference them later

Depending on DocketMath’s UI options, you may be able to:

• copy the results
• generate a shareable view
• export a summary

When you save your output, preserve:

• the exact inputs you used (principal basis, Start/Offer/End dates, and rate if applicable)
• the computed pre-offer and post-offer figures
• any assumption toggles shown on-screen

That way, when you update dates later, you can reproduce and explain changes in the numbers.

Common pitfalls

Here are frequent issues that can cause wrong splits in PH timelines and how to avoid them in DocketMath:

• Swapping Start date and End date

  • Symptom: Pre/post values look inverted or nonsensical.
  • Fix: Ensure Start date is earlier than End date.

• Misstating the Offer date

  • Symptom: Post-offer portion looks too large or too small after reviewing day counts.
  • Fix: Make sure the Offer date is the correct dated offer record (or the date your workflow treats as “deemed made”).

• Off-by-one boundary confusion

  • Symptom: The numbers don’t match your own manual day counting intuition.
  • Fix: Confirm how the calculator treats the Offer date as a boundary (i.e., whether it is excluded from pre and included in post, as described above). If your internal convention differs, adjust your inputs to match the tool’s logic.

• Inconsistent rate assumptions

  • Symptom: Outputs jump unexpectedly after small date edits.
  • Fix: Keep rate inputs consistent across runs if you’re using date changes only to test sensitivity.

• Entering the wrong “damages” basis

  • Symptom: Your Pre + Post sum doesn’t reconcile with what you expected as “total damages.”
  • Fix: Enter the value in the field the tool expects (e.g., principal basis vs any “total including interest” field, if the UI differentiates).

Pitfall to watch: updating only the Offer date after revising your timeline but forgetting to update the End date (cutoff). Because day counts drive the allocation, changing one boundary without the other can produce inconsistent splits.

Try it

1. Open the calculator: /tools/pre-post-offer-damages-split
2. Set jurisdiction to PH (if prompted).
3. Enter:

   • **Total damages (principal basis)
   • Start date
   • Offer date
   • End date
4. If DocketMath asks for a rate, enter it and keep it the same for your first run.
5. Click Calculate (or the tool’s equivalent).
6. Record:

   • Pre-offer damages
   • Post-offer damages
   • Total reconciliation

To make this session useful, do one quick “what changed?” check:

• Change Offer date by +1 day, rerun, and compare the pre/post outputs.
• If the calculator allocates by time and/or interest, post-offer should generally increase when Offer date moves earlier and decrease when it moves later.

If you want, repeat with a +3 day change to see whether the movement tracks the additional day count proportionally (especially if interest is included).

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