Worked example: Statute Of Limitations in Brazil

Example inputs

This worked example shows how DocketMath can help you model a statute of limitations timeline in Brazil (BR) using jurisdiction-aware rules—so you can sanity-check dates before you draft anything operational (e.g., a claim timeline, internal risk note, or litigation plan).

Scenario (assumptions you can change)

• Country / jurisdiction: Brazil (BR)
• Type of claim used for the calculator: “contract-style civil claim” (BR ruleset in the calculator)
• Event that starts the clock (“trigger date”): 2022-05-10
  (e.g., breach completed or loss realized)
• Intended filing date (“filing date”): 2024-11-20
• Potential tolling/interruptions: none applied in this base example
• Calculator mode: default computation for statute-of-limitations (no custom overrides)

Key inputs to enter in DocketMath

Use the following fields as your working set:

• Jurisdiction: **BR (Brazil)
• Trigger date: 2022-05-10
• Filing date: 2024-11-20
• Interruption / tolling flags: leave blank for baseline (none)

Quick reference: what the inputs mean

• Trigger date is the “clock start” input that drives the latest permissible filing date calculation.
• Filing date is then compared against that computed deadline to estimate timely vs. at-risk.
• Interruption/tolling flags (when enabled) can extend deadlines depending on the calculator’s BR configuration and the options selected.

Example run

Let’s run the base scenario in DocketMath.

Run the Statute Of Limitations calculator using the example inputs above. Review the breakdown for intermediate steps (segments, adjustments, or rate changes) so you can see how each input moves the output. Save the result for reference and compare it to your actual scenario.

DocketMath link (primary CTA)

Use /tools/statute-of-limitations to reproduce the timeline.

(If you want to validate date math patterns or other tooling assumptions, you can also cross-check with another DocketMath function here: /tools/date-differences.)

Output you should expect to see

After you submit the inputs, DocketMath typically returns a structured view with:

• Computed limitation period (in years or the calculator’s unit)
• A “deadline” date (trigger date + limitation period, adjusted using BR rules configured in the calculator)
• A timing status relative to the filing date (e.g., timely / approaching deadline / at-risk)

Worked timeline (base example)

Using the assumed baseline facts:

• Trigger date: 2022-05-10
• Filing date: 2024-11-20
• No interruption/tolling flags applied

DocketMath computes a Brazil limitation deadline by applying the limitation period from the Brazil ruleset to the trigger date, then comparing it to the filing date.

Result (illustrative structure)

The calculator’s exact numeric outputs depend on its BR ruleset configuration for the selected claim category, but the logic flow is consistent:

What you can do with the output right away

Once you have the deadline and timing status, you can convert the output into practical next steps:

• If status is “timely”

  • Proceed with drafting using the timeline as a baseline risk check.
  • Still document the trigger-date assumption (often a short internal note is enough).
• If status is “approaching”

  • Pull critical tasks forward (evidence collection, witness declarations, notice/service steps) so you’re not relying on the edge of the deadline.
• If status is “at-risk”

  • Re-run with interruption/tolling options enabled (if those events plausibly apply to your facts).
  • Verify the trigger date rationale and the claim-category mapping you selected in the calculator.

Sensitivity check

Deadlines can change when you toggle interruption/tolling logic or adjust the trigger/filing dates slightly. This section shows how to “stress-test” your model using the same DocketMath workflow.

To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.

Sensitivity 1: Move the filing date later by 30 days

Keep everything the same except:

• Filing date: 2024-12-20 (instead of 2024-11-20)

Then re-run DocketMath.

Expected behavior:

• If the original filing date was comfortably before the computed deadline, the status may remain timely.
• If you were near the edge, a 30-day shift could flip you into at-risk or “approaching” territory.

Use this quick checklist:

Sensitivity 2: Change the trigger date by one month

Now adjust the start event:

• Trigger date: 2022-06-10 (instead of 2022-05-10)
• Filing date: keep 2024-11-20

Why this matters: a one-month trigger shift usually moves the computed deadline by a similar amount (unless the calculator applies rule-specific date boundaries/adjustments).

What to check:

Sensitivity 3: Enable interruption/tolling flags (when applicable)

Rerun the example with interruption/tolling enabled using the calculator’s Brazil rule toggles.

Because these events are highly fact-specific, treat this as a “what-if” rather than a definitive legal conclusion:

• Baseline: no interruptions
• What-if A: interruption flag enabled
• What-if B: tolling flag enabled

Compare results:

Sensitivity 4: Multiple “reasonable trigger dates” approach

If your facts support competing trigger candidates, model each one with the same filing date (2024-11-20) and compare which trigger keeps the filing timely:

• Trigger candidate A: 2022-05-10 (breach completed)
• Trigger candidate B: 2022-06-01 (first demand / notice)
• Trigger candidate C: 2022-07-15 (loss crystallized / payment missed)

Practical takeaway:

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