Why Payment Plan Math results differ in Brazil

The top 5 reasons results differ

When you run DocketMath’s Payment Plan Math for Brazil (BR), small input and rule changes can produce noticeably different outcomes. That’s because the calculation depends on Brazil-specific execution details—including what’s counted as principal vs. fees, how installments are defined, and how rounding and timing are handled.

Here are the most common causes of divergence:

1. **Interest timing mismatch (start date vs. installment date)

   • Brazil payment-plan calculations often hinge on when interest begins accruing relative to the first payment.
   • If one run uses a contract signing date while another uses a notice/payment start date, the effective number of accrual periods changes.

2. **Principal composition changes (what you treat as the “base”)

   • If your amount includes costs, honoraria, or other add-ons in one dataset but excludes them in another, the amortization curve will shift.
   • The installment amount can look “off” even if the algorithm stays the same—because the principal base isn’t the same.

3. **Installment definition differences (fixed number vs. fixed end date)

   • Some inputs assume a fixed number of installments; others assume a fixed final date.
   • DocketMath may output different monthly values when the schedule is count-based (e.g., N installments) versus date-based (e.g., end date drives the cadence).

4. **Rounding strategy (round at the end vs. round each installment)

   • Brazil calculations frequently involve currency rounding per installment.
   • Switching from “round only at reconciliation” to “round each installment” can shift totals enough to create a different ending balance trajectory over longer terms (e.g., 12, 24, 36 months).

5. **Jurisdiction-aware fee inclusion (accruing vs. non-accruing components)

   • DocketMath can apply BR jurisdiction-aware assumptions for which components are treated as accruing over time.
   • If a fee is treated as accruing, it effectively becomes part of the balance base. If treated as non-accruing, it stays outside the interest base.

Gentle warning: Even when the visible inputs (amount, term, interest rate) match, results can diverge due to hidden inputs such as accrual anchor dates, principal breakdown, rounding-per-period rules, and fee classification.

How to isolate the variable

To pinpoint why your BR results differ, run a controlled diagnostic in one-factor-at-a-time fashion. The goal is to change only one assumption while freezing the rest.

Use this checklist workflow:

• Choose either a fixed number of installments or a fixed end date.

• Don’t mix assumptions between runs.

• Compare the “interest begins” date across both datasets.

• In DocketMath, confirm the first accrual anchor aligns with the first installment start logic.

• Ensure the “amount” you pass is defined consistently:

  • Principal only, or
  • Principal + costs/fees

• If one dataset includes costs/fees and the other doesn’t, totals and installment amounts will diverge.

• Identify whether installments are rounded each period or only at the final reconciliation.

• If one run rounds per installment and the other doesn’t, totals will drift.

• If you have separate fee inputs, ensure they’re categorized the same way across runs (e.g., accruing vs. non-accruing).

Fastest one-variable test (recommended):

1. Keep interest rate, term, and amount identical.
2. Change only the accrual start date.
3. Compare:

   • first installment amount
   • last installment amount
   • total paid
   • computed ending balance (under a consistent model, this should approach the expected endpoint behavior—often near zero)

Then repeat the same process with, one at a time:

Next steps

Once you identify the variable, you can make your results consistent without guessing.

1. Normalize your input schema for BR Maintain a canonical structure such as:

   • principal_amount (principal only)
   • interest_rate
   • accrual_start_date
   • installment_count OR end_date (choose one and use it consistently)
   • rounding_per_period (true/false)
   • fees_accrue (true/false if fees are separate)

2. Create a side-by-side comparison table Record your two runs to see where the divergence begins:

1. Re-run after each normalization Stop once installment amounts and totals match within your expected tolerance (often around 1–2 cents per installment depending on rounding rules).

To start quickly, use DocketMath here: **/tools/payment-plan-math

Related reading

• Payment Plan Math Guide for Alabama
• Payment Plan Math Guide for Arizona
• Payment Plan Math Guide for Colorado