Common deadlines mistakes in Massachusetts

The top mistakes

Running deadlines calculations in Massachusetts is mostly about getting the day-counting rules right—especially when you’re modeling the general limitations period. With DocketMath’s deadline calculator, these are the errors that most often produce an incorrect “last day” result.

1) Starting the clock on the wrong date

The most common “last day” errors happen when the input start date doesn’t match what actually starts the clock. Common mix-ups include:

• Using the filing date instead of the event/occurrence date (for example, when a breach occurred, when an injury happened, or when a contract was first violated).
• Using a notice date when the relevant clock actually runs from the underlying occurrence.
• Choosing the wrong received date when documents were exchanged.

What goes wrong in the output: your calculated end date can shift by weeks or even years, because the SOL window moves with the selected start date.

2) Counting days incorrectly (calendar time vs. business-day logic)

People often assume “deadlines” automatically mean “business days.” For SOL-style “last day” math, the safest approach is to treat the limitations period consistently with how the calculator is implemented—typically as a calendar-based interval unless an explicit rule changes the treatment.

What goes wrong in the output:

• If you skip weekends when you shouldn’t, the result can become too early.
• If you treat everything as business days (or mix approaches), you can end up with a date that’s systematically off.

3) Ignoring leap days and year boundaries

Even if you’re “adding 6 years,” leap years can still create edge-case errors. This tends to show up when:

• The start date is near February 29 or close to February/March transitions.
• The computation crosses multiple leap years over the life of the SOL period.

What goes wrong in the output: an off-by-one-day (or off-by-a-few-days) error near leap day, month boundaries, or year boundaries.

4) Misreading “6 years” as “add 6 to the year”

Two patterns cause “drift”:

• Adding 6 years by changing the year number but not preserving the correct month/day behavior (especially when the target year doesn’t have the same calendar day due to leap-year differences).
• Mixing calculation approaches (e.g., doing “6 × 365” in one step, then using a different method elsewhere).

What goes wrong in the output: the last day can slide—sometimes subtly—when leap days or date alignment matter.

5) Assuming the “general” 6-year period applies without confirming the assumption

It’s correct that the general SOL period is 6 years under Mass. Gen. Laws ch. 277, § 63. However, claim types can sometimes be governed by different timing rules. In this brief we did not identify a claim-type-specific sub-rule, so the guidance here stays on the default.

What goes wrong in the output: applying the general 6-year horizon when a different statute might govern can produce a result that is wrong by long periods (not just days).

6) Running once and never re-running after input updates

Deadline calculations often get done once, then treated as final. But small changes—like correcting the start/event date—can invalidate the “last day.”

What goes wrong in the output: the end date stays the same even after you correct key inputs, so your “last day” no longer matches the updated record.

How to avoid them

You can reduce SOL/deadline mistakes quickly by tightening inputs, aligning assumptions, and sanity-checking outputs.

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

Step 1: Anchor your inputs to a single, documented start date

Before running DocketMath, capture:

• Start date: the date you believe starts the clock (event/occurrence date).
• Time basis: whether you’re modeling the general SOL period.

Because the default is 6 years under Mass. Gen. Laws ch. 277, § 63, your first sanity check should be:

• “Am I intentionally using the general 6-year SOL period, not a claim-specific rule?”

Reminder: This is practical math guidance and not legal advice. If you’re unsure whether the general period applies, consider getting advice from a qualified professional.

Step 2: Use DocketMath’s deadline calculator consistently in one workflow

If you’re using DocketMath, keep a consistent approach:

• Run the calculation using your chosen start date.
• Record the calculated “last day.”
• Re-run whenever you adjust the start date or the assumption (general vs. something else).

Start the calculation here: **DocketMath deadline tool

Step 3: Confirm the general SOL assumption up front (and state it internally)

Since this brief found no claim-type-specific sub-rule, the default approach here is:

• General SOL: 6 years under Mass. Gen. Laws ch. 277, § 63

A quick checklist before trusting the “6-year later” output:

Step 4: Do a rounding/logic sanity check on the date result

After you compute the end date:

• Does the result keep the expected month/day relationship you’d anticipate from “6 years”?
• Is it unreasonably far from your expectation, given the start date?

If the computed end date is very close to your rough expectation (often within 1–2 days), that can indicate leap-year handling is consistent—but still verify rather than assume.

Step 5: Add a review trigger to every calculation

Make a workflow rule to re-run when:

• the event/occurrence start date changes
• any document date used as the start date changes
• you change the assumption (even if only to confirm you’re using the general SOL)

Step 6: Separate “SOL last day” from actual filing mechanics

A correct SOL “last day” under Mass. Gen. Laws ch. 277, § 63 does not automatically mean your filing will be treated as timely under court or administrative handling practices.

What to do: use DocketMath for SOL timeline math, and separately maintain internal operational deadlines (buffer time for preparation, submission, and any filing cutoffs).

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