How to run Offer Of Judgment Analyzer in DocketMath for South Dakota
6 min read
Published August 16, 2025 • Updated April 23, 2026 • By DocketMath Team
Trust release 4
This page has legal or numeric text that still needs claim-level inventory before we can treat it as verified.
Step-by-step
Run this scenario in DocketMath using the Offer Of Judgment Analyzer calculator.
This guide walks you through running DocketMath’s Offer Of Judgment Analyzer for South Dakota using jurisdiction-aware rules. It focuses on how the tool applies timing rules under SDCL § 15-6-68 (South Dakota’s offer of judgment statute) and what to expect from the analyzer output—without giving legal advice.
Note: SDCL § 15-6-68 is the default South Dakota rule for offers of judgment. From the jurisdiction data provided, no claim-type-specific deadline was identified. So, treat the statute’s baseline timing framework as generally applicable for how the analyzer models “timing compliance.”
1) Open the analyzer for South Dakota
- Go to the primary CTA: /tools/offer-of-judgment-analyzer
- Select South Dakota (US-SD) as the jurisdiction (the tool may preselect it, but verify).
- Confirm the analyzer is using a South Dakota ruleset tied to SDCL § 15-6-68.
2) Understand the timing rule your inputs must reflect
Before entering numbers, anchor your timeline to SDCL § 15-6-68’s baseline requirement.
From the statute: an offer may be served “[a]t any time more than ten days before trial…” (SDCL § 15-6-68).
Concretely, you want your inputs to let the tool determine whether the offer was served more than 10 days before trial. If the analyzer flags timing, that usually becomes the gating factor for whether the modeled outcome should be trusted in the tool.
3) Enter your case dates
In the analyzer, add dates that correspond to:
- Trial date (or the scheduled trial start date the tool uses)
- Offer service date (the date the offer was served on the opposing party—i.e., completed service, not just drafted or signed)
If the tool includes additional date fields, only use them if they match how you actually documented service and trial scheduling. The goal is to feed the tool the same “service vs. trial” relationship the statute is concerned with.
Date-input checklist
4) Add financial inputs (what the offer is “about”)
Most offer calculators require at least:
- Claimed amount (or another field the tool labels as “damages sought,” “expected recovery,” or similar)
- Offer amount (the judgment amount proposed in the offer)
Use the closest equivalent to what your filings describe, and—importantly—follow the analyzer’s field definitions rather than manually reshaping the numbers (for example, don’t assume the tool will automatically separate or recombine components unless it tells you to).
Amount-entry tips
5) Add outcome assumptions (so the analyzer can compare)
Offer-of-judgment analyzers typically need an assumed result to model whether the offer was effectively “beaten.”
If DocketMath asks for a projected judgment amount, estimated verdict, or similar term:
- Use your best estimate of the judgment amount the court would enter (based on evidence and likely damages theories)
- Avoid using only your “ideal settlement number,” because the tool’s output depends heavily on how far the assumed judgment is from the offer
In practice: this is one of the biggest sources of variation between runs. Even if your timing is correct, a different assumed judgment can flip the comparison and change the modeled economics.
6) Run the calculation
Click Analyze / Calculate (the button label may vary).
The tool should return results in at least two areas:
- **Timing compliance (SDCL § 15-6-68)
- Whether the offer appears to be served “more than ten days before trial”
- Offer vs. assumed judgment comparison
- How the offer amount measures against the assumed judgment amount
Depending on how DocketMath models the economics, it may also show modeled impacts such as:
- cost/fee-related consequences (if the tool includes them in its calculations)
- an “economics if the offer is accepted” vs. “economics if not” style breakdown (tool-dependent)
If the tool flags a timing mismatch, treat the modeled outcome as less reliable for that scenario. In many offer-of-judgment analyses, timing compliance is the threshold issue.
7) Review the analyzer outputs for decision-quality signals
Treat the results like a dashboard, not a guarantee. Look for three categories:
- **Timing compliance (SDCL § 15-6-68)
- Was the offer served more than 10 days before trial?
- Offer vs. judgment comparison
- Did the assumed judgment land above or below the offer?
- Modeled economic impact
- What does the tool estimate would change if the modeled scenario “wins” for the offer?
Warning: If your offer service date is entered too close to trial—at or within 10 days—the analyzer may indicate the statutory timing window (the “more than ten days before trial” language) is not satisfied. Even if the financial numbers look favorable, the model can break on timing.
8) Iterate with alternative scenarios
To understand sensitivity, rerun the analyzer using multiple inputs for the assumed judgment.
For example, try:
- a low / conservative assumed judgment
- a middle / likely assumed judgment
- a high / aggressive assumed judgment
You can also vary:
- the offer amount
- the trial date inputs (only if the trial schedule changed)
- the offer service date (only if you entered it incorrectly)
This iterative approach is usually the fastest way to see where the tool’s conclusions flip.
Common pitfalls
Avoid these issues when using DocketMath’s Offer Of Judgment Analyzer for South Dakota:
- Using the wrong date concept
- Pitfall: entering the date the offer was drafted or signed instead of the date it was served (completed service).
- Forgetting the “more than ten days before trial” threshold
- SDCL § 15-6-68 uses the strict phrase “more than ten days before trial.”
- Assuming claim-type-specific sub-rules exist
- Based on the jurisdiction data provided, no claim-type-specific deadline was identified. Treat SDCL § 15-6-68’s baseline timing language as the analyzer’s default assumption.
- Mixing damages with costs/fees incorrectly
- Pitfall: double-counting or placing the wrong components into the tool’s fields. Use the analyzer’s field labels and don’t combine categories unless the tool expects it.
- Testing only one number
- Pitfall: running a single assumed judgment hides how results change. Run at least 2–3 judgment scenarios.
- Relying on “near misses” around the timing cutoff
- Even a small shift around the 10-day threshold can change the analyzer’s timing compliance result.
Try it
To run a quick first pass:
- Open /tools/offer-of-judgment-analyzer
- Select **South Dakota (US-SD)
- Enter:
- Trial date
- Offer service date
- Offer amount
- Assumed judgment amount (or the analyzer’s closest field such as “expected recovery”)
- Click Analyze
- Review:
- whether the tool finds your timing consistent with SDCL § 15-6-68 (“more than ten days before trial”)
- how the offer compares to the assumed judgment
- the modeled economic impact
If your results show a timing problem, double-check:
- whether the offer service date is truly the date service was completed, and
- whether the trial start date you used matches the trial date the tool expects.
For better insight, rerun the analysis using a low/medium/high range for the assumed judgment and see where the modeled economics change.
