Spreadsheet checks before running Payment Plan Math in Brazil

What the checker catches

Before you run Payment Plan Math in Brazil (BR) with DocketMath, verify that your spreadsheet inputs won’t produce misleading outputs. The “spreadsheet checker” step is built to catch issues that commonly distort results—especially when payment schedules, dates, currency formatting, or installment logic are off by just one column or one formula.

Here’s what the checker focuses on.

Input quality problems (the ones that break math quietly)

• Date fields that aren’t true dates

  • Examples: 15/02/2026 stored as text, or a spreadsheet that mixes dd/mm/yyyy with mm/dd/yyyy.
  • Output impact: installment counts can shift, amortization timing can drift, and “first payment” may be treated as “last payment.”

• Payment frequency mismatches

  • Examples: you indicate monthly payments, but the schedule is actually built on “30 days,” or you provide a list of irregular dates but label it monthly.
  • Output impact: DocketMath may compute the wrong number of periods or incorrect period boundaries.

• Installment count conflicts

  • Examples: you provide both number_of_installments = 24 and a schedule table with 25 payment dates.
  • Output impact: totals won’t reconcile; the final balance may go negative or leave an unexplained remainder.

• Interest-rate formatting errors

  • Examples: entering 2.5 when the checker expects 0.025, or using comma decimals (2,5%) inconsistently.
  • Output impact: interest accrual can be off by a factor of 10, 100, or worse.

• Compounding vs. simple interest confusion

  • Examples: annual rate with monthly compounding assumed incorrectly (or vice versa).
  • Output impact: repayment totals and effective rate can diverge from what you intended.

Consistency checks that prevent “looks right” outputs

• Totals that don’t reconcile

  • Examples: sum of installment amounts ≠ principal + interest (or ≠ the total you used elsewhere in the sheet).
  • Output impact: Payment Plan Math may be correct for your inputs, but your sheet is internally inconsistent.

• Rounding drift

  • Examples: carrying many decimal places in one column but rounding to 2 decimals in another.
  • Output impact: the ending balance may not land at zero, creating an apparent error.

• Currency formatting issues

  • Examples: currency symbols included in numeric cells, or negative values formatted with parentheses.
  • Output impact: numeric parsing fails or flips sign.

Jurisdiction-aware rule reminders (BR)

Brazil-specific workflows often involve payment schedules tied to legal or administrative timelines. While the checker doesn’t replace legal analysis, it does validate the mechanics you provide—particularly:

• Brazil date conventions (DD/MM/YYYY)
• Period definitions aligned to the timeline you’re modeling (monthly/weekly/custom dates)
• Sign conventions (for example: whether installments are entered as positive payments reducing a balance, or negative cashflows increasing it)

When to run it

Run the spreadsheet checker at three distinct points in your workflow—before you compute, after you compute, and after you adjust inputs.

Run the checker before importing a spreadsheet into the Payment Plan Math workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

1) Before running DocketMath Payment Plan Math

Best time: immediately after you finalize spreadsheet inputs.

Checklist:

• Dates are real dates (not text)
• Installment count matches the schedule (if you use explicit dates)
• Interest rate is in the expected format (for example: percent vs decimal)
• Currency/number fields parse cleanly (no symbols in numeric fields)
• Frequency setting matches how your dates are spaced

2) After running Payment Plan Math (output verification)

Even with valid inputs, validate outputs against spreadsheet expectations:

• Ending balance is near zero (within your rounding tolerance)
• Total paid equals the sum of installment amounts
• Any “residual” (for example, 0.01) is explainable by rounding
• The schedule aligns with the intended start date and period spacing

3) After any spreadsheet edits (incremental changes)

Re-run when you change:

• start date / first payment date
• interest rate
• frequency
• number of installments
• principal amount
• additional payment adjustments (if your sheet supports them)

Try the checker

You can use DocketMath to run Payment Plan Math—but the fastest path to reliable results is:

(1) spreadsheet checker → (2) Payment Plan Math → (3) quick reconciliation checks

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Recommended input structure (so the checker can validate)

Use a consistent column layout. For example:

What you’ll see after running

After the checker runs, expect:

• A list of detected issues (with the specific field/column)
• A confirmation that date parsing and period logic are consistent
• Flags when schedule length, frequency, or totals don’t reconcile

Where to start

Use the primary call-to-action to begin your workflow:

• DocketMath Payment Plan Math: /tools/payment-plan-math

If you want to validate your broader workflow approach across tools, you can also browse:

• DocketMath tools hub: /tools

Related reading

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