Pre/Post-Offer Damages Split Guide for Texas

What this calculator does

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

DocketMath’s Pre/Post-Offer Damages calculator for Texas (US‑TX) helps you separate damages timeframes into two buckets:

• Pre-offer damages: damages that accrued before a defined “offer” date
• Post-offer damages: damages that accrued on/after the offer date

This split is often used in civil litigation to line up damages with the procedural timeline that affects exposure—especially when an “offer” creates different consequences for what happens before vs. after that milestone.

Texas-specific timing baseline (what the tool uses from the dataset)

Your jurisdiction dataset provides a default SOL period of:

• General SOL Period: 0.0833333333 years (≈ 1 month)

It also provides a statute reference:

• Texas Code of Criminal Procedure, Chapter 12
  Source: https://statutes.capitol.texas.gov/Docs/CR/htm/CR.12.htm

Important clarification: Chapter 12 of the Texas Code of Criminal Procedure is a criminal procedure source. The dataset note also says no claim-type-specific sub-rule was found. Because of that, this guide treats the provided “General SOL Period” as the single default timing window for this calculator workflow (i.e., a general/default lookback/cutoff concept for splitting/limiting the timeframe the tool counts).

Not legal advice / verify applicability: Don’t treat the dataset’s “general SOL period” as the definitive limitations period for every civil claim in Texas. Texas limitations rules vary by cause of action. Use this guide to organize a damages timeline and then confirm the governing limitation period for the specific claim in your matter.

Inputs the calculator typically needs

To produce a split, you normally provide (field names may vary slightly in the tool UI):

• Accrual date (start date for the damages clock)
• Offer date (the split point)
• End date (the cutoff where you stop counting damages—often judgment date, filing date, or another analysis end date)
• SOL period (defaulted from the dataset, unless you override it in the tool)

Optional accuracy helpers may include:

• Daily vs. monthly accrual behavior (if the tool models time-based accrual)
• Whether the offer date is included in post-offer (your tool convention may matter)

Output you’ll see

You can expect two output buckets:

If your damages calculation is rate-based (e.g., per-day accrual, interest accrual, or another ongoing component), the length of each bucket can materially change the total.

When to use it

Use DocketMath’s pre/post-offer split when you need to report damages in two time windows tied to an offer milestone and when the damages logic should treat the periods differently.

Common practical triggers (Texas-focused workflows)

You may be especially likely to use this calculator when:

• You must present damages by time window for briefing or case management
• A procedural event (the “offer”) creates an inflection point in your damages narrative
• Your damages model includes time-based components (daily accrual, continuing harm, interest-like accrual)
• Settlement communications or an offer milestone functions as the clean boundary between different treatment periods in your analysis

Checklist: good fit for this calculator

Confirm you have:

• An accrual/start date for the damages concept you’re measuring
• A clearly documented offer date (ideally a specific day, not just a month)
• An end date you want the tool to measure through
• A goal to break results into pre-offer vs post-offer buckets

Texas timing boundary reminder (based on the dataset)

The dataset default is ≈ 1 month (0.0833333333 years). Because no claim-type-specific rule was provided, this guide assumes the same default timing window controls the split workflow.

Pitfall to avoid: If you leave the SOL period at the dataset default (≈ 1 month) while your case actually uses a different limitations rule, the computed eligible time may shrink or shift—yielding a timeline that is internally consistent but may not match the correct limitations analysis for your claim.

Step-by-step example

This walkthrough focuses on the timeline logic and how you would feed inputs into DocketMath’s tool at:
/tools/pre-post-offer-damages.

Example scenario

You are analyzing damages with:

• Accrual date (start): January 1, 2023
• Offer date (split point): March 15, 2023
• Analysis end date: June 30, 2023
• Default SOL period from dataset: 0.0833333333 years (≈ 1 month)

Step 1: Create the raw time windows (before SOL cutoffs)

Before any limitation/cutoff logic, the raw split looks like:

• Pre-offer (raw): Jan 1, 2023 → Mar 15, 2023
• Post-offer (raw): Mar 15, 2023 → Jun 30, 2023

Step 2: Apply SOL cutoff behavior (as implemented by the tool)

Because the guide’s provided dataset supplies only a general/default SOL period (≈ 1 month) and does not specify additional mechanics, the exact eligibility window depends on how DocketMath applies the SOL cap within the tool.

In practice, tools that apply a “lookback/eligibility period” often do something like:

• Cap the start of eligible counting, so only the last ~1 month (relative to the tool’s reference point) is included, and/or
• Apply eligibility relative to a reference date used by the calculator

Key point: The calculator’s SOL cutoff step determines the exact eligible pre/post dates.

Step 3: Enter dates in DocketMath

Open the tool (using the primary CTA) and input:

• Accrual/start date: 01/01/2023
• Offer date: 03/15/2023
• End date: 06/30/2023
• SOL period: defaulted to ≈ 1 month (0.0833333333 years)

Step 4: Interpret results

You’ll receive eligible pre-offer and post-offer windows (not necessarily the full raw spans). With a very short SOL default (≈ 1 month), it’s possible that:

• Pre-offer becomes much smaller than the raw Jan 1 → Mar 15 span, and/or
• Post-offer captures most (or at least a large portion) of the remaining eligible period

Illustrative outcome structure (exact dates depend on tool logic)

Common scenarios

Below are scenario templates that typically map cleanly to a pre/post-offer damages split.

1) Offer date falls in the middle of an extended damages period

What happens: both pre and post buckets tend to be meaningfully sized (unless the SOL default is very restrictive relative to your timeline).

Typical inputs:

• Accrual: well before offer
• Offer: midstream
• End: after offer

Expected result: both time windows show up as non-trivial.

2) Offer date is close to accrual

What happens: pre-offer window is small.

Expected result: pre-offer is short; post-offer dominates.

3) End date is shortly after the offer

What happens: post-offer period may be the smaller bucket.

Typical end dates: filing date, hearing date, judgment date, or another analysis cutoff.

4) SOL window is extremely restrictive (≈ 1 month default in this dataset)

Given the dataset’s default ≈ 1 month (0.0833333333 years), older parts of the damages timeframe may be excluded.

What you’ll notice:

• one bucket can become nearly empty
• eligible time may cluster near whichever segment is closest to the tool’s internal eligibility reference point

This scenario is especially visible when:

• accrual date is far earlier than the offer, or
• the offer is outside the last ~month (as counted by the tool)

5) Day-count conventions matter

If your damages concept accrues by the day (common for interest-like or continuing daily-loss models), then:

• small date changes (e.g., offer on a different day) can shift bucket lengths, and
• output numbers may change accordingly

If the tool provides toggles (daily accrual, include/exclude offer date conventions), keep those consistent with your damages theory.

Tips for accuracy

• Use exact dates, not approximations. If you only know the offer month, use the best available evidence (e.g., the actual signed offer date) so the pre/post boundary is correct.
• Confirm your “accrual date” definition. Your accrual/start date should match the date your damages begin accruing under your damages theory (not just the first procedural event in the case).
• Be consistent about the offer boundary. Ensure you understand whether the tool treats the offer date as post-offer (your guide assumes on/after goes to post-offer).
• Set the SOL period deliberately. By default

Related reading

• Pre/Post-Offer Damages Split Guide for Alabama
• Pre/Post-Offer Damages Split Guide for Arizona
• Pre/Post-Offer Damages Split Guide for Colorado