Spreadsheet checks before running Deadline in Philippines

What the checker catches

Run this scenario in DocketMath using the Deadline calculator.

Before you run a Deadline calculation in the Philippines with DocketMath, use a spreadsheet “pre-flight” checker to catch common input errors that lead to wrong due dates. Think of this as validating the data you feed into Deadline, not challenging the underlying legal rules.

A good spreadsheet checker should validate at least these categories:

1) Date integrity problems

Use column-level checks to ensure every date input is usable by your system.

• Blank dates in required fields (e.g., filing date, service date, notice date)
• Text-formatted dates (common when copy/pasting from PDFs or emails)
• Impossible dates (e.g., February 30)
• Timezone drift if you’re importing timestamps as date-only fields
• Inconsistent format across rows (e.g., MM/DD/YYYY vs DD/MM/YYYY)

Output impact:
If Deadline consumes a malformed date, the computed deadline can shift by days or fail entirely.

2) Jurisdiction-aware rule selection mismatches (PH)

For Philippines workflows, you may run the same “deadline” calculation with different assumptions depending on the proceeding or calendar effect. The checker should confirm that your sheet selects the correct rule path for PH (jurisdiction code: PH).

Checklist items to include:

• Correct scenario flag for your proceeding type (e.g., notice-based vs order-based workflows)
• Correct counting mode (calendar-day vs business-day assumptions)
• Correct exclusion/inclusion policy toggles (for example, if your sheet uses a “holiday-aware” calendar, confirm it’s enabled)

Output impact:
Even when dates are perfect, applying the wrong counting mode can produce a result that is consistently—but incorrectly—shifted.

Practical tip: In addition to validating values, ensure that the “PH branch” is explicitly tied to jurisdiction code: PH so it can’t accidentally fall back to a default.

3) Wrong “anchor date” mapping

Most Deadline errors are caused by using the wrong starting point (“anchor date”).

Common anchor-date mixups:

• Filing date used as the anchor when your process requires a service/receipt date
• Receipt/acknowledgment date entered when the process depends on the date of notice
• Order date used when the deadline depends on date of entry/actual receipt

Output impact:
A single-day anchor error can cascade into a repeatable shift across every row—making outputs look plausible while still being incorrect.

To catch this, your checker should confirm that each row’s anchor field is populated and that it matches the intended process mapping for that row’s scenario flag.

4) Missing or invalid calendar inputs

If your Deadline approach uses PH holidays or excluded dates, validate those inputs too.

• Holiday list sheet is present and updated through the relevant year
• No duplicate holidays (double-exclusions)
• Holidays are marked with the correct “exclude vs include” meaning
• Year boundary handling is correct (e.g., a period starting in December crossing into January)

Output impact:
When holiday data is stale or misclassified, your “business day” computation becomes unreliable.

Gentle reminder: Calendar handling can vary by implementation. The goal here is consistency inside your spreadsheet so DocketMath receives what you intend.

5) Range and direction errors

Spreadsheet logic often assumes “later than” constraints. Add checks like these:

• Anchor date must be on or before the computed due date
• Computed due date must stay within a reasonable range (to catch unit mistakes)
• No accidental unit swap: days vs months (or “2” interpreted as “2 years”)

Output impact:
These checks catch unit mistakes early—before the DocketMath Deadline tool produces a confident-looking date.

When to run it

Run the checker in three moments: before the Deadline run, immediately after the first run, and during ongoing updates. This reduces “silent drift,” where the sheet still produces outputs but no longer reflects the intended PH logic.

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

Step 1: Pre-flight before you calculate

Run the checker before clicking through to DocketMath Deadline for PH at /tools/deadline.

Recommended order:

1. Validate all required date fields
2. Validate rule/toggle fields that determine PH logic
3. Validate anchor-date mapping (service/notice vs filing/order)
4. Validate holiday/calendar inputs (if used)

Step 2: Sanity-check after the first calculation

After you generate results for a small batch (e.g., 5–10 rows), confirm:

• Deadlines land on expected weekdays (if business-day logic is used)
• Deadlines don’t regress (e.g., computed deadline earlier than anchor)
• Results change appropriately when you intentionally adjust one input date by +1 day

Step 3: Re-run after any spreadsheet edits

Re-run the checker when you:

• Copy new rows from another team or case file
• Update holiday calendars for the year
• Modify rule toggles or scenario flags
• Change date formats due to export/import

Output impact:
This catches issues that otherwise remain invisible—such as a single column switching from date values to text during import.

Try the checker

If your goal is to calculate PH deadlines in a spreadsheet and then send the inputs to DocketMath, start by routing your workflow through the Deadline tool and validating your sheet first.

1. Open DocketMath Deadline: /tools/deadline
2. Run your spreadsheet checklist for the same rows you plan to calculate in DocketMath
3. Compare the outputs to confirm your inputs match your intended PH logic

To make it practical, here’s a simple “spreadsheet checklist” you can implement right away:

Quick pre-run checklist (PH)

A practical sanity test

Pick one row and change only one variable:

• Increase the anchor date by 1 day
• Re-run Deadline
• Confirm the due date shift matches expectations (for example, business-day logic should generally not shift on excluded days)

This helps verify that your PH logic branch is reading the correct columns and that your formulas are referencing the edited cell.

Warning (non-legal): If your computed deadline does not change when you adjust the anchor date, you likely have a mapping or reference issue (e.g., the tool reads a different column than the one you edited, or a formula isn’t tied to the updated cell).

Related reading

• Why deadlines results differ in Canada — Troubleshooting when results differ
• Worked example: deadlines in New York — Worked example with real statute citations
• Deadlines reference snapshot for New Hampshire — Rule summary with authoritative citations