How to interpret Settlement Allocator results in Philippines

What each output means

When you run DocketMath’s Settlement Allocator for Philippines (PH) cases, the calculator produces an allocation-style breakdown designed to map a settlement amount across parties and claims using jurisdiction-aware rules.

Because the exact output fields can vary by configuration (and by what information you entered), use this guide to interpret the meaning of each common output category—not to treat the numbers as a final legal determination.

Typical allocation outputs you’ll see

Use these to translate “calculator results” into “what to verify next”:

• **Total settlement allocated (PHP)

  • Meaning: The sum of all line-item allocations the model outputs, usually after applying your inputs (e.g., settlement amount and the items you selected).
  • How to read it: If the total doesn’t match your entered settlement amount, check for rounding and whether some components are excluded by your selections.

• **Allocation by party (e.g., Claimant / Respondent)

  • Meaning: How the settlement is split across parties based on your PH inputs and the allocator’s allocation logic.
  • How to verify: Confirm you entered the correct party roles (who is seeking payment vs. who pays) and that your claim types are mapped correctly.

• Allocation by claim category

  • Meaning: The settlement portion attributed to each selected category (for example, different claim types you selected in DocketMath, such as contract-related vs. damages-related buckets—whatever categories are enabled in your run).
  • Why it matters: This category-level split often drives the wording and structure of settlement paperwork (e.g., schedules/annexes), even when the overall total remains stable.

• **Unallocated or residual amount (if shown)

  • Meaning: Any portion the rule set does not assign to a specific party/category in the allocation output.
  • What it usually signals: Missing inputs, categories that are mutually exclusive, or caps/constraints embedded in the allocator workflow.

• **Assumptions or rule flags (if shown)

  • Meaning: Indicators that the calculator applied certain thresholds, default weights, or normalization steps.
  • How to use it: Treat these as checkpoints for data quality. When a flag appears, review the corresponding inputs first rather than assuming the result is “off” due to math errors.

For the tool itself, start here: /tools/settlement-allocator

What changes the result most

In practice, the largest swings in the PH allocator typically come from a small set of inputs. Changes can affect not only the scale of allocations, but also the “shape” of how amounts distribute across parties and categories.

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

1) Settlement amount (the headline number)

• Effect: Usually scales the allocation proportionally until caps, minimums, or category eligibility constraints apply.
• What to watch: If the allocator shows a residual/unallocated amount at one settlement level but not another, your category constraints may be interacting with the numbers.

2) Claim categories you select (and how many you include)

• Effect: More categories usually means the settlement is distributed across more buckets, which can reduce any single category’s share.
• Common scenario: Adding a category you didn’t initially intend can reallocate a meaningful portion away from a higher-priority bucket.

3) Strength/weight inputs used for allocation

Depending on DocketMath configuration, the allocator may use factors such as:

• evidentiary strength indicators,

• priority/importance weights,

• or relative contribution scores across claims.

• Effect: These inputs often change the shape of the allocation, not just the scale.

• Practical check: If one party’s share unexpectedly collapses or spikes, review the relative weights assigned to that party’s claim set.

4) Party role mapping (who is Claimant vs. Respondent)

• Effect: Reversing party roles can flip allocation direction and materially change which side receives which amounts.
• Fast verification: Confirm your entered roles match the transaction reality—who receives vs. who pays—before interpreting the party-by-party results.

5) Caps, normalization, or eligibility rules (PH-specific allocator rules)

Philippines-specific jurisdiction-aware rules may include allocator constraints that:

• prevent a category from receiving more than a computed ceiling,

• or ensure allocations sum cleanly.

• Effect: Constraints create “kinks,” meaning small input changes can produce non-linear output changes.

• What to do: If you see rule flags or residual amounts, test inputs by changing one variable at a time and re-running.

Quick “impact testing” checklist

Use these steps to pinpoint what drove the result:

Next steps

After reviewing the Settlement Allocator outputs, convert the numbers into usable settlement documentation and internal review steps. The goal is consistency: the allocation your team agrees on should match what your draft agreement, payment instructions, and bookkeeping can support.

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

Step 1: Reconcile totals and residuals

• Confirm:

  • total allocated = expected settlement total (allowing for rounding), and
  • no unintended residual amount remains.
• If residual exists, re-run with corrected category selections or missing inputs.

Step 2: Match allocation buckets to settlement agreement language

Turn outputs into structured agreement components:

• Identify each claim category in your allocation
• Mirror those categories in your settlement agreement schedules/annexes
• Ensure each party’s payment entitlement aligns with the party-level allocation

Step 3: Prepare a “review packet” for stakeholders

Create a short internal summary that includes:

• settlement amount,
• allocated share by party,
• allocated share by claim category,
• and any rule flags/assumptions explaining why the split looks the way it does.

Step 4: Use DocketMath links to improve workflow clarity

If you’re iterating on inputs or validating run-to-run consistency, start by revisiting the tool page:

• /tools/settlement-allocator

For broader context around case and document workflows, use:

• /tools: DocketMath tools

Related reading

• Settlement Allocator Guide for Alabama
• Settlement Allocator Guide for Arizona
• Settlement Allocator Guide for Colorado