Spreadsheet checks before running Statute Of Limitations in Philippines

What the checker catches

Running a Statute of Limitations (SOL) check in the Philippines often fails first on inputs, not on the underlying law. DocketMath’s Statute of Limitations spreadsheet-checker (PH) is built to surface the “quiet errors” that can flip a result from “likely time-barred” to “still timely,” or vice versa.

Here are the most common issues this checker is designed to catch:

• Wrong cause-of-action bucket

  • SOL depends on the nature of the claim (for example, written contract vs. injury; specific statutory timelines vs. default rules).
  • If the spreadsheet maps the case to the wrong bucket, the date calculations downstream can become unreliable even if all dates you entered are correct.

• Misread or inconsistent key dates

  • Missing or inconsistent values for key timeline fields, such as:

    • Accrual date (when the claim “began” legally, based on the trigger you’re using)
    • Last demand date (relevant for some demand-based or contract-related obligations)
    • Filing date (the complaint filing date you plan to test against the SOL deadline)
  • The checker flags contradictions like “accrual after filing,” or demand dates that come after filing.

• **Jurisdiction mismatches (not PH)

  • The tool is jurisdiction-aware. If PH settings aren’t applied, the spreadsheet may use the wrong limitation period logic.
  • This commonly happens when teams reuse templates across countries without reviewing jurisdiction configuration.

• Off-by-one spreadsheet logic

  • SOL checks can be sensitive to boundary math (for example, whether the last day of the period is treated as included or excluded).
  • The checker helps you validate the spreadsheet’s date comparisons and deadline boundary handling.

• Missing adjustment fields for tolling / interruption events

  • In practice, SOL analysis may involve concepts like interruption or other timeline effects depending on the facts and the legal theory applied.
  • If your sheet doesn’t track the interruption-related (or other adjustment) dates you intend to rely on, the resulting SOL outcome can be understated or overstated.
  • The goal here is not to “decide the law” in the sheet, but to ensure the spreadsheet reflects the timeline assumptions you selected.

Quick “inputs → output” mapping

Use this to anticipate how changes typically affect the checker’s warnings and SOL result:

When to run it

Timing matters—especially when you’re building a litigation plan, drafting pleadings, or deciding whether SOL is worth emphasizing.

Run DocketMath’s spreadsheet-checker at these points:

• Before drafting a complaint or response

  • Catch date and mapping issues early, before deadline pressure forces rework.

• Before using SOL as a primary motion/defense theme

  • A spreadsheet error can cause briefing arguments and timeline narratives to drift apart across documents.

• After you update factual timelines

  • Examples include:

    • New evidence of demand timing
    • Corrections to an accrual trigger date
    • Revised transaction dates or documented events

• When reusing a template across multiple matters

  • SOL issues often come from copy/paste and label mismatches:

    • wrong filing date
    • wrong transaction type
    • cause-of-action category not updated

A simple disciplined workflow:

Common timing error to avoid

Pitfall: running SOL checks only after you’ve already drafted your motion/complaint narrative. If your accrual date (or boundary assumption) is off by even one key event boundary, you may need to revise both the legal theory and the dates at the same time.

Try the checker

If you want to test this workflow with your own spreadsheet-style inputs, start with the DocketMath SOL tool:

• Primary CTA: **/tools/statute-of-limitations

Once you open it, use the tool like a “date QA pass”:

1. Choose the Philippines (PH) jurisdiction mode
2. Enter your key timeline dates

   • Accrual date (or the best available working accrual trigger date)
   • Filing/complaint date
   • Any demand or other legally relevant event dates you plan to rely on
3. Select the cause-of-action category

   • This determines the structure of the limitation period in the spreadsheet
4. Review output + warnings

   • The checker should surface contradictions (for example, filing before accrual), missing fields, or rule-mapping issues
5. Update and rerun until the sheet is internally consistent

   • When the checker stops flagging data integrity problems, the SOL math becomes more trustworthy for triage

To keep results explainable to your team, save a versioned copy each time you change a single input (especially cause-of-action category and accrual date). That makes it easier to see how SOL outcomes shift as facts update.

What to expect from the checker output

Typically, you’ll see:

• A computed SOL deadline (based on the selected category and timeline)
• A pass/fail style indicator for whether filing appears within the limitation period
• Warning flags for:

  • missing required dates
  • logically inconsistent date ordering
  • rule mapping issues (for example, configuration not matching PH)

Related reading

• Choosing the right statute of limitations tool for Vermont — How to choose the right calculator
• Statute of limitations in Singapore: how to estimate the deadline — Full how-to guide with jurisdiction-specific rules
• Choosing the right statute of limitations tool for Connecticut — How to choose the right calculator