Common Attorney Fee mistakes in Brazil

The top mistakes

Run this scenario in DocketMath using the Attorney Fee calculator.

Attorney-fee billing in Brazil is a common source of friction—not because fees are “mysterious,” but because practitioners often model them without matching how Brazilian procedure and contract mechanics actually work. Using DocketMath (the attorney-fee calculator), the goal is to catch avoidable errors early by aligning your inputs with the rules that can affect Brazilian fee outcomes.

Below are frequent mistakes we see when preparing attorney-fee projections (and then reconciling them against case events). Use these as a checklist before you lock your numbers.

1) Using the wrong fee base (amount vs. result)

A common error is calculating fees from an incorrect base—e.g., using the gross claim value when the intended base should be the amount effectively settled/paid (or another quantified procedural value depending on posture).

What goes wrong in DocketMath

• You enter a base amount that doesn’t correspond to the phase you’re forecasting.
• The output looks precise—but it’s precise for the wrong “driving number.”

Quick example (conceptual): If your model assumes fees are calculated on the full claim, but the matter actually resolves on a reduced settlement figure, the fee outcome can be materially overstated.

2) Confusing contractual fee design with procedural/judgment-linked fees

In Brazil, fee mechanics can differ between:

• Contractual fees (agreed between client and lawyer), and
• Procedural/judgment-linked attorney fees (often tied to what the decision orders and governed by the procedural framework).

A typical operational error: treating a contingent contract fee structure as if it will be reimbursed/ordered in the same way as procedural attorney fees—or assuming the losing party reimburses the exact private structure.

Practical risk: You may overestimate recoverable amounts by modeling contractual contingencies as though they are automatically reproduced in the proceeding’s ordered allocations.

3) Entering outdated or misapplied fee percentages

Even when the “fee type” is correct, percentages can change based on factors such as:

• stage (e.g., early resolution vs. final disposition),
• whether there is a settlement,
• how the judgment quantifies the base, and
• the fee regime you’re intending to simulate.

Common workflow failure: Using one percentage across every scenario (trial, partial settlement, final settlement) without updating the fee base and the governing assumptions per scenario.

4) Ignoring the relationship between stage and the attorney-fee outcome

Brazilian procedural timeline affects fee expectations. A frequent pattern is running a single “final” calculation too early (or using a late-stage model for earlier events), then having to correct it after key milestones.

Practical symptom: The first invoice/projection is produced after critical procedural moments have already passed—or assumptions need updating because the event changed the quantified base.

5) Mis-matching currency/date assumptions in cashflow planning

Attorney-fee modeling often sits next to payment timing and settlement mechanics. If DocketMath assumes one valuation basis but your cashflow model uses a different valuation date (e.g., “today’s” vs. “signed at settlement” figures), your expected net may not match actual payment timing.

DocketMath error pattern: Treating a settlement value as if it was current when it was agreed months earlier—or vice-versa—and then carrying that mismatch into cashflow forecasts.

6) Not setting scenario “branches” for partial outcomes

Many matters resolve partially: partial settlement, partial withdrawal, partial victory, or multiple quantified components. If you run a single blended model, you can hide how fees scale with the portion actually awarded/paid.

Result: You miss the range of outcomes and only detect the problem at reconciliation time.

How to avoid them

You can reduce these mistakes by treating DocketMath as a scenario model (not a one-time calculator) and by making your inputs event-aware.

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

Step 1: Define what you are modeling (contractual vs. procedural)

Before you enter anything into DocketMath, write down which question you’re answering:

• “What do we owe under our fee agreement?”
• “What might we recover as ordered/allocated in the proceeding?”
• “What is the expected range if the settlement happens at stage X?”

Then match the DocketMath inputs to that purpose. If you’re not sure which mechanics apply, run two separate scenarios (contract model vs. procedural recovery model) and compare them explicitly.

Gentle reminder: This is modeling guidance, not legal advice. Fee outcomes can depend on the specifics of the agreement, procedural posture, and the way amounts are quantified in the case.

Step 2: Use an event-aligned base amount

In DocketMath’s attorney-fee workflow, your base amount should correspond to the event you’re modeling:

• final awarded/quantified amount (if judgment-based),
• settlement amount (if settlement-based),
• or another quantified reference used by the fee agreement.

Checklist

Step 3: Update the fee percentage per stage (don’t reuse one number)

Run separate scenarios for:

• early vs. late settlement,
• partial vs. full resolution,
• and different quantified outcomes.

This is where spreadsheets commonly fail. With DocketMath, treat stage as a variable, not a footnote.

Even if your contract fee is fixed, Brazilian procedural outcomes can still affect what you recover from the other side. Keep “what we earn” vs. “what we collect/recover” as separate calculations when possible.

Step 4: Sanity-check with bounds (low / expected / high)

Create three DocketMath runs:

• Low case: conservative base amount or earlier-stage resolution
• Expected case: your best estimate
• High case: later-stage resolution or higher quantified base

Then compare outputs. If the “high case” is only marginally higher than the “low case,” re-check whether your base amount actually changes between scenarios.

Step 5: Make timing and currency assumptions explicit

If your DocketMath output feeds a cashflow schedule, ensure consistency about:

• the valuation date of the base amount,
• whether the model reflects “today” values or historical settlement/judgment figures.

If your workflow separates fee calculation from cashflow planning, keep the dates aligned when you transfer numbers.

Step 6: Document your scenario logic for faster reconciliation

When you save a DocketMath run, attach a short internal note such as:

• “Base = settlement amount in the signed term”
• “Stage = post-sentença simulation”
• “Percentage = agreement schedule item X”

This prevents the common problem where assumptions change but the reasoning doesn’t survive into reconciliation.

Related reading

• Worked example: attorney fee calculations in Vermont — Worked example with real statute citations
• Attorney Fees Guide for Alaska
• Attorney Fees Guide for American Samoa