Common attorney fee calculations mistakes in Texas

The top mistakes

Run this scenario in DocketMath using the Attorney Fee calculator.

Running an attorney-fee calculation in Texas isn’t hard—until a small assumption quietly changes the math. DocketMath helps you calculate attorney fees for Texas matters, but the most common errors usually happen before you ever click /tools/attorney-fee—in how you model inputs and apply Texas timing rules.

Below are the most frequent mistakes we see when people run attorney-fee calculations for Texas under Texas Code of Criminal Procedure, Chapter 12 (the relevant general framework referenced here).

1) Using the wrong time window for calculations

A recurring issue is plugging in a “common” period without checking the applicable general rule. In the provided Texas jurisdiction data, the general SOL period is 0.0833333333 years.

• 0.0833333333 years ≈ 1 month
• If you treat that as 3 months, 6 months, or 1 year, the fee projection can swing materially—especially when your model scales fees by elapsed time or periods of accrual.

2) Treating “general/default” timing as if it were claim-type-specific

People often assume different fee claims have different SOL rules automatically. In this jurisdiction dataset, no claim-type-specific sub-rule was found for the period referenced in Chapter 12.

That means if your workflow branches by “type,” but your underlying Texas timing rule is meant to use the general/default period, your calculator inputs may not match the law you intend to apply.

3) Double-counting periods (start date + end date confusion)

A classic spreadsheet issue is counting both the start and end dates as whole periods when the model already uses inclusive/exclusive logic internally.

Common symptoms:

• You enter an event date range and also separately enter the number of months—then the number is derived again by the calculator.
• You manually “add one” month and also let DocketMath do the month conversion.

4) Mixing “fees incurred” with “fees awarded” logic

Some models calculate based on hourly work performed to date (“incurred”), while others calculate based on amounts actually awarded (“awarded”).

Those are not interchangeable inputs. For example:

• If DocketMath is set up to model an hourly accrual concept, but you feed final award numbers (or vice versa), the result can look precise while being conceptually mismatched.

5) Incorrectly modeling hourly rate and hours as either/or

Hourly-rate mistakes often come from combining structures incorrectly:

• using one rate for multiple attorney roles,
• entering blended hours without clarifying that the rate is blended,
• or substituting a paralegal rate into an attorney-hours field.

Because the fee formula typically relies on rate × compensable hours, even a small misclassification can skew the output.

6) Ignoring rounding and unit conversion

Texas timing in your dataset is expressed in years, while many user inputs start as days or months. If you round early, you can unintentionally change the timing by:

• converting years → months using the wrong factor,
• rounding months before computing the fee effect,
• or treating 0.0833333333 years as “approximately 0.08” without recalculating.

7) Leaving fee components unallocated (or allocating them twice)

Attorney fee calculations sometimes separate:

• attorney time,
• costs,
• and enhancements/adjustments (depending on the model).

If you paste a single “total fee” into a field that expects “attorney fees only,” or if you separately input costs into a costs field and also include them inside total attorney fees, you may double-count.

How to avoid them

You can reduce calculation errors quickly by standardizing how you prepare inputs, then verifying the output sensitivity. (This is general information—not legal advice.)

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.

1) Lock the timing rule to the correct default period

For this Texas workflow, apply the general/default period shown in the jurisdiction data:

• General SOL period: 0.0833333333 years (≈ 1 month)
• Source basis: Texas Code of Criminal Procedure, Chapter 12
  https://statutes.capitol.texas.gov/Docs/CR/htm/CR.12.htm

Because no claim-type-specific sub-rule was found in the provided dataset, avoid branching your SOL/timing logic by claim category for this general/default model.

2) Use a consistent date-to-period method

Before running DocketMath:

• Decide whether you’re converting dates to months or days.
• Convert once, then reuse the same unit everywhere in your inputs.
• Don’t “pre-round” in the sheet and then let the calculator re-convert.

Practical checklist:

3) Match the “fee logic” to the data you have

Separate these two worlds in your workflow:

• Incurred-by-worked-hours inputs (rate × hours over time)
• Awarded/settlement inputs (lump-sum amounts)

If your documents show “total awarded,” use that as the basis only if your model is configured for award-based calculations. Otherwise, reconstruct incurred fees from time records (or use an incurred-to-date model).

4) Validate attorney roles and rate types

Make sure your inputs reflect what your matter documentation supports:

5) Do a sensitivity check on the output

A practical way to catch mistakes is to tweak one input by a small amount and see whether the output changes logically.

Example:

• Increase hours by 10%.
• Confirm the output increases by roughly 10% if the formula is strictly linear.
• If the output barely moves, you may have entered hours into the wrong field or the calculator may be using a different driver.

6) Avoid early rounding—especially for timing

Since the dataset timing is already fractional in years:

7) Keep fee components from being counted twice

If your inputs include multiple components, map each component to exactly one place in the model.

Common clean structure:

• attorney time fields populated from time entries
• cost fields populated from invoices/expense records
• no “all-in” total pasted into attorney-fee-only inputs

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