How to interpret Pre Post Offer Damages Split results in Brazil

What each output means

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

DocketMath’s Pre/Post Offer Damages Split for Brazil (BR) is designed to break damages into two conceptual buckets based on one key event: the timing of the offer relative to the period when damages are modeled as accruing.

Because Brazilian-related damages modeling often depends on time-sensitive assumptions (for example, correction/interest timing and valuation dates), the tool’s goal is to help you organize the timeline and explain how the output shifts when the offer boundary moves. It’s a calculation framework, not a promise about how any particular court will classify every damages component.

Typical outputs you’ll see in DocketMath

Exact labels can vary slightly depending on your selected inputs, but you should be able to map your results to these concepts:

Note (important): The split reflects the assumptions and timeline boundaries you entered. If your inputs define “accrual” differently from your case narrative, the split can look counterintuitive—even if the arithmetic is working as designed.

How the offer timing drives the split

DocketMath treats the offer date as a boundary between two computation windows:

• Pre-offer window: from your accrual start up to just before the offer milestone (per the model’s date logic)
• Post-offer window: from the offer date onward to your accrual end / valuation date (per the model’s logic)

That means:

• If the offer date is earlier, a larger share of the timeline shifts into the post-offer bucket.
• If the offer date is later, the pre-offer bucket typically grows.

To interpret your results correctly, confirm that your accrual start/end dates and your intended “offer boundary” match the way the model defines those periods.

What changes the result most

A Pre/Post split result will move most when you change inputs that alter (1) how much time sits before vs. after the offer date, or (2) how damages grow over time under the model’s settings.

These inputs have the biggest impact on the final number. Adjust them one at a time if you need a sensitivity check.

• date range
• rate changes
• assumption changes

1) Offer date (the single biggest lever)

Changing the offer date shifts the boundary between pre and post. This is usually the fastest way to see the split ratio react.

Quick intuition:

• Move the offer date forward → more of the timeline is “pre” → pre-offer increases
• Move the offer date backward → more of the timeline is “post” → post-offer increases

Practical test:

1. Run a baseline scenario.
2. Rerun with the offer date moved by ±30 days.
3. Compare how the split ratio/percentages change—not just Pre and Post individually.

2) Accrual window dates (start and end)

Your accrual start date and accrual end/valuation date determine the total eligible timeline in the model.

Use this checklist when the output doesn’t “feel right”:

• ☐ Are you using consistent definitions across runs (for example, the same accrual start event)?
• ☐ Does the end date reflect the valuation date your analysis is aiming for?
• ☐ Are you encoding the intended correction/interest timing behavior into the model inputs correctly?

If these dates are inconsistent with your case timeline, the split may look off even though the math is consistent.

3) Damages base amount and scaling assumptions

If your DocketMath run uses a principal/base amount and scaling parameters (rate assumptions, per-period accrual logic, etc.), changes here can shift both:

• the total damages, and
• potentially the relative weighting between pre and post (depending on how time interacts with your model inputs).

How to diagnose with outputs:

• If Total damages changes a lot, you likely changed a base or rate (or a similar scaling assumption).
• If Total stays similar but pre/post percentages move, you likely changed the offer boundary or the window dates.

4) Rounding and compounding frequency

Brazil-related time computations can be sensitive to model settings like step frequency and rounding.

If your DocketMath settings include options such as:

• daily vs. monthly time steps,
• compounding vs. non-compounding,
• rounding policy,

avoid comparing two scenarios that use different settings as if they were directly equivalent analyses.

5) Multi-component damages (if applicable in your model)

If you’re modeling multiple categories/components separately (for example, different damage streams), each component may accrue differently over time.

A common pattern:

• One category may be more heavily time-weighted before the offer.
• Another category may accrue more steadily, producing a less dramatic pre/post swing.

If you’re reviewing multiple components, track whether the dominant driver of your overall split is actually the offer boundary effect or a component-specific accrual pattern.

Next steps

Use DocketMath to convert the split output into a timeline-driven, calculation-focused explanation. This helps you stay organized and ready to discuss assumptions with stakeholders—without treating the tool output as legal advice.

After you run the Pre Post Offer Damages Split calculation, capture the inputs and output in the matter record. You can start directly in DocketMath: Open the calculator.

Step-by-step workflow

1. Confirm the timeline inputs

   • Offer date
   • Accrual start date
   • Accrual end / valuation date
     Also note where each date came from in your record (even brief internal notes).

2. Run and record the baseline

   • Capture: Pre, Post, Total, and any split ratio/percentages.

3. Stress-test the boundary

   • Rerun with offer date shifted ±15 days and ±30 days.
   • Document how sensitive the split ratio is to those changes.

4. Check internal consistency

   • Confirm Pre + Post ≈ Total (allow for rounding).
   • If it doesn’t reconcile, revisit input definitions—especially dates and any scaling/time-step settings.

5. **Draft a non-legal interpretation (calculation narrative) Use language like:

   • “The model allocates damages into two windows separated by the offer date: [offer date].”
   • “Pre-offer represents the modeled accrual from [start date] to [offer date boundary].”
   • “Post-offer represents the modeled accrual from [offer date boundary] to [end/valuation date].”
   • “The split changes mainly when the offer date moves.”

6. Tie back to case strategy carefully If the model shows an extreme split (e.g., 80/20), identify which inputs are driving it (usually offer date and window dates). Then sanity-check whether those inputs match your factual timeline.

Use the tool entry point

Start with DocketMath here:

• /tools/pre-post-offer-damages-split

If you’re comparing other timeline/boundary methods within DocketMath, you can explore additional calculators via:

• /tools/

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