Why Attorney Fee results differ in Brazil
4 min read
Published April 15, 2026 • By DocketMath Team
The top 5 reasons results differ
If you run DocketMath’s Attorney Fee calculator for Brazil and see materially different results between two cases—or between two “attempts” on the same matter—that usually comes down to a handful of jurisdiction-aware inputs. Below are the most common causes, in the order that typically produces the biggest swings.
| # | Reason | What changes in DocketMath | Why it moves the number |
|---|---|---|---|
| 1 | Base amount selection | The “starting figure” the fee is calculated from (e.g., claim value vs. amount awarded) | Brazil fee outcomes often track the monetized outcome more tightly than many other systems, so changing the base can have a large effect |
| 2 | Fee trigger / phase | Whether the model applies fee mechanics based on procedural stage (e.g., early vs. later) | Different stages can map to different percentage schedules or fee rules |
| 3 | Contingency / agreement structure | Inputs for contractual fee arrangement vs. court-shaped structure | Contract terms can yield different effective rates than court-shaped outcomes, even if the underlying claim/award is the same |
| 4 | Discounts, caps, or reductions | Whether limitations/reductions are applied to the computed base | A cap or reduction toggle can cut totals sharply, sometimes dwarfing other differences |
| 5 | Allocation rules (who pays / who bears costs) | Assumptions about fee allocation by outcome | Attorney fees are often recovered from the losing side, but the net modeled figure depends on who pays and what portions are recoverable |
Pitfall: Even when the headline outcome looks identical (for example, “R$ 100,000 awarded”), attorney-fee results can still diverge if your DocketMath inputs reference different fee bases (e.g., “claimed amount” vs. “award amount”) or if the runs use different trigger logic.
How to isolate the variable
To diagnose differences quickly, treat your DocketMath run like a controlled experiment: change one input at a time, and compare the delta in the output. This reduces guesswork and makes the cause obvious.
Step-by-step isolation workflow
Record the two outputs (Case A vs. Case B)
- Compute: Delta = Attorney fees(A) − Attorney fees(B)
Freeze everything except one input
Keep constant:- currency
- base amount source
- fee trigger/phase
- agreement type/structure
- caps/reductions settings
- allocation assumptions (who pays / netting logic)
Change only one field, then re-run DocketMath
Examples of “one-at-a-time” tests:- switch base amount selection (claim vs award)
- switch the procedural stage/phase mapping
- toggle caps/reductions (ON vs OFF)
- switch agreement structure (contractual vs court-shaped inputs)
Interpret the shift
- If changing the base amount moves the result dramatically, that’s your likely root cause.
- If only the stage/trigger changes between runs, focus on how DocketMath maps that stage to fee mechanics.
- If results sometimes “snap” downward, check caps/reductions toggles.
- If your “net” expectation includes recovery from the other side, verify your allocation assumptions match the scenario you’re modeling.
Practical diagnostics by symptom
- Consistently higher by a fixed percentage
Likely a mismatch in base amount selection or agreement/structure inputs. - Close most of the time, but occasionally drops sharply
Likely caps/reductions or a different trigger/phase causing a different fee schedule. - Large swings even when claim value appears the same
Commonly: one run uses award amount while the other uses claimed amount, or the stage/trigger differs.
Gentle reminder: this is a modeling exercise. DocketMath reflects the inputs you provide; it’s not guaranteed to match every Brazilian case-file outcome without aligning the underlying assumptions.
Next steps
Once you identify the input that’s causing the mismatch, you can make future runs reproducible—and easier to explain.
Standardize your Brazil case template
- Pick one convention for the fee base:
- “award amount” (granted) or
- “claim amount” (sought)
- Use that convention consistently across scenarios.
Create a “scenario label” for phase/trigger Track the stage outside DocketMath so you don’t rely on memory. Example labels:
- pre-judgment
- judgment / post-judgment
- settlement-based
Lock in fee structure inputs If you model contractual contingency, keep agreement terms consistent (even if outcomes differ) so you don’t accidentally change more than the scenario variables you care about.
Document exact toggles used Write down which caps/reductions options were enabled per run, and which base/trigger settings were selected.
Sanity-check with two quick comparisons
- Run with caps/reductions ON
- Run with caps/reductions OFF
- If the gap is huge, you know the interpretation hinges on those limitations.
Primary CTA: Run it directly: DocketMath Attorney Fee tool