Why Closing Cost results differ in Missouri

The top 5 reasons results differ

If you’re seeing different Closing Cost numbers in Missouri from DocketMath, the cause is almost never “the math.” Instead, it’s usually how an input is mapped to Missouri jurisdiction-aware rules (including statute-backed assumptions). Here are the top 5 causes that commonly change outputs when using the Closing Cost calculator (US-MO) via the /tools/closing-cost workflow.

1) Closing-cost base differs (what’s treated as “closing”)

Some users include lender fees while others exclude them. Even when the same dollar amounts are entered, results can diverge if DocketMath’s input mapping interprets categories differently (for example, separating origination-type fees from third-party settlement charges).

What changes outputs: the set of line items you tell the calculator to treat as closing costs.

2) Timelines change the value used for downstream adjustments

Missouri’s default statute of limitations used in the calculator logic can affect any time-based component of the calculation. Missouri’s general limitations period is 5 years under Mo. Rev. Stat. § 556.037.

Because the brief notes that no claim-type-specific sub-rule was found, DocketMath should apply this general/default period rather than a shorter/longer category-specific one. That default (5 years) can shift results compared with tools or scenarios that assume different timing logic.

Statute reference: Mo. Rev. Stat. § 556.037 (general SOL period = 5 years): https://law.justia.com/codes/missouri/title-xxxviii/chapter-556/section-556-037/

3) Borrower vs. settlement charge payer assumptions

Closing costs can be allocated differently depending on who pays what (borrower, seller, or split). If two runs swap payer assumptions—even with identical fee dollars—totals and net estimates can change.

What changes outputs: the payer allocation flags (or equivalent selections) tied to each cost line item.

4) Rounding and fee normalization

Different inputs can land on different rounding paths—especially when percentages are involved (e.g., a fee entered as a percent of the loan amount, or a fixed fee that is later converted into a time-related adjustment).

What changes outputs: the loan amount and percent-based fee entries, plus whether any normalization/rounding rules apply in your scenario.

5) Date-related inputs (effective date vs. incident date)

In Missouri workflows, date selection can matter because it affects the elapsed time used in calculations that tie into limitations logic. With a 5-year default SOL, even a few months can move the calculation into a different timing bucket.

What changes outputs: the entered start date/end date (or which date field is treated as the “event” date).

How to isolate the variable

Use DocketMath to run a controlled “difference hunt.” The goal is to change only one thing per run and observe which output component moves.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

Step-by-step debugging checklist

A quick isolation method

Run these three passes:

1. Baseline run (Run A): all inputs exactly as you currently use them
2. Timing-only run (Run B): same fees, change only the date fields
3. Fee-mapping run (Run C): same dates, change only which costs are included as “closing”

Then compare:

• If A vs. B differs materially → timing/date mapping is the driver
• If A vs. C differs materially → closing-cost category mapping is the driver
• If both differ → the issue is likely payer allocation + timing (or rounding)

If you need to start from scratch, open DocketMath here: /tools/closing-cost.

Next steps

1. Confirm the jurisdiction default is being used
   In Missouri, DocketMath should rely on the general/default SOL period of 5 years under Mo. Rev. Stat. § 556.037. Since no claim-type-specific sub-rule was found, don’t assume the calculator will automatically swap to a different SOL category based on claim labels.

2. Document your input set
   Save (or screenshot) the exact inputs used in the run:

   • included/excluded closing-cost line items
   • payer allocation selections
   • the date fields used
   • loan amount and how percent fees were entered

3. Re-run with one controlled change
   After you identify whether the driver is timing, fee mapping, payer allocation, or rounding, make the smallest adjustment needed to match your intended scenario.

4. Standardize comparisons
   If you’re comparing two computers/users:

   • use the same calendar dates
   • use the same fee categories
   • enter percent fees using the same format (e.g., 1.25% vs 0.0125)

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