How to run deadlines in DocketMath for Australia

7 min read

Published April 8, 2026 • By DocketMath Team

Step-by-step

Run this scenario in DocketMath using the Deadline calculator.

This guide shows how to run deadlines in DocketMath for Australia (AU) using the Deadline calculator. The goal is to turn messy dates (filing dates, notice periods, extensions) into a clear “deadline on calendar” output you can share internally.

Note: This post explains how to use DocketMath for deadline calculations. It’s not legal advice about what deadlines apply to your situation—if you’re unsure which rule governs a matter, get qualified advice.

1) Open the Deadline calculator

  1. Go to /tools/deadline
  2. Select Australia (AU) if the jurisdiction isn’t already set.
  3. You should see fields for the deadline inputs (commonly: a start date and a time period/unit).

2) Choose what your deadline is “counting from”

Most deadline problems in practice come down to one decision: what is the start date for counting.

Typical examples:

  • A date a document was served
  • A date a notice was given
  • A filing date, event date, or decision date
  • A “from now” date in operational workflows

In DocketMath, you’ll enter that start date in the relevant field (often labeled something like Start date).

What changes in the output:

  • Every downstream deadline date shifts if the start date shifts.
  • Even a one-day change in the start date can move the final deadline by one day.

3) Enter the duration and unit accurately

Next, input the time period:

  • Number (e.g., 14, 28, 56, 3)
  • Unit (e.g., days, months, years—depending on what the calculator supports)

Common patterns in AU workflows:

  • “14 days after …”
  • “28 days from …”
  • “3 months after …”
  • “1 year after …”

What changes in the output:

  • Switching days to months (or vice versa) changes the method used to compute the calendar date.
  • Using months can preserve a day-of-month when possible (and roll forward when not), which will not match a “same number of days” approach.

4) Add any offset rules your workflow needs

Some deadline scenarios require additional timing logic beyond “start + period,” such as:

  • Extra days for internal review
  • A buffer period before the absolute deadline
  • A “submit by” date that’s earlier than the “deadline on paper”

If DocketMath’s Deadline calculator includes an additional offset field (or “add/subtract” option), use it to match your process.

Operational example (workflow, not legal advice):

  • If the “hard deadline” is 30 days after notice, you might set:
    • Hard deadline: calculated normally
    • Internal submission date: subtract 3–5 business days for drafting/QA

5) Review the calculator’s results

After you run the calculation, DocketMath will present one or more computed dates (often including):

  • The computed deadline date
  • A “calendar view” or summary of inputs/outputs

Check the output carefully:

  • Does it land on the day you expect?
  • Does it look like a calendar date rather than a time span?
  • Are you consistent about “counting from” the correct event date?

Quick sanity checks:

  • If you chose “months,” confirm the day-of-month behavior matches what you expect.
  • If you chose “days,” confirm the scale aligns with your intended period.

6) Export or reuse the result in your matter workflow

Use the tool output directly in your tasking:

  • Create a task due date based on the computed deadline
  • Attach it to your deadline tracker
  • Share the computed date in internal checklists

If you maintain a recurring workflow, save the key inputs and rerun the calculator when the start date changes (for example, a new service date).

7) Run multiple deadlines for one matter (recommended)

Real matters typically have more than one deadline (and they often depend on different triggers). Instead of trying to force everything into a single calculation, run separate calculations per trigger.

Use a table like this in your notes:

TriggerStart date you enteredPeriodCalculated deadline
Service/notice2026-04-0814 days(run in DocketMath)
Filing task2026-04-0828 days(run in DocketMath)
Internal review buffer2026-04-08subtract 5 days(run in DocketMath)

8) Validate against internal expectations

Before you rely on the output operationally, run at least one “back-of-the-envelope” check:

  • If the period is 14 days, your deadline should be roughly two weeks after your start date.
  • If the period is 3 months, your deadline should be in the corresponding month, not hundreds of days away.
  • If you added an offset, confirm it moves the date in the direction you intended.

Common pitfalls

Deadlines in Australia often go wrong due to input misunderstandings—not because the calculator fails. Here are the mistakes that most commonly create a wrong date.

Warning: Deadline errors can cascade into missed filing or internal escalation failures. Treat the first run as a “test,” then lock it in once you’re satisfied with the inputs.

1) Counting from the wrong event date

If you accidentally use:

  • the decision date instead of the service date, or
  • the date received instead of the date given,

your output will be consistently wrong.

Fix: Re-check what your workflow means by “start date” and make it consistent.

2) Mixing up “days” and “business days”

Many legal timelines use concepts like “business days” or “working days,” but your operational calendar may be different.

If DocketMath’s Deadline calculator is set up for calendar days (common in simple deadline calculators), entering “14 business days” as “14 days” will produce the wrong result.

Fix: Use the calculator unit that matches your intent, and if you need business-day logic, reflect it in your offset/buffer step.

3) Using “months” when you meant a fixed number of days

Months behave differently than days. For example:

  • 1 month is not always 30 or 31 days.
  • Month-to-month computations follow calendar rules, not a constant daily count.

Fix: Confirm the unit you enter matches the period you’re modeling.

4) Forgetting internal buffers

A common operational pattern is having a “hard deadline” but requiring earlier submission for drafting/review.

If you skip buffers, you’ll likely compress your schedule too late.

Fix: Use an offset/subtract step so your task due date is earlier than the calculated deadline.

5) Updating only the start date and not the rest

If your start date changes and:

  • the period stays the same, great. But if the period also changes (e.g., different notice types), you might only update one field.

Fix: For each run, compare both:

  • the start date, and
  • the duration/unit.

6) Reusing results without rerunning

If the matter’s trigger date changes, old output becomes stale.

Fix: Treat each calculated deadline as tied to a specific trigger date set of inputs.

Try it

Run a quick exercise to build confidence:

  • Start date: today’s date in your timezone (or your actual example trigger date)
  • Duration: 14 days
  • Offset: subtract 3 days (optional, to simulate an internal review buffer)

Then compare:

  • The “hard deadline” result (start + 14 days)
  • The internal “submit by” date (hard deadline minus 3 days)

If the dates don’t move exactly the way you expect, pause before using it for real work.

To streamline your workflow, start directly at /tools/deadline and run the same calculation for each distinct trigger date you track.

Related reading