The top 5 reasons results differ

If you’re using DocketMath to run an Arkansas closing-cost calculation and your outputs don’t match someone else’s, the mismatch is usually caused by inputs and jurisdiction-aware rules—not a “math error.” For Arkansas (US-AR), DocketMath uses the default statute of limitations (SOL) rule: 6 years under Ark. Code Ann. § 5-1-109(b)(2).

Importantly, no claim-type-specific sub-rule was found for this calculator scenario, so you should expect the same 6-year default across the general use cases the tool covers.

Below are the most common reasons results differ in US-AR.

1. **Start date of the clock (event date vs. filing date)

   • A frequent issue is entering the “wrong” date as the start of the 6-year SOL.
   • Even a small date shift can move amounts from inside the window to outside it (depending on how the tool applies boundaries).

2. Different treatment of “closing costs” line items

   • Closing costs might be entered as:

     • one lump sum, or
     • separated categories (fees, prepaid items, etc.).
   • DocketMath will only calculate what you feed it—so mismatched formatting can produce mismatched outputs even when the totals look similar.

3. Partial payments, refunds, or credits not entered consistently

   • If one run includes a refund/credit and another doesn’t (or if the timing differs), the net closing cost changes.
   • That net change then affects downstream results tied to inclusion/exclusion logic.

4. Inconsistent jurisdiction assumptions

   • DocketMath is jurisdiction-aware. If another workflow accidentally uses a different state’s rule set, the SOL window length/logic can differ.
   • For Arkansas in this context, the default expectation is 6 years under Ark. Code Ann. § 5-1-109(b)(2).

5. **Different SOL windowing logic (counting conventions)

   • Two runs might both say “6 years,” but still differ in whether boundary dates are counted inclusively/exclusively.
   • DocketMath uses its own deterministic approach based on the inputs you provide, so make sure your dates map cleanly to the tool’s fields.

Most common pitfall: A swapped date—especially using a “transaction date” where the tool expects the SOL start date—can flip outcomes under the 6-year default in Ark. Code Ann. § 5-1-109(b)(2).

How to isolate the variable

To diagnose differences quickly, run a controlled comparison: change one input at a time, keeping everything else identical.

Start with the tool here: **/tools/closing-cost

Isolation checklist (do these in order)

• For Arkansas here, the default SOL is 6 years under Ark. Code Ann. § 5-1-109(b)(2).

  • Because no claim-type-specific sub-rule was identified, you generally should not see different SOL periods unless the other workflow used a different rule set or jurisdiction.

  • Use the same closing-cost total (or the same breakdown categories) across both runs.

  • If one workflow used categories and the other used a lump sum, align the input structure.

  • Compare:

    • Run A: original SOL start date
    • Run B: corrected SOL start date

  • If outputs swing meaningfully, the start date is likely the driver.

  • If your process includes a cutoff (often labeled “as of”), test that next.

  • Boundary effects are most likely near the end of the SOL window.

  • Add or remove only the refund/credit line item (and keep amounts the same otherwise).

  • If outputs change after this step, your mismatch is in net cost modeling, not timing.

Quick reference (what usually moves)

Gentle note: This is not legal advice—use it to troubleshoot data and tool inputs so you can reconcile differences consistently.

Next steps

Once you isolate the variable, reconcile the two workflows using the same “evidence trail.”

1. Write down the exact dates

   • SOL start date
   • calculation cutoff / “as of” date (if applicable)
   • any filing/demand dates you used to derive the SOL start date (only if they were used in your process)

2. Match the closing-cost structure

   • If the other workflow used categories, mirror that category structure in DocketMath instead of converting everything into a lump sum.

3. Confirm the SOL basis you’re applying

   • For Arkansas in this calculator context, the default is 6 years under Ark. Code Ann. § 5-1-109(b)(2).
   • Since no claim-type-specific sub-rule was identified, you should generally see one default SOL period when the jurisdiction is correctly set to US-AR.

4. Rerun after each adjustment

   • Re-run DocketMath after each single change so you can confirm causation, not just correlation.

Related reading

• Browse the blog

The top 5 reasons results differ

• Different trigger dates or event definitions were used.
• Inputs were entered with different day-count or compounding assumptions.
• Payments, credits, or tolling periods were handled differently.
• Jurisdiction or court settings did not match the matter.
• Rounding or cutoff-time rules were applied inconsistently.

How to isolate the variable

• 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.

Next steps

Run the Closing Cost calculator now and save the inputs alongside the result so the workflow is repeatable. You can start directly in DocketMath: Open the calculator.

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

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