Why Closing Cost results differ in Brazil
5 min read
Published April 15, 2026 • By DocketMath Team
The top 5 reasons results differ
Run this scenario in DocketMath using the Closing Cost calculator.
When you run the DocketMath closing-cost calculator for Brazil (BR), different outputs usually come from a small set of jurisdiction-aware assumptions. Even when you think you entered the same deal, small mismatches—like which closing-cost categories you include or which property/transaction role you selected—can change totals noticeably.
Here are the most common reasons results differ, in priority order:
**Category coverage mismatch (what’s included vs. excluded)
- Some workflows include ITBI, notary/cartório charges, registry fees, and stamp-tax-like items, while others omit one or more categories to match a “net to seller” vs. “total buyer cost” view.
- Result: totals can shift by large percentages if ITBI/registry items are toggled or filtered differently.
Municipality-based ITBI settings
- In Brazil, ITBI is handled at the municipal level, so the estimate depends on the municipality rule set you select and the assessed base used.
- Result: the closing-cost range can widen significantly when two runs use different cities/regions or different assessed-value assumptions.
Property type / transaction type assumptions
- Some components behave differently depending on whether the transaction is treated as a sale, assignment, or another transfer structure.
- Result: certain line items may appear in one run and not the other if the transaction type (or “role”) selection doesn’t match the documents/workflow reality.
Registration / cartório “bundle” differences
- Brazil’s process often bundles multiple cartório steps (document preparation, formalization, registration). If one model reflects a partial process while another reflects the full sequence, you’ll see different totals.
- Result: registry-related components can diverge even when the municipality and price/value are the same.
Rounding, payment timing, and fee basis
- Even with the same category set, differences can come from:
- rounding to whole currency units,
- applying a percentage to different bases (e.g., sale price vs. declared/assessed value),
- assumptions that effectively change how components roll up.
- Result: the final total may differ despite the inputs being “close.”
Pitfall: If two estimates differ, don’t assume the calculator is wrong. Start by verifying that both runs used the same category set, the same municipality assumptions, and the same transaction/property type selection.
For a quick reference point, use the tool directly at /tools/closing-cost.
How to isolate the variable
Use a “binary search” mindset: compare two runs and make them identical except for one variable. With DocketMath, you’re trying to pinpoint which input causes the gap.
- 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 checklist
- Confirm you both model the same perspective (for example, “buyer closing costs” vs. “total closing package”).
A mode difference alone can change which categories are included.
Ensure both runs specify the same municipality (or the same intended ITBI rule set).
If one run changes the municipality rate and/or assessed base, ITBI may explain most of the difference—especially if it’s the largest component in the breakdown.
Pick the same property and transaction type in both runs.
If the real documents reflect a different structure than the selection, fee components can shift.
Compare the included line items side-by-side.
If one run includes cartório/registry categories and the other omits them, that’s often the root cause.
Compare whether each run calculates percentage fees off sale price vs. declared/assessed value.
Also compare whether the calculator rounds intermediate values or only at the end.
What to look for in the output
- Use the DocketMath breakdown to identify the largest swing component.
- Change only the governing input for that component and re-run.
- If the biggest change is tied to ITBI, municipality/assessed base is usually the variable.
- If the biggest change is registry/cartório, it’s likely category coverage or how the workflow bundle is modeled.
- If categories are the same and only totals differ slightly, focus on rounding and fee basis.
Next steps
Run a baseline scenario
- Use the most accurate inputs you have for municipality, price/value basis, and transaction type.
Duplicate and change only one setting at a time
- Start with municipality (often the dominant driver in Brazil via ITBI).
- If the delta moves, keep focusing on that area. If it doesn’t, revert and test category coverage next.
Write down your assumptions
- Record which categories you included and which municipality rule set you selected.
- This prevents future “apples-to-apples” confusion and makes the comparison repeatable.
**Be careful about scope (gentle disclaimer)
- Closing-cost components can vary based on deal documents, workflow scope, and what specific parties expect to pay. DocketMath is a modeling tool, not a guarantee of exact charges.
For the fastest comparison, work directly within /tools/closing-cost and keep the two runs tightly aligned.
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
