Abstract background illustration for How Closing Cost rules vary in Minnesota

How Closing Cost rules vary in Minnesota

6 min read

Published June 4, 2026 • By DocketMath Team

Partially verified

older_than_packet

How Closing Cost rules vary in Minnesota

Closing costs aren’t governed by a single “one-size-fits-all” formula. In Minnesota, a major driver of transfer-related closing costs is the state’s deed transfer tax and the mortgage registry tax. These taxes are governed by Minnesota statutes, and they change what DocketMath will calculate when you choose different property and loan inputs.

This post explains how the rules vary in Minnesota, what you need to verify before you rely on a number, and how to use DocketMath’s closing-cost calculator to keep the result jurisdiction-aware.

Note: This page covers the general/default period only. No claim-type-specific sub-rule was found in the provided jurisdiction data, so this guide does not assume special handling for particular transaction categories beyond the stated deed and mortgage transfer taxes.

What varies by jurisdiction

In Minnesota (US-MN), the most “jurisdiction-identifying” closing-cost components in the state statutes you provided are:

  1. Deed tax (transfer tax on deeds)
    • Governed by Minn. Stat. § 287.21 (deed tax).
  2. Mortgage registry tax
    • Governed by Minn. Stat. § 287.04 (mortgage registry tax).
  3. Statutory transfer tax framework

Why this matters for DocketMath

DocketMath’s closing-cost output shifts based on whether your scenario includes:

  • a deed transfer (typical for many purchases and other ownership transfers), and/or
  • a recorded mortgage (typical when a lender records a mortgage during the transaction).

Even when the calculator’s mechanics are conceptually similar across jurisdictions, Minnesota’s tax structure makes correct inputs (and correct inclusion/exclusion of tax lines) especially important.

Key jurisdiction-driven variability (Minnesota-specific)

Below is a practical mapping of “what changes the result” to the Minnesota tax concepts your inputs typically represent.

Input you provideMinnesota rule it affectsTypical outcome shift
Property “consideration” / deed value (amount tied to deed transfer)Minn. Stat. § 287.21 (Deed tax)Higher stated consideration generally increases deed tax
Mortgage amount / principal (amount tied to recorded mortgage)Minn. Stat. § 287.04 (Mortgage registry tax)Higher recorded mortgage generally increases mortgage registry tax
Whether the transaction includes a recorded mortgageMinn. Stat. § 287.04If there’s no recorded mortgage, that line item should not be included
Whether there’s a deed transferMinn. Stat. § 287.21If there’s no deed transfer, deed tax should be excluded

What to verify

Before you run DocketMath’s closing-cost calculator, verify the details that Minnesota law (and closing/recording practices) effectively “lock in.” This isn’t legal advice—it’s about confirming the numbers that feed the tax computations.

1) Confirm which transfer taxes apply to your transaction

Use this checklist to align your inputs with Minnesota’s deed and mortgage taxes:

  • Is there a recorded deed transfer?
    If yes, include deed tax assumptions tied to Minn. Stat. § 287.21.
  • Is there a recorded mortgage?
    If yes, include mortgage registry tax assumptions tied to Minn. Stat. § 287.04.
  • Are you modeling purchase vs. refinance vs. other ownership changes?
    Even without claim-type-specific sub-rules in the provided data, the presence of a deed and/or recorded mortgage is what typically determines whether these tax streams appear in the calculation.

2) Make sure your “base amounts” match how the lender/closing statement frames them

DocketMath can only compute what you enter. Minnesota tax calculations generally turn on transaction amounts that correspond to:

  • transaction consideration tied to the deed, and
  • the mortgage principal tied to the recorded mortgage.

Practical steps:

  • Pull the contract sales price / consideration figure that your closing documents treat as deed consideration.
  • Pull the loan amount / mortgage principal that the recorded mortgage reflects.

Pitfall: People sometimes enter a sales price into a “mortgage amount” field (or enter loan principal into a “deed consideration” field). Even if the calculator’s math is correct, swapping the bases will produce an incorrect Minnesota transfer tax total.

3) Use the statute citation as your anchor

When you’re validating a computed amount, anchor to the statute text and verify that the calculator’s rate logic matches the applicable provision.

Statutes to use for Minnesota (from your provided sources):

4) Run two scenarios if documentation is unclear

If your closing documents aren’t finalized, model a conservative “upper/lower” range by changing only the base amount tied to each tax:

  • Scenario A: deed exists + mortgage exists (common for financed purchases)
  • Scenario B: deed exists only
  • Scenario C: mortgage exists only

In DocketMath, keep everything else fixed and vary:

  • deed consideration → affects § 287.21
  • mortgage principal → affects § 287.04

Using DocketMath for Minnesota closing-cost estimates

Start with the primary CTA and keep your inputs aligned to the two Minnesota statutory buckets:

  • Use DocketMath here: /tools/closing-cost

As you fill the calculator, sanity-check your results against the presence/absence of:

  • deed transfer (Minn. Stat. § 287.21)
  • recorded mortgage (Minn. Stat. § 287.04)

If DocketMath shows line items that don’t match your transaction documents, adjust:

  • whether the deed transfer amount is included, and/or
  • whether the mortgage amount is included.

Related reading

Sources and references

  • Minnesota statutes (transfer tax framework): https://www.revisor.mn.gov/statutes/cite/287
    • Minn. Stat. § 287.21 (Deed tax)
    • Minn. Stat. § 287.04 (Mortgage registry tax)
  • TODO: If you want, share the specific closing statement fields you’re using (e.g., “consideration,” “mortgage amount,” or “loan principal”) and I can outline which calculator inputs best map to those fields—without changing the underlying statutory basis.