Why Pre Post Offer Damages Split results differ in Brazil

The top 5 reasons results differ

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

If you run DocketMath with the pre-post-offer damages split calculator for Brazil (BR) and you see materially different outputs across runs, it usually comes down to how your inputs map to Brazil-relevant assumptions—especially around what counts as “pre-offer” vs “post-offer” and the timing convention the calculator applies.

Here are the top 5 reasons results differ most often in Brazil:

1. Offer date vs. “effective” date mismatch
   The split hinges on a date boundary. If your “offer date” differs across runs—e.g., one run uses the offer sent date while another uses the offer received/acknowledged (or filed/posted/publication) date—the boundary shifts.
   Result: the pre-offer accrual window and post-offer window change, often producing noticeable swings even when dates appear “close.”

2. Day-count convention (calendar days vs. business days)
   Day ranges and accrual periods can be sensitive to whether you count calendar days or business days (and whether weekends/holidays are excluded).
   Result: pre- and post-offer totals diverge because the duration assigned to each segment is not the same.

3. Interest/monetary adjustments applied to the wrong segment
   A common cause is applying adjustment rules across the whole timeline and then splitting, instead of applying them segment-by-segment (pre-offer vs post-offer).
   Result: you may unintentionally shift more value into the post-offer portion (or vice versa), giving results that look “off” despite identical dates.

4. Rounding and compounding/aggregation frequency
   Small differences become visible when intermediate values are rounded more than once, or when you change how frequently compounding/aggregation is performed.
   Result: two runs that “should” match can still differ—especially if the post-offer segment is long and accumulates more periods.

5. Inconsistent currency/amount basis
   If one run uses a nominal principal and another uses an adjusted base (or different index baseline), the split can look inconsistent even if the date boundary is identical.
   Result: differences reflect a changed monetary foundation, not just a timing effect.

Pitfall to check: If two runs use the same dates in the interface but one interprets “offer date” as sent while the other interprets it as received, you are not comparing the same model. The accrual boundary has moved, so the split won’t “cancel out.”

For the exact inputs that affect these boundaries, start here: /tools/pre-post-offer-damages-split.

How to isolate the variable

Use a controlled approach: keep everything constant except one assumption at a time. The goal is to identify which specific mapping (date boundary, day-count, adjustments scope, rounding, or amount basis) is driving the divergence.

1. Lock dates first
   Keep constant across runs:

   • Claim event start date (or your claim beginning)
   • Offer date (your chosen boundary definition)
   • Valuation/through date
     Then re-run DocketMath and verify your split aligns with what you expect for the pre/post day counts.

2. Freeze the monetary basis
   Hold constant:

   • the damages principal you enter, and
   • any adjustment basis you rely on (so the numeric foundation is the same conceptual year/value).
     If the calculator allows multiple money/adjustment modes, ensure you’re not switching modes between runs.

3. Toggle only one “timing” assumption
   Create a pair of runs that differ only by day-count convention:

   • Run A: calendar-day split
   • Run B: business-day split
     Compare:
   • total pre-offer damages
   • total post-offer damages
   • grand total

4. Confirm segment-scoped application of adjustments
   If DocketMath includes inputs for interest/monetary adjustments, verify they are applied to:

   • pre-offer segment only, and
   • post-offer segment only,
     rather than “whole period, then split.”

5. Use a small comparison table
   Capture results from at least 3 controlled runs:

   Run	Offer date used	Day count	Pre-offer total	Post-offer total	Total
   A	Date 1	Calendar
   B	Date 1	Business
   C	Date 2	Calendar

If only one column changes dramatically when you vary a single input category, you’ve found the driver.

Gentle note: this is diagnostic guidance, not legal advice. Damage timing can be legally nuanced, so align your assumptions with the relevant underlying record and your internal modeling standards.

Next steps

Once you isolate the driver, apply targeted fixes:

• Normalize your “offer boundary” definition
  Pick one consistent interpretation across runs, such as:

  • offer sent date,
  • offer filed/posted date, or
  • offer received/acknowledged date.
    Then use it consistently for every DocketMath run.

• Standardize day-count rules
  Choose calendar vs business days intentionally. If your workflow involves both, keep them in separate scenarios instead of mixing them between runs.

• Ensure adjustments are scoped correctly
  If totals are unexpectedly high/low, re-check whether your configuration effectively applies the same adjustment more than once (e.g., once over the whole timeline and again within a segment).

• Document run settings
  Maintain a one-page log with:

  • dates used,
  • damages principal basis,
  • day-count convention,
  • rounding/aggregation choices (where controllable in DocketMath).

If you want to sanity-check behavior, revisit /tools/pre-post-offer-damages-split and mirror your “Run A” configuration before changing a single variable.

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