Spreadsheet checks before running Pre Post Offer Damages Split in Philippines

What the checker catches

Before you run DocketMath’s Pre Post Offer Damages Split calculator in the Philippines (PH), run a quick spreadsheet check to prevent the most common—often silent—data errors. This is especially helpful when your spreadsheet powers multiple scenarios (e.g., different offer dates, different damage components, or more than one defendant).

The checker focuses on the problems that distort the pre-offer vs. post-offer boundary. When that boundary is wrong, everything downstream (pre/post totals and reconciliations) can look plausible while actually being incorrect.

Data integrity issues the checker flags

• Blank offer date values.

  • Dates stored as text (e.g., "01/02/2024" typed or imported as text).

  • Mixed date formats (e.g., MM/DD/YYYY in one area and DD/MM/YYYY in another).

  • Likely result: the split boundary shifts, or the offer date becomes NaT/null, so amounts land in the wrong period.

  • Some rows may use full timestamps (date + time), while others store only dates.

  • Likely result: a one-day (or even same-day) offset moves damages across the split boundary—especially around midnight or locale conversions.

  • Credits/refunds recorded as negative in one section but positive in another (or vice versa).

  • Likely result: pre and post totals can still “look right” individually, but reconciliation fails because the net effect is inconsistent.

  • Example: one tab stores amounts as “PHP” while another stores “thousands of PHP.”

  • Likely result: the ratio between pre and post can change even if your grand total seems close.

  • If your sheet uses a “damage type” column, the checker verifies that each type routes to the correct calculator input.

  • Likely result: “actual damages” flowing into an “interest-bearing” (or other) component field.

  • Common workflow: copy/paste a range after edits, or merge cells in a way that duplicates rows.

  • Likely result: rows (and their amounts) are counted twice—so the split may be “consistent,” but the base data is already wrong.

  • A derived column (e.g., “running balance” or “allocated amount”) doesn’t sum back to the original line items.

  • Likely result: the split can be mathematically consistent with a broken base—so you get believable outputs from incorrect inputs.

Pitfall to watch: If your “offer date” cell is formatted as text, the calculator may not reliably treat it as a real date. You might still get numbers, but the pre/post boundary may be wrong—quietly.

Output symptoms you can spot immediately

After running the checker (and before trusting final results), sanity-check these patterns:

• Pre-offer total = 0 even though your data includes transactions clearly before the offer date.
• Post-offer total = 0 despite late-period entries being present.
• Totals remain unchanged when you adjust only the offer date by one day (often indicates a date parsing or boundary issue).
• The split changes for some components but not others (often points to mapping or boundary application differences).

(Gentle note: the checker reduces risk of spreadsheet errors, but it doesn’t replace careful review of your underlying facts and how your model is intended to treat each line item.)

When to run it

Run the spreadsheet checks at the moments when errors are hardest to detect by inspection—when small input changes can have large downstream impact.

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

Recommended checkpoints

• Catch offer date parsing, missing columns, sign conventions, and mapping issues before outputs exist.

  • Switching from YYYY-MM-DD to a localized format, or changing a cell’s type via import, can break date handling without obvious warning.

  • Imports frequently convert dates into strings and numbers into text. A checker helps you catch type drift early.

  • If you create multiple “scenario sheets” (different offer dates/allocations), apply the checker to the final scenario sheet you will actually run—not only the original source.

  • The risk shifts from “wrong calculation” to “wrong presentation,” especially when you copy/paste calculated cells or reorganize tables.

What to verify at each checkpoint

Treat the checker as a gate, then confirm:

• Offer boundary correctness

  • Pick at least 3 sample rows: one clearly before the offer date, one on/near the boundary (if applicable), and one clearly after.

• Component consistency

  • If you have multiple damage components, ensure each component uses the same boundary logic and is mapped correctly.

• Reconciliation

  • For each component, verify pre + post reconcile to your expected total (accounting for any lines you explicitly exclude in your design).

Try the checker

You can run the workflow directly with DocketMath using the tool’s calculator and jurisdiction-aware rules for PH (Philippines).

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

Primary CTA

• Use DocketMath: Pre Post Offer Damages Split

Practical input checklist (what to prepare in your spreadsheet)

Before running, align your spreadsheet columns so the checker can validate them cleanly:

• Offer date

  • One cell (or one column value per scenario) representing the “offer” boundary.

• Transaction / event date per line

  • The dates used to determine whether each amount is pre-offer or post-offer.

• Amount fields

  • Separate columns for each damage component you plan to split.

• **Consistent “damage type” mapping (if used)

  • Ensure each row’s category routes to the correct component input expected by the calculator.

• Currency/unit consistency

  • Keep values in a consistent unit (for example, all in PHP—not mixed with “thousands of PHP”).

How outputs change when inputs are corrected

When the checker identifies an issue and you re-run, the results should change in predictable ways:

(Reminder: this is guidance for interpreting spreadsheet behavior—not legal advice.)

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