Spreadsheet checks before running Statute Of Limitations in Brazil

What the checker catches

Running a Statute of Limitations (SoL) analysis for Brazil without validating the timeline inputs is one of the fastest ways a spreadsheet can drift into the wrong conclusion. DocketMath’s statute-of-limitations calculator (tool code: BR) helps, but it’s the inputs—especially dates—that determine whether the calculator is working from a consistent, usable record.

This checker is intended to catch data issues before you rely on the SoL output, focusing on defects that can change whether a claim is time-barred under Brazil-specific, jurisdiction-aware logic (including how the calculator interprets the relationship between trigger/event dates, filing dates, and any interruption/suspension-related timeline handling).

Typical spreadsheet defects it detects

Use this checklist to understand what the checker is protecting you from:

Output signals to watch

When you run the checker in DocketMath, you should see results that help you decide whether the next step (the SoL calculation) is trustworthy:

• Row-level validation results (which rows/entries pass vs. fail)
• Chronology warnings (dates out of order or outside expected windows)
• Parameter mismatches (e.g., jurisdiction-aware rules not aligning with the inputs you provided)
• Sanity checks (e.g., “as-of date earlier than filing date”)

If any rows fail validation, fix those first. The SoL math is only as reliable as the timeline data you feed it.

Gentle disclaimer: This guidance is about spreadsheet hygiene and tooling checks, not legal advice. SoL outcomes are highly fact-dependent—use your organization’s legal review process as appropriate.

When to run it

Run the checker at every transition where spreadsheet data changes. Not just once—because the most damaging errors usually get introduced during updates: imports, edits, merges, and as-of date changes.

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

Recommended workflow (practical sequence)

1. Before bulk import

   • If dates come from email, PDFs, or OCR, expect formatting drift.
2. After you normalize dates

   • Convert to a consistent format in your sheet (for example, DD/MM/YYYY) before sending/validating in DocketMath.
3. After you set the “calculation as-of” date

   • The as-of date determines whether the elapsed period has crossed (or hasn’t crossed) the relevant threshold in the calculator’s logic.
4. Before you export results or share with stakeholders

   • It’s faster to correct row-level issues early than after results are distributed.

Trigger points (use these as checkboxes in your process)

A note on your “as-of” date

The statute-of-limitations outcome can hinge on the as-of date because the calculator evaluates elapsed time relative to the timeline anchors you provide. For the same case events, choosing a different as-of date can change the result—even if all event dates remain identical.

Try the checker

You can validate your spreadsheet using DocketMath’s statute-of-limitations tool for Brazil (BR). Start with the primary CTA:

• Open the calculator: /tools/statute-of-limitations

Then, use the checker step to validate spreadsheet rows before relying on the SoL output.

What you’ll enter (and why it matters)

Align your columns to what the calculator expects. In practice, you typically provide:

• Key event dates (the trigger/anchor date(s) used by the SoL logic)
• Filing date (or the comparable procedural timestamp)
• Jurisdiction identifier (BR)
• Calculation as-of date (the “today” date for the analysis)

How outputs change based on inputs

Use these scenarios to sanity-check what you see from the checker:

• As-of date earlier than filing date

  • Expected: checker flags chronology issues.
  • Likely impact: any SoL result becomes unreliable or not meaningful.
• Event date later than filing date

  • Expected: chronology warning.
  • Fix: re-check the event timeline against your source documents.
• Date typed as text

  • Expected: invalid date type warnings.
  • Fix: convert to real date values in your sheet (not display-only strings).

Quick self-test (2-minute drill)

Before you run any batch analysis, do this on one row:

Internal action link while you work

• /tools/statute-of-limitations

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