Spreadsheet checks before running Deadline in Brazil

What the checker catches

Run this scenario in DocketMath using the Deadline calculator.

Before you run Deadline in Brazil with DocketMath, a spreadsheet checker helps prevent the most common “wrong date, wrong result” failures—especially when your inputs come from multiple systems (case management, spreadsheets, PDFs, or exported dockets).

In a jurisdiction-aware workflow (jurisdiction: BR), the checker focuses on problems that typically cause Deadline to compute from the wrong day, ignore the intended starting point, or misalign rows.

Common spreadsheet issues it flags (Brazil-focused workflow)

Gentle warning: If your spreadsheet stores dates as text (common after Excel exports or older imports), Deadline might still produce output—yet the result can be incorrect (for example, misinterpreting values or failing to apply date math). The checker is meant to surface these patterns before they corrupt your deadline output.

Input fields it validates (typical columns)

A reliable Brazil setup usually includes columns like:

• Case identifier (e.g., ProcessNumber or your internal ID)
• Event date (the date the clock starts from—often labeled “from”)
• Event type (the category that your team uses, such as “filing”, “publication”, “notification”)
• Jurisdiction code: BR
• Optional: “deadline basis” indicators (if different event subtypes map to different computation rules)

Then the checker can enforce consistency, such as:

• every row has a valid event date
• every row is tagged as BR
• event types are populated (or at least not left blank for rows you plan to calculate)

How the output changes when checks pass vs fail

The key value is that issues are detected before you run Deadline.

Depending on your run mode, you may see outcomes like:

• Hard stop: the checker blocks execution until required cells (like the event date / “from” date) are corrected.
• Soft stop / row-level warnings: the checker flags specific rows so you can fix them without discarding everything.
• Normalization: ambiguous inputs (like datetimes that should be date-only) may be converted into the expected type so Deadline uses the intended day.

Use this quick checklist view:

When to run it

A spreadsheet checker pays off most when you’re about to do batch calculations, rerun after edits, or coordinate work across multiple people.

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.

Best timing: run it at these moments

1. Immediately after importing or exporting your spreadsheet

   • Excel exports often convert dates into text.
   • Copy/paste can introduce formatting differences that look identical visually.

2. Before any batch run of DocketMath Deadline

   • Treat Deadline as a “calculation engine,” not a data cleanup tool.
   • The checker validates inputs so the math is applied to clean, predictable fields.

3. Whenever you update event dates

   • If you revise one “notification” date, you want the affected rows recomputed using the corrected starting point.
   • Rechecking helps prevent stale rows or mismatched event/date pairs.

4. After you filter, sort, or delete rows

   • Filters can change which rows are visible while leaving underlying data intact.
   • Sorting/deleting can create duplication or misalignment between columns.
   • The checker helps reconcile row counts and detect integrity problems before you compute.

A practical cadence that works in real teams

• Step 1 (5 minutes): run the spreadsheet checker on the full dataset
• Step 2 (10–20 minutes): fix the flagged rows (usually formatting or alignment issues)
• Step 3: run Deadline via Primary CTA: /tools/deadline
• Step 4: re-run the checker if you modified any date-related columns since the last run

Pitfall to avoid: Running Deadline first, then trying to “clean” the outputs, is risky. When inputs were wrong, it can be hard to tell which issues are “data problems” vs “calculation results.”

Try the checker

You can test a repeatable workflow with DocketMath by validating Brazil (BR) inputs before computing deadlines.

1. Prepare your spreadsheet so each row includes:

   • a case identifier
   • an event “from” date
   • the event type label (whatever your internal process uses)
   • jurisdiction code BR

2. Run the checker to catch:

   • date formatting issues (including text dates)
   • missing start dates
   • row alignment problems across columns
   • basic integrity mismatches (like duplicates or inconsistent row counts)

3. After the sheet passes, compute deadlines using DocketMath Deadline via the primary action:

   • Primary CTA: /tools/deadline

What to look for in a “clean input” sheet

If you want a quick “do we have clean inputs?” test, look for:

• no blank event dates
• consistent date formatting across the sheet
• date values that behave like dates (not text)
• event type filled for every row you intend to calculate

And when you’re setting up the run, use the tool page as your reference point:

• /tools/deadline

What you’ll get from the run

Once the checker clears your inputs and you run Deadline:

• rows with valid data receive computed deadline dates (and any configured derived outputs)
• rows with invalid data are identified so you can correct and re-run without guessing

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