How to run Payment Plan Math in DocketMath for Brazil

Step-by-step

This is a practical walkthrough for running Payment Plan Math in DocketMath for Brazil (BR) using jurisdiction-aware rules. This guide is about how to drive the calculator and interpret what you get—it is not legal advice.

• Select Brazil in the Payment Plan Math tool.
• Enter the trigger dates and any caps or rates.
• Run the calculation and save the output.

1) Open the Payment Plan Math tool

Start from the primary call to action:

• Go to: **/tools/payment-plan-math

Once you’re in the Payment Plan Math interface, confirm the calculator is set to Brazil (BR). Some DocketMath screens use a jurisdiction selector; others apply a jurisdiction-aware default based on your context.

2) Choose the payment plan structure

Next, pick the structure that matches how your plan is expected to work. In DocketMath, this usually means setting items like:

• Payment frequency (commonly monthly)
• Number of payments
• Start date / first due date (if the tool uses dates to build the schedule)

If your plan includes special behavior (for example, different amounts for later periods or a final balloon payment), look for inputs that support options such as:

• stepped payments (amounts by period), or
• a final/last payment override.

3) Enter the base amount (principal or starting balance)

Now enter the base amount the calculator should build the schedule from. Depending on how DocketMath labels the field, this may be one of:

• “Starting balance”
• “Principal”
• “Amount to be paid” (in some calculators, this still functions as the principal-like starting figure)

This input typically drives:

• the payment schedule totals
• the per-period amounts (especially if amortized)
• any interest/adjustment components (if you turn them on)

Tip: Use an amount you can verify. For example, if you know the outstanding balance at a known “as of” date, that’s a strong starting point for the math run.

4) Add interest/adjustment only if your scenario requires it

Payment plans in Brazil can involve interest-like adjustments depending on the underlying obligation and the model you’re trying to reflect. DocketMath’s Payment Plan Math may allow you to include components such as:

• Periodic interest rate
• Rate type (if selectable)
• Compounding frequency (if exposed)

If your scenario is principal-only, set interest/adjustment to 0 (rather than leaving it ambiguous). If your scenario should include a rate, enter it using the tool’s expected units.

Practical check before you run:

• Make sure the field expects a fraction (e.g., 0.12) or a percentage (e.g., 12), and confirm whether the rate should be monthly vs annual.

5) Configure due dates and any grace periods

If the tool supports date logic, configure:

• First payment due date
• Grace period (if there’s an option—e.g., payments begin 30 days after the schedule start)
• Any calendar behavior controls (if available), such as shifting payments that fall on weekends/holidays

Dates matter because they can change:

• how many periods the schedule counts,
• how time-based components accrue (when interest/adjustments are enabled),
• the exact calendar dates shown in the schedule table.

6) Verify assumptions in the results panel

Run the calculation and review everything the results panel provides. Look for:

• Payment amount per period (especially if amortized)
• Total paid across the plan
• Totals by component (principal vs interest/adjustment), if the breakdown is shown
• A payment schedule table (period-by-period)

Use the schedule table to sanity-check:

• Does the balance trend in the direction you expect?
• Is the final payment different when a last payment adjustment is expected?
• Do the schedule totals match the summary totals?

If the tool rounds, small differences in the final payment are normal—your goal is consistency between the schedule and totals, not perfect “every payment identical” results.

7) Adjust inputs and compare scenarios

If you need confidence, run multiple passes. A simple workflow is to change one variable at a time:

• payments: 24 vs 30
• rate: 0 vs a non-zero value (entered in correct units)
• first due date: earlier vs later

As a rule of thumb:

• increasing the number of payments usually changes the per-period amount (and may affect total cost if interest/adjustments apply)
• shifting the start/first due date can affect time-based components and therefore totals

Keep track of each set of inputs so you can explain why a scenario differs from another.

8) Export or capture the schedule for review

If DocketMath provides an export option (CSV/PDF) or a copyable schedule table, capture:

• the payment schedule
• the summary totals
• the inputs used for that scenario (jurisdiction, frequency, base amount, rate settings, and dates)

Even without providing legal advice, documenting your math inputs is essential for internal consistency and for communicating assumptions clearly.

Common pitfalls

These are common “it runs, but the results don’t match expectations” issues when running Brazil payment plan math in DocketMath:

• Wrong rate units

  • Example: entering 12 when the field expects 0.12, or entering an annual rate into a monthly-rate field.
• Frequency vs compounding mismatch

  • Example: monthly payments configured while interest/compounding is set as annual (or vice versa), if the UI exposes both.
• Off-by-one period due to date logic

  • Example: first due date or grace period settings cause one extra (or one fewer) period than intended.
• Using the wrong base amount

  • Example: entering a “total including interest” as the base principal while also enabling interest/adjustment in the tool.
• Interest/adjustment not actually disabled

  • If your scenario is principal-only, ensure interest/adjustment fields are set to 0 rather than left blank.
• Not checking the last payment and final balance

  • Rounding can make the last payment slightly different. Confirm the schedule behaves as expected (e.g., remaining balance goes to the expected endpoint, typically zero for an amortizing plan).
• Ignoring date shifting

  • If the tool shifts due dates to avoid weekends/holidays, it can change accrual timing and therefore totals.

Try it

Use this quick checklist to run your first Brazil (BR) scenario in DocketMath:

1. Select Brazil (BR) in the tool (if it’s not already set).
2. Enter a starting balance you can verify (e.g., an outstanding amount).
3. Choose payment frequency (monthly is common).
4. Set number of payments.
5. Set first due date (and grace period if the UI includes it).
6. Decide whether to include interest/adjustment:

   • principal-only: set rate to 0
   • include rate: enter it in the tool’s expected units
7. Run and review:

   • Total paid
   • Per-period payment
   • Schedule trend (balance decreasing toward zero, if you expect an amortizing plan)

If you’re testing for accuracy, start with a simple baseline:

• starting balance = 10,000 (or another clean round number)
• payments = 12 or 24
• rate = 0

Then rerun with interest enabled (correct units) and compare how totals change.

For reference, you can revisit the tool 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