Spreadsheet checks before running Structured Settlement in Brazil

What the checker catches

Running a structured settlement in Brazil with DocketMath starts with getting your spreadsheet inputs right. In this context, the most common “failures” aren’t legal problems—they’re data-quality issues. Those issues later show up as review delays, calculation errors, or drafts that can’t be trusted because the underlying inputs didn’t parse correctly.

DocketMath’s Spreadsheet Checker (structured-settlement) is built to surface these issues before you run calculations. In practice, it focuses on three categories:

1) Spreadsheet schema issues (columns, formats, required fields)

Typical problems the checker catches include:

• Missing required columns, such as a payment date, an amount, a beneficiary/adjudicated claimant reference (if your template uses one), and a payment type (where applicable).
• Wrong header names, including case differences, renamed fields, or merged header rows that shift column detection.
• Date parsing failures, especially when Brazilian-style dates like 15/04/2026 are interpreted inconsistently.
• Currency/number format inconsistencies, such as mixed separators in “R$ 10.000,00” entries.

Use this pre-check list before clicking calculate:

2) Arithmetic and reconciliation integrity (sum/total mismatches)

Even when each row “looks right,” totals can fail due to rounding, missing rows, or formatting that silently changes how values are interpreted.

The checker flags issues such as:

• Row totals that don’t sum to a reported “Total” cell.
• Rounding conflicts, where per-installment rounding causes the grand total to differ beyond an expected tolerance.
• Negative or zero payments when the schedule logic indicates those amounts shouldn’t exist.

A common and useful output is a named discrepancy list, for example:

• “Installment amounts sum to R$ X but Total cell is R$ Y”
• “Rounding delta exceeds tolerance (delta = R$ Z)”

3) Schedule logic problems (timing and ordering)

Structured settlement schedules can also break downstream even if arithmetic is correct. The checker looks for internal consistency patterns such as:

• Out-of-order payment dates (e.g., installments entered chronologically incorrectly).
• Overlapping periods when the spreadsheet model implies distinct windows.
• Start date/end date inconsistencies (for example, a first payment date earlier than a maintained “effective date” field).
• Missing or duplicated installments, such as two lines for the same installment number or an unexpected gap.

For Brazil-focused spreadsheets, timing is also where teams often mix concepts:

• competence date vs. payment date
• contractual start date vs. first installment date

The checker won’t replace your business judgment, but it can verify internal consistency within your sheet logic—so you catch “spreadsheet contradictions” before they become calculation or QA problems.

Note / gentle disclaimer: A spreadsheet that “looks correct” in Excel can still hide issues like dates stored as text or amounts stored with thousands separators. DocketMath’s checker is most valuable right before running calculations, because it helps catch parsing problems that can silently produce wrong arithmetic.

When to run it

Run the checker when errors are cheapest to fix—specifically at points in your workflow where spreadsheet edits or data imports are likely to break parsing or logic.

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

Before your first Structured Settlement run

Use the checker when you:

• import or paste installment data into the structured-settlement calculator,
• update dates or amounts,
• change assumptions such as installment count or payment cadence.

This is typically the highest ROI step, because it prevents running a full model on bad inputs.

After any spreadsheet edits that change structure

Examples include:

• adding/removing payment rows,
• renaming column headers,
• copying ranges from another workbook (which can change formats),
• changing display formats for dates or numbers.

Even “format-only” changes can cause values to become text (or change separators), and the checker is designed to detect those outcomes.

Before stakeholder sharing

If your spreadsheet is going to a review step—internal QA, committee review, counsel workflow, or a vendor handoff—run the checker first and keep the discrepancy list. That list becomes a practical record of what was validated before distribution.

A simple practical workflow:

• Validate with DocketMath checker
• Correct the spreadsheet
• Re-run until the discrepancy list is clean
• Then run the Structured Settlement calculations

Try the checker

Start the trial by using DocketMath’s tool directly: Structured Settlement calculator.

To make the trial effective, structure your spreadsheet so the checker can validate it cleanly.

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

Recommended inputs to prepare

Ensure these are present and consistent with your model:

Quick “run-and-fix” loop

1. Open Structured Settlement in DocketMath: /tools/structured-settlement
2. Select your spreadsheet input for the structured-settlement calculator.
3. Run the Spreadsheet Checker first.
4. Fix only the flagged issues (prioritize date parsing + numeric conversion).
5. Re-run the checker until it reports no discrepancies.
6. Run the structured settlement calculation once the spreadsheet is “clean.”

Pitfall to avoid: If you jump straight to calculation and only later notice totals are off, you may spend more time reconciling because parsing errors can propagate. The checker helps stop that propagation early.

Related reading

• Structured Settlement Calculator Guide for Alabama
• Structured Settlement Calculator Guide for Arizona
• Structured Settlement Calculator Guide for Colorado