Spreadsheet checks before running Damages Allocation in Philippines

5 min read

Published April 15, 2026 • By DocketMath Team

What the checker catches

Before you run Damages Allocation in the Philippines with DocketMath, run a quick spreadsheet health check. This “spreadsheet-checker” step prevents allocation outputs from being based on malformed inputs—especially where labor, contracts, or tort-style damages computations get split across categories.

Here’s what the checker is designed to catch in your workbook before you calculate:

1) Wrong column mapping (category drift)

Damages allocation commonly relies on category columns (e.g., actual damages, moral damages, exemplary damages, attorney’s fees, interest, costs). The checker verifies that:

  • Each category column header matches what the calculator expects
  • The same row represents the same “case instance” across all columns
  • No category column is shifted due to an inserted/deleted column

Typical symptom: totals look “reasonable,” but one category is consistently too high or too low.

2) Mixed data types in amount fields

Damages allocation inputs often include numbers entered with commas, currency symbols, or blank strings. The checker flags:

  • Text-formatted numbers (e.g., "1,250,000" stored as text)
  • Negative amounts where the model expects non-negative figures
  • Blank cells in rows that otherwise contain amounts

Pitfall: A single text-formatted number can propagate as 0 (or trigger incorrect parsing) in some spreadsheet setups, producing allocations that look coherent but are mathematically wrong.

3) Hidden blanks and inconsistent ranges

If you computed ranges manually, you can get partial coverage (e.g., one column covers rows 2–30, another covers 2–29). The checker detects:

  • Row count mismatches between required input ranges
  • Cells outside the “active rows” you intended to calculate
  • Entire rows with only one category filled

4) Inconsistent basis columns (dates, principal, and interest triggers)

When your allocation includes interest or date-driven computations, the checker validates:

  • Date columns are true dates (not text)
  • Start/end dates follow chronological order
  • Principal amounts used for interest match the principal cells referenced in the spreadsheet

Output impact: If dates are misread or swapped, the interest allocation can swing dramatically even when all amounts seem correct.

5) Missing allocation targets or rules keys

In DocketMath’s damages-allocation workflow, some jurisdiction-aware rules depend on rule keys and calculation parameters you feed into the spreadsheet. The checker ensures:

  • Required parameters are present
  • Rule keys exist for the Philippines (PH) configuration you selected
  • You didn’t leave “default” placeholders in cells that should be populated

Output impact: Without proper rule keys, the calculator may produce fallback behavior that doesn’t match your intended method.

Gentle note: this checker is about spreadsheet correctness and data structure. It’s not legal advice, and it can’t determine how authorities would apply rules to specific facts.

When to run it

Run the checker at specific points in your workflow so you don’t “bake in” spreadsheet defects.

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

Recommended timing

  • Before the first Damages Allocation run
    Do this after you import or paste amounts into the sheet.
  • After every structural edit (insert/delete columns or reorder columns)
    Even one column shift can invalidate category mapping.
  • After copying formulas across rows
    Especially when you extend beyond your original data set.
  • After changing any date fields used for interest or time-based calculations.
  • Before export or submission of outputs
    Catch issues early so exported allocation totals aren’t based on broken inputs.

Quick checklist for “run now” triggers

Try the checker

Use DocketMath’s damages-allocation tool with a pre-flight spreadsheet check so you can trust the allocation math.

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

Step-by-step workflow (practical)

  1. Open DocketMath and navigate to the calculator:
  2. Load or prepare your spreadsheet inputs for PH.
  3. Run the spreadsheet-checker pass:
    • Confirm category columns are mapped correctly
    • Convert any text-formatted numbers into real numeric values
    • Ensure date fields are proper date values
  4. Fix checker warnings/errors, then re-run the checker.
  5. Only after the checker is clean, run Damages Allocation.

Inputs you should inspect (what changes output)

Focus on these columns and how corrections affect results:

  • Category amounts
    • If a category amount is “text,” it may evaluate to 0 or produce wrong totals.
    • Converting to numeric typically changes category allocations immediately.
  • Interest-related principal and dates
    • Swapping dates or using text dates can shift interest computed periods.
  • Rule parameters / keys
    • Missing keys can route you into incorrect rule paths for allocation.

Output validation you can do in 60 seconds

After running the calculator, sanity-check these totals:

Sanity checkWhat you expect to seeCommon mismatch cause
Category sums reconcile to overall totalsOverall total equals sum of categoriesColumn mapping drift
Interest bucket changes when you correct datesUpdated interest amount reflects your corrected timelineText dates / reversed dates
No category is consistently zero across all rowsCategories with inputs shouldn’t all be 0Blank/hidden cells or wrong data type

Note: The goal isn’t to “force” an answer—it’s to ensure your spreadsheet inputs match the structure and data types the calculator expects. That’s where most allocation errors originate.

If you want to speed up your setup, keep your spreadsheet consistent:

  • Use one row per case instance (or per allocation target)
  • Keep one header row with the exact category labels expected by DocketMath
  • Store amounts as numbers, not formatted text

Related reading