Pre/Post-Offer Damages Split Guide for Michigan
7 min read
Published April 8, 2026 • By DocketMath Team
What this calculator does
Run this scenario in DocketMath using the Pre Post Offer Damages calculator.
DocketMath’s Pre/Post-Offer Damages Split tool (for Michigan, US-MI) helps you separate damages into two time periods based on the date an offer was made:
- Pre-offer damages: damages that accrued before the offer date
- Post-offer damages: damages that accrued on/after the offer date
This split is often necessary when a case’s damages can be affected by procedural timing—including scenarios where Michigan law limits what a party can recover after an offer (for example, via Michigan’s offer-related framework reflected in MCL § 767.24(1)).
Note: This guide provides a practical damages-splitting workflow. It’s not legal advice, and it won’t determine outcomes for your specific case. Use it to organize numbers and understand how the split may be applied.
The Michigan timing baseline (general/default SOL)
For Michigan, this guide uses the general/default statute of limitations (SOL) period:
- 6 years, under MCL § 767.24(1)
- Michigan’s general SOL period is a baseline; this write-up does not identify any claim-type-specific SOL sub-rules because none was found for this guide.
- Source for jurisdiction data: Michigan.gov (statute reference: MCL § 767.24(1)).
How this helps you practically: you can use the 6-year baseline to set a lookback window for which portions of damages to include in your accounting. The tool itself is focused on the offer split—but your inputs should usually reflect an eligible time window consistent with MCL § 767.24(1).
If a portion of damages falls outside the 6-year lookback, it may be treated as potentially time-barred depending on the specific facts and legal theories in your case. This guide stays focused on the workflow rather than legal conclusions.
When to use it
Use the DocketMath pre/post-offer damages split workflow when you need to allocate damages across time relative to an offer date. Common triggers include:
- You are tracking damages continuously over time (e.g., monthly expenses, accruing obligations, or running totals)
- You have one or more damage components that start/stop on specific dates
- You have a damages model that must be audit-ready and explainable based on dates tied to an offer
A quick decision checklist
If you answered “yes” to the first three items, the split tool will likely be useful. If you also answered “yes” to the fourth, you’ll apply the offer split within the SOL-eligible time window (6 years, per the general/default baseline).
What you’ll typically input
Most users structure their inputs like this:
- Offer date (the cutoff between “pre” and “post”)
- Damage rate or amounts by period (daily/monthly amounts, invoices, or totals by date range)
- Start date and end date of each damages component (so the calculator can allocate dollars to the right bucket)
Open the calculator
Use the calculator here: /tools/pre-post-offer-damages
Step-by-step example
Below is a realistic walkthrough showing how the split changes outputs when you move dates or rates.
Example facts (Michigan)
Assume you’re calculating damages for a single continuous component—an accruing monetary obligation—using a monthly rate.
- Offer date: June 15, 2022
- Case filing date you use for lookback: July 1, 2028
- General SOL baseline: 6 years under MCL § 767.24(1)
- The SOL-eligible window starts: July 1, 2022 (6 years before July 1, 2028)
Your damages component spans:
- Start of damages: January 1, 2021
- End of damages: December 31, 2023
- Rate: $2,000 per month
Step 1: Determine the eligible accounting window (SOL baseline)
Because the general SOL is 6 years under MCL § 767.24(1), you’re typically not splitting every historical month back to 2021 in the calculator—your modeling usually focuses on months that fall within the 6-year window.
- Eligible window: July 1, 2022 through December 31, 2023
That means the months from:
- January 2021 through June 30, 2022
are outside the 6-year baseline and are excluded from the calculator’s split inputs in this example.
Step 2: Split the eligible window at the offer date
Offer date is June 15, 2022. But your eligible window starts on July 1, 2022, which is after the offer date.
So, within the eligible window, all dates fall in the post-offer bucket:
- Pre-offer (eligible portion): none
- Post-offer (eligible portion): July 1, 2022–December 31, 2023
Step 3: Convert the date range into months (or daily amounts)
From July 2022 through December 2023, that’s 18 months.
- Monthly rate: $2,000
- Total eligible damages: 18 × $2,000 = $36,000
Step 4: Apply the pre/post split
Because the eligible window contains no dates before June 15, 2022:
- Pre-offer damages (eligible): $0
- Post-offer damages (eligible): $36,000
Step 5: What the calculator output would reflect
When you run DocketMath’s tool with:
- offer date = June 15, 2022
- damages inputs limited to July 1, 2022–December 31, 2023 (per the 6-year baseline)
your results will align with this date logic:
| Bucket | Date logic | Amount |
|---|---|---|
| Pre-offer | Before June 15, 2022 (none within eligible window) | $0 |
| Post-offer | On/after June 15, 2022, up to Dec. 31, 2023 | $36,000 |
Pitfall to avoid: If you enter damages starting in 2021 without applying the SOL window logic, your “pre-offer” may look inflated—even though those months may fall outside the 6-year baseline associated with MCL § 767.24(1). Keep the SOL-eligible time window aligned with how you plan to present damages.
Common scenarios
Here are practical patterns you’ll see when splitting Michigan damages relative to an offer date. Each scenario highlights how the split typically behaves.
Scenario 1: Offer date falls well inside the eligible window
- Offer date: June 15, 2022
- Eligible window: July 1, 2022–Dec. 31, 2027
How results behave:
- You usually get both pre-offer and post-offer damages within the eligible window.
- As the offer date moves later/earlier, the split will shift (some months move from pre to post or vice versa).
Scenario 2: Offer date is before the eligible window starts
This matches the earlier example: the offer date is earlier than the first eligible day under the 6-year baseline (MCL § 767.24(1)).
How results behave:
- Pre-offer = $0
- Post-offer = total eligible damages
Scenario 3: Offer date is after your damages end date
- Damages end: Mar. 31, 2023
- Offer date: Sep. 1, 2023
- Eligible window includes the relevant period
How results behave:
- Post-offer = $0
- Pre-offer = total eligible damages
Scenario 4: Multiple damages components with different rates and dates
Common when you have, for example:
- Component A: $1,200/month for equipment
- Component B: $450/month for software
- Component A starts earlier than Component B
How results behave:
- Each component’s active date range may place some amounts into different buckets.
- A reliable workflow is to enter each component with its own start/end dates (and rate/amount rules), then let DocketMath aggregate totals.
Scenario 5: One-time damages mixed with accrual damages
If you have:
- recurring monthly amounts plus
- a lump-sum repair billed on a specific date
How results behave:
- The lump-sum will fall into pre or post depending on whether the billing/accrual date is before or on/after the offer date.
- This can materially change the totals even if the monthly recurring component is unchanged.
Tips for accuracy
Most mistakes come from date discipline and consistent math. These tips help you keep the split defensible and easy to review.
1) Apply a consistent rule for “on/after offer date”
Decide and apply a consistent rule:
- Pre-offer: strictly before the offer date
- Post-offer: on or after the offer date
Use the same approach for every component, so your totals don’t mix inconsistent interpretations.
2) Align the SOL-eligible window with MCL § 767.24(1) (general/default)
For this guide’s purposes:
- **
Sources and references
Start with the primary authority for Michigan and confirm the effective date before relying on any output. If the rule has been amended, update the inputs and rerun the calculation.
