Worked example: Closing Cost in Maine

Example inputs

Below is a worked example of a closing cost calculation in Maine (US-ME) using DocketMath with jurisdiction-aware rules.

Because you didn’t provide any claim-type-specific sub-rule for Maine closing costs, this example uses the default/general statute period you supplied:

• General SOL period: 0.5 years
• General statute: Title 17-A, § 8
• Source: https://legislature.maine.gov/statutes/17-a/title17-asec8.html?utm_source=openai
• How to interpret the “no sub-rule found” note: DocketMath applies the general/default period since no claim-type-specific SOL sub-rule was identified in the jurisdiction data you provided.

Before the run, collect the inputs you’ll feed into DocketMath. In practice, these often come from the contract terms, HUD/Loan Estimate materials, or settlement documents.

Inputs (example values)

Assume the following scenario:

• Property/transaction type: residential (no special claim-type rule assumed)
• Event date (start marker): 2026-01-15 (e.g., date of closing or other triggering event)
• Cost amount to evaluate: $12,500
• Claim filing date: 2026-07-20
• Jurisdiction: Maine (US-ME)

Tip: The event date (the start marker) and the claim filing date are what drive the timing check. The $12,500 is the amount you’re evaluating in the closing-cost review workflow (while the timeliness logic is determined by the dates).

Quick reference: the Maine timing rule used here

In this example, DocketMath uses:

• General SOL period: 0.5 years
• Legal anchor: 17-A M.R.S. § 8 (as provided in the jurisdiction data)

Example run

To run the calculator in DocketMath, use the closing-cost tool:

• Primary CTA: /tools/closing-cost

And set the jurisdiction to Maine (US-ME).

Run the Closing Cost 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.

Run setup

1. Select Calculator: closing-cost
2. Select Jurisdiction: US-ME
3. Enter:

   • Event date: 2026-01-15
   • Claim filing date: 2026-07-20
   • Cost amount: $12,500

Step-by-step timing math (what DocketMath computes)

Even though DocketMath handles the detailed conversion logic, it helps to understand the boundary being tested.

1) Compute the SOL deadline from the event date

• SOL period: 0.5 years
• Event date: 2026-01-15

Half a year from 2026-01-15 is approximately:

• SOL deadline: ~ 2026-07-15

In other words, the decision boundary in this example is based on event date + 0.5 years.

2) Compare the filing date to the SOL deadline

• Claim filing date: 2026-07-20
• SOL deadline: ~ 2026-07-15

Because 2026-07-20 is after 2026-07-15, the run is outside the 0.5-year general window used here.

Expected output (worked example result)

In this example, DocketMath’s output is driven by whether the filing date lands before or after the computed timing deadline:

Outcome: The calculator flags the run as timed beyond the 0.5-year general SOL window.

Gentle usage disclaimer (non-legal advice)

This worked example is meant to show how DocketMath applies the provided jurisdiction data to a timing-based closing-cost review. It isn’t legal advice, and real-world results can vary based on additional facts and any other rules that may be applicable beyond the general/default period used here.

Sensitivity check

A practical way to validate a timing-driven calculator is to change one input at a time and observe whether the output flips when you cross the deadline.

Here are three targeted sensitivity tests, holding everything constant except the variable noted.

Sensitivity test A: Filing date moved earlier (within the window)

Change claim filing date:

• Event date: 2026-01-15 (same)
• Filing date: 2026-07-10 (moved earlier)
• Cost amount: $12,500 (same)

Compare to the approximate deadline:

• Deadline ~ 2026-07-15
• 2026-07-10 is before the deadline

Expected DocketMath behavior: the timing outcome should change to within the general SOL period.

Sensitivity test B: Filing date moved later (further outside the window)

Change claim filing date:

• Filing date: 2026-08-10

This is clearly beyond the approximate deadline (~ 2026-07-15).

Expected DocketMath behavior: the timing outcome remains filed after deadline.

Sensitivity test C: Event date moved later (deadline shifts)

Change event date while keeping filing date constant:

• Event date: 2026-02-01
• Filing date: 2026-07-20
• Cost amount: $12,500 (same)

Recompute the deadline with the same general period (0.5 years):

• Deadline ~ 2026-08-01

Now:

• 2026-07-20 is before ~2026-08-01

Expected DocketMath behavior: the timing outcome should switch back to within the general window.

Pitfall to watch: If the “event date” you enter is inconsistent with your workflow’s definition of the triggering date (for example, using the wrong closing-related milestone), the computed deadline may shift enough to flip the result.

What this sensitivity check confirms

• The decision boundary in this example is based on a deadline derived from event date + 0.5 years.
• The general/default rule controls because no claim-type-specific sub-rule was identified.
• With a 0.5-year period, date changes on the order of weeks (and sometimes even shorter, depending on the exact conversion) can meaningfully affect whether the outcome is “within” vs “after.”

Related reading

• Average closing costs in Alabama — Rule summary with authoritative citations
• Average closing costs in Alaska — Rule summary with authoritative citations
• Average closing costs in Arizona — Rule summary with authoritative citations