How to run attorney fee calculations in DocketMath for Texas

7 min read

Published April 15, 2026 • By DocketMath Team

Step-by-step

Run this scenario in DocketMath using the Attorney Fee calculator.

This guide walks you through running attorney fee calculations in DocketMath for Texas (US-TX) using the Attorney Fee calculator. It’s designed to be practical: you’ll set the right inputs, understand what the outputs mean, and see how the calculation changes when key dates or fee components change.

Note: This walkthrough explains how to run the calculator. It does not provide legal advice or case strategy. Attorney fee rules can depend on the underlying claim type and procedural posture.

1) Open the correct tool in DocketMath

Start at the primary call to action:

  • /tools/attorney-fee

If you’re building a workflow, treat this as your “fee math workspace” for Texas inputs.

2) Confirm you’re using the Texas jurisdiction (US-TX)

Within the tool, set the jurisdiction to Texas (US-TX) so DocketMath applies Texas-specific logic and date handling.

3) Enter the date inputs the calculator requests

Attorney fee calculations usually hinge on timing and the applicable limitations framework. In Texas, the relevant criminal procedural framework is found in:

DocketMath also uses a general/default limitations period for the tool’s timing logic. Your jurisdiction data specifies:

  • General SOL Period: 0.0833333333 years

That number equals 1 month, because:

  • 0.0833333333 × 12 ≈ 0.9999999996 months

Important (per your brief): No claim-type-specific sub-rule was found. That means DocketMath should apply a general/default period rather than a specialized rule for a particular claim type—unless the tool itself provides a claim-type-specific selection.

4) Add the fee components the calculator needs

Attorney fee calculations typically use inputs like:

  • Requested attorney fees (or claimed fee amount)
  • Hours and rate (if the calculator derives totals from timekeeping)
  • Adjustment fields (if the calculator supports them)
  • Payment or offset amounts (if applicable in the calculator design)

In DocketMath, enter only the values you have. If the tool provides multiple ways to represent fees (for example, both “hours × rate” and “total”), double-check which field the calculator treats as controlling.

A quick sanity check:

  • if you provide a “total” and also provide “hours × rate,” do the numbers match?
  • if they don’t match, the output may reflect one field more than the other (depending on tool design).

5) Run the calculation and review each output bucket

After submitting, DocketMath should return a breakdown of the computed results. Use a checklist to verify you’re reading the right lines:

If your outputs include intermediate values (for example, days/months derived from SOL logic), capture those for your recordkeeping so you can troubleshoot later without re-running from scratch.

6) Change one input at a time to see how outputs move

To get confidence in your run, test sensitivity. Small changes in date inputs can change whether the timing logic flags a limitations window.

Two helpful “one-variable” tests:

  1. Move the key date by ~30 days
    • Expect the timing/eligibility portion to change, since 1 month ≈ 0.0833333333 years.
  2. Adjust attorney hours or rate
    • Expect the fee subtotal to change proportionally, unless the tool applies caps or fixed adjustments.

Keep a mini log for each run:

  • which input you changed
  • which output section changed
  • the before/after values

This makes it easier to explain your workflow and reduces the chance of copying the wrong output line.

Common pitfalls

DocketMath can only compute what you enter and the Texas logic it is configured to apply. The most frequent missteps are about timing assumptions, choosing which fee inputs to use, and interpreting “general/default” behavior.

  • using gross recovery when net applies
  • mixing recoverable and non-recoverable time
  • skipping statutory prerequisites
  • forgetting fee caps or schedules

Misinterpreting the limitation period as claim-type-specific

Your jurisdiction data explicitly states:

  • No claim-type-specific sub-rule was found
  • therefore the default/general period is used

So the tool’s timing portion should be anchored to the general/default limitations period and the broader framework referenced in:

Warning: If your situation truly requires claim-type-specific treatment, check whether DocketMath offers a way to select that. Otherwise, the timing output may not match the limitation that applies to your specific scenario.

Entering inconsistent date formats or the wrong date field

A single swapped date can dramatically change the computed interval.

Double-check:

  • which date represents the start of the limitations measurement
  • which date represents the filing/action date (or whatever endpoint the tool requests)
  • the date format the tool expects (and whether it needs full dates vs. partial dates)

If the tool shows a derived interval (e.g., days or months), use that as an immediate verification step.

Double-counting fee amounts

If the calculator supports multiple fee entry methods (for example, both “hours × rate” and “total”), you can accidentally enter the same economic amount twice.

Practical check:

  • temporarily set hours to 0 (or set rate to 0) and re-run
  • confirm the output reflects only the remaining method

If the calculator allows selecting one method, prefer selecting a single consistent approach.

Assuming the last number is always the “final” number

When outputs are broken into parts (base → reductions/caps → final), don’t just copy the last line without verifying the logic.

Use the checklist approach again:

  • verify whether reductions/caps are included only when certain conditions are triggered
  • confirm that the “final” equals the base ± adjustments as the tool indicates

Using Texas timing logic without verifying your broader governing framework

Timing rules in Texas can come from different procedural contexts. This guide focuses on the framework associated with:

If your matter is governed by a different framework, the calculator timing segment may not match your controlling rule.

Try it

If you want a quick start, open DocketMath → Attorney Fee and run a baseline scenario:

  1. Set jurisdiction to Texas (US-TX).
  2. Use a test key date pair such that the interval is close to 1 month (because 0.0833333333 years1 month).
  3. Enter a simple fee pattern:
    • either a total fee number, or
    • hours and rate that produce a clean total (for example, 10 hours × $200/hour = $2,000).

Then run three iterations:

  • Run A (baseline): initial date pair + base fee inputs
  • Run B (timing stress): move the endpoint by +15 days
  • Run C (fee sensitivity): change rate by +10% (keep dates constant)

Use this mini result tracker:

RunDate interval targetFee inputs changeWhat you should expect
A~1 monthnonebaseline outputs, including default timing logic
B~1 month + 15 daysnonetiming portion may shift; fee portion should stay the same
C~same as A+10% rate (or equivalent)fee subtotal/final should rise; timing should stay unchanged

When you’re satisfied the outputs react predictably, you’ll have a repeatable workflow for your real attorney fee calculations.

Related reading