Spreadsheet checks before running Settlement Allocator in Philippines

What the checker catches

Run this scenario in DocketMath using the Settlement Allocator calculator.

Before you run DocketMath’s Settlement Allocator (PH), a “spreadsheet checker” pass can prevent the most common allocation failures caused by bad inputs, inconsistent mappings, or Philippines (PH)-specific rule mismatches. Think of the checker as a pre-flight validation layer that focuses on data quality and compatibility before any allocation math begins.

Below are the typical issues a spreadsheet-checker workflow is designed to catch before allocation logic runs.

1) Structural spreadsheet problems

These errors break allocation logic long before any deeper rule interpretation is possible:

• Missing required columns (for example: party name or identifier, claimant amount, currency, and any allocation target or basis fields the PH setup relies on).
• Duplicate headers that look identical but differ subtly (for example: Claim Amount vs Claim Amount with a trailing space).
• Mixed data types in critical fields, such as:

  • Amounts entered as text ("10,000.00") instead of numeric values.
  • Date fields stored as strings (e.g., 2024-01-31 mixed with 01/31/2024).
• Blank rows inside the claim table, which can shift row-to-party alignment and cause mappings to point at the wrong claimant.

2) Numeric integrity checks (where allocations go wrong)

Settlement allocation calculations are sensitive to arithmetic inputs. The checker should validate things like:

• Total consistency

  • The sum of claim amounts versus the spreadsheet’s Total Settlement value.
• Rounding behavior

  • Whether amounts use consistent decimal precision, and whether rounding differences could accumulate.
• Sign errors

  • Negative claim amounts or a negative settlement pool amount (unless your workflow explicitly supports that, which most don’t).
• Unit/currency mismatches

  • For example, mixing PHP-labeled amounts with USD-labeled amounts, or having amounts in one currency while the allocator assumes another.

3) Jurisdiction-aware data normalization for PH

Even when a spreadsheet “looks right” to a human reviewer, PH-oriented normalization can fail if date formats, identity handling, or tagging isn’t consistent:

• Date parsing for PH formats

  • Ensure settlement dates, filing dates, or hearing dates (if those fields feed PH rule logic) are parsed consistently by the spreadsheet.
• Party identity collisions

  • Claimants with the same name spelled differently (e.g., Juan Dela Cruz vs Juan dela Cruz) can cause accidental grouping if the sheet groups by name instead of a stable key.
• Entity type tagging

  • If the spreadsheet distinguishes individuals vs. corporations/partnerships, the checker ensures that the tag exists and is consistent across rows.

4) Allocation rule compatibility flags (pre-flight validation)

DocketMath can’t apply PH-specific rule logic if the spreadsheet doesn’t provide the fields the rules expect. The checker should verify compatibility, including:

• Missing allocation basis

  • For example: a missing “allocation method” or PH rule selector cell that determines how categories are handled.
• Incomplete category mapping

  • If claims must be mapped into categories (e.g., principal vs. interest vs. expenses), the checker flags any row where required classification is missing.
• Inconsistent category totals

  • If the sheet includes category subtotals, the checker verifies they reconcile with underlying line items.

A good checker doesn’t just say “something is wrong”—it identifies what’s wrong, where it is, and which fields prevent correct Settlement Allocator behavior.

When to run it

Run the spreadsheet-checker immediately before launching Settlement Allocator, and re-run it whenever you change any input layer that affects mapping, totals, or PH-normalized fields.

Run the checker before importing a spreadsheet into the Settlement Allocator workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

Best timing checklist (PH workflow)

Use this order:

1. After you import or paste claim data into the spreadsheet.
2. After you adjust totals (for example, updating Total Settlement or adding a new claimant row).
3. After you update categorization columns (principal/interest/expenses or any PH rule inputs used by the allocator).
4. Before you export results from DocketMath.

Changes that always trigger a re-check

Re-run the checker if you:

• Add or remove claimants (affects row alignment and totals).
• Reformat currency or amounts (especially commas/decimals).
• Change date columns (even changing a single character can alter parsing).
• Edit party identifiers or labels used for grouping.
• Update allocation method / rule selector fields used by the allocator.

Try the checker

You can test the workflow end-to-end by using DocketMath’s Settlement Allocator tools and validating inputs with the checker step first.

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Primary call-to-action

Start here: /tools/settlement-allocator

What to prepare in your spreadsheet (practical input guide)

To make PH checks effective, aim for these minimum data qualities:

• Amounts

  • Store as numbers (not quoted text), and keep decimals consistent.
• Currencies

  • Use an explicit and consistent currency approach—especially if multiple currency inputs appear.
• Party identifiers

  • Prefer a stable Party ID over names when possible.
• Dates

  • Use a consistent date format that your spreadsheet reliably recognizes as a date.
• **Categories (if used)

  • Every claim row should include the category value required by the allocation basis.

How outputs change when the checker catches issues

When the checker detects problems, you should expect one of two outcomes:

• Hard stop / block

  • Allocation doesn’t run because key fields are missing or incompatible.
• Soft correction / flagged warnings

  • Allocation may proceed, but results are flagged for review (examples: rounding variance, category subtotal mismatch, or party-identity collision).

Use these signals to decide whether you should fix data and re-run—or whether it’s acceptable to proceed after reviewing the flagged outputs.

Quick verification steps (before trusting allocator results)

After running the allocator and after the checker clears:

• Confirm the sum of allocated amounts equals the intended settlement pool (within a reasonable rounding tolerance).
• Scan for outlier allocations (e.g., one claimant receiving an unexpectedly large share due to a mapping error).
• Verify party counts

  • The number of claimant representations in the output matches what you expect from the spreadsheet.

Gentle note: this guidance is about operational data hygiene, not legal advice. If you’re unsure whether a particular field or rule configuration is appropriate for your matter, use internal review or appropriate professional guidance.

Related reading

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