Spreadsheet checks before running Pre Post Offer Damages Split in Brazil

What the checker catches

Run this scenario in DocketMath using the Pre Post Offer Damages Split calculator.

Before you run DocketMath’s Pre Post Offer Damages Split calculator for Brazil (BR), a handful of spreadsheet issues can quietly distort the split—especially when your workbook relies on an offer date, a damages start date, and time-based accrual assumptions.

Use DocketMath as a first-pass analysis tool, but treat this spreadsheet checker as a data quality gate. Its job is to verify that your workbook is internally consistent so the calculator doesn’t produce a confident-looking number from flawed inputs.

Typical problems the spreadsheet checker catches in Brazil-focused models include:

• Date alignment errors

  • Offer date earlier than the damages start date.
  • The pre-offer period accidentally includes (or excludes) the offer date.
  • Mixed date formats (for example, 15/02/2024 stored as text in one sheet/tab and as a real date in another).

• Accrual boundary mistakes

  • Gap days created by inconsistent calendar references (e.g., settlement date vs. offer date references swapped across tabs).
  • Negative day counts in the pre or post segment caused by incorrect ordering.

• Wrong units for the damages basis

  • Entering currency amounts into a field that expects daily/periodic amounts (or vice versa).
  • Accidentally entering annual figures into a field meant for totals.

• Row/column mapping issues

  • A “rate” cell linked to the wrong row—common when formulas are copied across line items.
  • Shared ranges that shift when you insert/delete rows, changing what each formula actually points to.

• Silent blanks and zero-fill behavior

  • Empty cells interpreted as zero by downstream formulas.
  • Some lines having values while others are blank, causing mismatched totals.

• Inconsistent scenario or party identifiers

  • Multiple scenarios (e.g., Offer A vs. Offer B) where the date comes from one scenario but amounts come from another.
  • Party columns swapped, so the offer-based split is applied to the wrong entity.

Here’s a quick checklist of the most frequent “Brazil split” issues you can validate before calculation:

Warning (practical): Spreadsheet date cells that look correct to the human eye can still be stored as text. When a date is text, Excel/Sheets may not compute day differences reliably—leading to an incorrect pre/post split without an obvious error message.

When to run it

Run the spreadsheet checker right before you execute the DocketMath Pre Post Offer Damages Split calculator, and again after any edit that could change boundaries or units.

A practical schedule that avoids rework:

• Before your first run

  • Confirm the workbook has:

    • one offer date reference for the scenario
    • one damages start date reference for the scenario
    • a consistent unit model (totals vs daily/periodic inputs)

• After any change to dates

  • If you update the offer date, settlement date, or damages start date—even by 1 day—re-run the checker.

• After any structural edits

  • Adding/removing rows or columns.
  • Copy/paste operations that may break references.

• After scenario duplication

  • If you duplicate a sheet to create “Offer A / Offer B,” validate that:

    • the duplicated sheet’s offer date really changed
    • the damages inputs changed with it (not only the date)

• Before exporting results

  • If you generate a report table/dashboard, run the checker first to ensure the exported totals align with the validated inputs.

Simple “trigger list” for re-running the checker:

Try the checker

If you want the fastest workflow, use DocketMath’s tool entry point and keep the checker adjacent to your calculator run. Start here:

• Primary CTA: /tools/pre-post-offer-damages-split

Next, run the calculator only after your spreadsheet passes the checker’s consistency checks. The input-to-output relationship below is a good way to sanity-check what the model is doing (and to catch unexpected flips):

Inputs to confirm (Brazil BR workflow)

Make sure your sheet clearly defines (and consistently references):

• Offer date (the boundary date for the split)
• Damages start date (beginning of the accrual window)
• Damages amount basis (whether your model uses totals vs daily/periodic amounts)
• Any rate/period assumptions your model uses (daily/annual/periodic)

Outputs you should expect to move when inputs change

When you adjust each input, the split should change in predictable ways:

• If you move the offer date later:

  • Pre-offer portion should increase (more days before the boundary)
  • Post-offer portion should decrease

• If you move the damages start date later:

  • Day counts for both pre and post may shrink
  • Totals should reflect the shortened accrual horizon

• If you fix date format issues:

  • Day-count calculations often “snap” back into a plausible range
  • Totals frequently shift noticeably after invalid dates are corrected/flagged

Suggested “minimum validation” before trusting results

Once those conditions are satisfied, run Pre Post Offer Damages Split with greater confidence that changes in results reflect your assumptions—not accidental spreadsheet mechanics.

To get hands-on, open /tools/pre-post-offer-damages-split and follow the calculator flow after your checker run.

Related reading

• Why Pre Post Offer Damages Split results differ in Alabama — Troubleshooting when results differ
• Why Pre Post Offer Damages Split results differ in Alaska — Troubleshooting when results differ
• Why Pre Post Offer Damages Split results differ in Arizona — Troubleshooting when results differ