How to run Settlement Allocator in DocketMath for Philippines

Step-by-step

Run this scenario in DocketMath using the Settlement Allocator calculator.

This guide walks you through running Settlement Allocator in DocketMath for Philippines (PH). It’s designed to be practical: it shows what to enter, how PH jurisdiction-aware rules change validation/structure, and how to sanity-check results before you use them in any workflow.

Before you start, gather the inputs you’ll type into DocketMath:

• Total settlement amount (PHP) — the anchor total you want allocations to reconcile to
• Parties list — who receives allocated amounts
• Settlement components (claims/components/categories) that you want allocated to those parties (for example: damages/principal, interest, attorney’s fees, costs—use whatever structure your settlement uses)
• Allocation basis you want DocketMath to use (for PH, use the tool’s PH-aware configuration rather than generic defaults)

1) Open the tool and select the Philippines jurisdiction

1. Go to Settlement Allocator in DocketMath:
   /tools/settlement-allocator
2. Confirm the jurisdiction is set to Philippines (PH).
3. Ensure your matter currency is PHP (or set it explicitly if the UI asks).

What changes with PH rules?
When you choose PH, DocketMath applies jurisdiction-aware conventions for how allocations are structured and validated. Even if the arithmetic seems straightforward, the structure (how components are expected to map) and validation checks (how totals and component-to-party mapping are verified) may differ from other jurisdictions.

2) Enter the total settlement amount

1. In the Total settlement field, enter the gross amount you intend to allocate (in PHP).
2. Double-check input formatting:

   • Use the decimal format the tool supports (for example, 2500000.00 if cents are supported).
   • Avoid commas if the input field doesn’t accept them.

Outputs to expect:
DocketMath treats this as the anchor total and attempts to reconcile component allocations so the sum matches your total (typically considering rounding behavior when decimals are involved).

3) Add parties

1. Add each party you want included in the allocation.
2. For each party, provide the identifying information DocketMath requires (names and/or internal party IDs).

Tip: If you have multiple beneficiaries (for example, a claimant and a related payee), add them as separate parties so the output can present clear, separated totals.

4) Define the settlement components (claims, categories, or pay buckets)

Settlement Allocator works best when the “why” behind the money movement is explicit. Define the components you want allocated to the parties.

Common component patterns you might use (adapt these to your settlement agreement):

• Principal / damages
• Interest
• Attorney’s fees (if included in what you are allocating)
• Costs / reimbursement
• Other agreed amounts

Then:

1. Add each component.
2. For each component, decide whether it will be:

   • Manually entered (fixed amount), or
   • Allocated using a basis (percentages/weights used to compute the component split)

How PH-aware rules show up here:
Depending on how your PH configuration is set, DocketMath may enforce constraints and reconciliation checks aligned with common PH allocation workflows—especially around the way totals are validated and how component-to-party mapping is expected to be complete.

5) Map components to parties using DocketMath’s allocation settings

Now connect the components to the parties:

• Choose an allocation mode per component (or per the tool’s overall setting):

  • By amount: specify component amounts and assign them to parties
  • By ratio/weights: specify weights and let DocketMath compute the distribution
• Ensure every component is mapped to at least one party.
• If a component must be split, create multiple assignments for that component.

Outputs to expect:
DocketMath generates a table-like breakdown showing:

• per-party totals, and
• per-component allocation details.

As you edit inputs, the tool should update instantly. Watch for propagation like:

• If you change a weight on a party, their share of affected components shifts.
• If you edit a component total, allocations rebalance according to your chosen basis/mapping.

6) Validate the reconciliation totals

Before you treat results as final, run the tool’s built-in checks:

• Confirm Total allocated equals Total settlement (allowing for rounding).
• Confirm there are no unmapped components.
• Confirm each party has either:

  • allocation lines, or
  • a clear reason for zero allocation (for example, an intentionally excluded component)

If DocketMath flags discrepancies, fix them by:

• adjusting component totals,
• correcting mapping coverage,
• updating allocation ratios/weights so they match the tool’s expectations.

7) Review the results and export/share outputs

Once reconciliation succeeds:

1. Review per-party totals (useful for payment instructions/workflow handoff).
2. Review per-component breakdown (useful for alignment with how settlement terms are described internally).
3. If the tool supports it, generate an export (PDF/CSV) or copy the allocation table into your process.

Practical approach:

• Use party totals for what will be paid/recorded.
• Use component breakdown for internal review and settlement agreement alignment.

8) Save your run and document the configuration

Save the DocketMath run so it’s reproducible later:

• jurisdiction: PH
• allocation mode(s)
• component list and mapping
• input amounts and weights
• reconciliation status

This helps with auditability, especially if revisions happen after contract changes or settlement amendments.

Common pitfalls

Settlement Allocator is mostly input/mapping sensitive—so the most common problems involve jurisdiction selection, component definitions, and component-to-party coverage.

• Re-check the jurisdiction selector before finalizing.
• Make sure your Total settlement matches what your components represent (included amounts vs excluded amounts).
• Unmapped components can create reconciliation gaps or missing party lines.
• For ratio-based allocations, ensure weights are consistent with the tool’s required basis (commonly 100% per allocation set, depending on configuration).
• Example: adding both “damages” and “damages + interest” when interest is already included duplicates value.
• With cents/decimals, rounding can produce small PHP differences that must still reconcile.
• After any change to totals, weights, or mappings, confirm validation again.
• If a party should receive nothing, represent that intentionally via mapping (e.g., exclude the component or set an explicit zero) rather than leaving it accidental.

Pitfall reminder: Don’t assume “it sums up” because party rows look populated. Use DocketMath’s reconciliation to confirm Total allocated = Total settlement.

Try it

If you want to run a PH allocation now, use the tool entry point and follow a quick test sequence:

• Open Settlement Allocator: /tools/settlement-allocator
• Then:

1. Set jurisdiction to PH
2. Enter a simple total, such as 1000000.00
3. Add 2 parties
4. Add 2 components
5. Map each component to the parties using ratios (or fixed amounts)
6. Confirm reconciliation succeeds
7. Change one weight and confirm:

   • the party distribution updates, and
   • totals still reconcile to the same Total settlement

To make your first run more meaningful:

• Name components to match your internal reporting categories.
• Ensure the output includes both party totals and component breakdown.
• Save the run so you can compare outcomes after adjustments.

Related reading

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