Why Deadline results differ in Brazil

The top 5 reasons results differ

Run this scenario in DocketMath using the Deadline calculator.

When you run the DocketMath deadline calculator for Brazil (BR), results can diverge across people, workflows, and case types. Those differences usually come from jurisdiction-aware rules interacting with how you entered inputs (especially dates and the deadline “type” profile).

Below are the most common causes—ranked by how often they show up in real workflows.

1. Holidays and “non-business” day handling

   • Brazil’s deadline counting may depend on whether a date is treated as a business day versus a holiday (in practice, this can vary by how workflows model federal vs. local observances).
   • If one workflow uses a generic holiday set while another uses a jurisdiction-specific calendar, the computed “last day” can shift by 1–N days.

2. **Start date misalignment (event date vs. service date vs. entry date)

   • Deadline calculations depend on the trigger date (for example, the date of citation/intimation, publication, or another procedural act).
   • Systems often disagree on what a “received” date means—some store the event date, others store the system entry date.
   • Even a single-day shift can cascade into a different expiration date.

3. Inconsistent treatment of weekends / non-business days

   • Some teams exclude weekends automatically; others rely on “business-day” settings.
   • If your configuration already excludes non-business days but your input date range or “trigger date” definition has already been pre-adjusted, you can get double-exclusion, arriving earlier than expected.

4. **Wrong rule profile (case type / proceeding context / deadline category)

   • Brazil deadlines can vary based on procedural context and how a timeline is categorized.
   • In DocketMath, jurisdiction-aware calculations expect the correct mapping between the procedural act you’re computing and the selected deadline category/type.
   • If the wrong category is selected, the tool can produce a legitimately different result—even if every date you entered is correct.

5. Timezone / timestamp normalization

   • If your source data contains timestamps (not just dates), timezone conversion can move an event across midnight.
   • Two teams may both say they used the “same date,” but one derived it from UTC and the other from local time (BRT)—producing a date flip and therefore a different deadline.

Gentle note: These mismatches often look like “the calculator is wrong,” but they’re frequently calendar + start-date definition issues. The fastest fixes come from standardizing how you define the trigger date and how you load the business-day/holiday logic.

How to isolate the variable

Use a tight diagnostic workflow: change one input factor at a time, then compare the DocketMath output. Don’t adjust multiple settings in the same run, or you won’t know what caused the difference.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

Step-by-step checklist (single-variable tests)

• Identify the canonical field you intend to use (e.g., “event date” vs. “intimation date” vs. “system entry date”).

  • Run DocketMath multiple times, each time swapping only the trigger date source.

  • Look for a consistent shift (often about 1 day, unless a weekend/holiday boundary is crossed).

  • Ensure both runs use the same holiday/business-day logic.

  • If your workflow allows selecting a calendar basis, keep it identical across teams.

  • If your pipeline includes timestamps, convert them to date-only in one agreed timezone before entering DocketMath.

  • Then re-run using the normalized dates.

  • If results converge after normalization, timezone conversion was the culprit.

  • Confirm the selected deadline category/type corresponds to the procedural act you’re calculating.

  • A wrong profile can change the computed due date even when start dates and calendars are correct.

  • If DocketMath shows any intermediate values (like counted days, or how it adjusted the last day), compare those too.

  • Intermediate differences make it easier to pinpoint whether the issue is calendar handling, start-day selection, or profile logic.

Quick comparison table

Next steps

1. Standardize your “deadline record” inputs

   • Save (at minimum) the following per calculation:

     • Trigger date as date-only (timezone-normalized)
     • Selected deadline type/profile
     • The calendar basis used for business days/holidays

2. Create a mismatch worksheet

   • For each discrepancy, record:

     • Exactly what values were entered into DocketMath
     • The computed due date
     • Which single variable changed between Run A and Run B

3. Validate with a 3-case test set

   • Pick three examples that stress common failure points:

     • One near a holiday
     • One that crosses a weekend
     • One where the source event is close to midnight
   • If DocketMath matches expectations across these, your pipeline inputs are likely consistent.

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