Spreadsheet checks before running Structured Settlement in Georgia

What the checker catches

DocketMath’s Structured Settlement spreadsheet checker for Georgia (US-GA) is designed to flag common “before you run it” problems that can derail your settlement workflow—especially when your timeline logic depends on a statutory time limit.

For Georgia, the checker uses the general/default limitation period provided in your jurisdiction data:

• O.C.G.A. § 17-3-1 (general statute of limitations): 1 year
  Source: https://law.justia.com/codes/georgia/2021/title-17/chapter-3/section-17-3-1/?utm_source=openai

Important note (from the jurisdiction data): The data provided for this checker identifies only a general/default statute of limitations period of 1 year under O.C.G.A. § 17-3-1. No claim-type-specific sub-rule was found in the provided data, so the checker applies the general rule unless you use a documented, claim-specific rule from your own research.

Here are the specific categories the checker is designed to catch in a structured settlement spreadsheet:

• Missing or inconsistent key dates
  Typical fields include: date of injury/incident, demand date, contract/settlement date, payment start date, and any “trigger” date you use for cashflow logic.
  Output impact: the tool can’t reliably determine whether your spreadsheet’s timeline is complete for a limitation-period check, so it flags those row(s) as incomplete.

• Date format problems that break calculations
  Common issues: dates stored as text, mixed formats (e.g., MM/DD vs DD/MM), or blank cells in the “reference date” column.
  Output impact: calculations like “age of claim” (or any day-count-based logic) can become wrong or show misleading pass/fail indicators.

• Off-by-one logic caused by how dates are represented
  For example, entering 2024-01-01 versus 01/01/2024 00:00 can cause filtering or boundary logic to exclude or include the wrong day depending on how the spreadsheet is set up.
  Output impact: when the limitation window is tight (and Georgia’s general period is 1 year), small boundary differences can flip the result.

• Run-time mismatch between the settlement plan and spreadsheet schedule
  Example: the schedule shows payments for 36 months, but the plan sheet indicates a different duration, or the payment start dates don’t match across tabs.
  Output impact: timeline-based checks and cashflow outputs may no longer reflect the same underlying plan.

• Limitation-period compliance checks using the general/default rule
  The checker uses 1 year as the Georgia general/default limitation period from O.C.G.A. § 17-3-1.
  Output impact: if your spreadsheet indicates that the relevant event happened more than 365 days (or effectively “over a year,” depending on the day-count method you’ve configured), the checker highlights that mismatch.

Gentle disclaimer: DocketMath helps you validate spreadsheet mechanics and apply the selected timing rule to your inputs. This is not legal advice; confirm your limitation-period theory and triggers with qualified guidance where appropriate.

When to run it

Run DocketMath’s spreadsheet checker before you execute the Structured Settlement calculation workflow. In practice, that usually means at two decision points: data validation time and results interpretation time.

A practical sequence:

1. After you populate the spreadsheet, before running calculations

   • Confirm dates, durations, and triggers.
   • Verify that every row feeding the structured settlement schedule has required inputs.

2. Right before you share outputs internally or with counterparties

   • Catch last-minute edits that accidentally changed date formats or shifted a start date.

3. Whenever you change even a single date input

   • Even one date edit can affect whether your 1-year general limitation window is implicated under O.C.G.A. § 17-3-1.
   • Rerun the checker rather than relying on prior confidence.

Quick checklist to use while running:

• All date fields are filled for every relevant row
• Dates are stored as actual spreadsheet dates (not text)
• The schedule start date matches the plan’s start date
• The trigger/event date aligns with the timeline logic you intend to check
• The checker reports “complete inputs” before you trust computed results
• Your timing rule selection matches the Georgia general/default 1-year period from O.C.G.A. § 17-3-1 (unless you’ve documented and modeled a claim-specific rule yourself)

Try the checker

To see how the Georgia-aware rules affect spreadsheet inputs, start with DocketMath’s Structured Settlement tool:

• Open: Run Structured Settlement in Georgia

What to enter (and how outputs change)

As you work through the tool, focus on these input categories—because they most strongly influence what the checker flags:

• Trigger / reference date(s)
  Changing these dates is the fastest way to see the checker respond, because the general limitation window is 1 year under O.C.G.A. § 17-3-1.

• Schedule start date and duration
  If these don’t align with your payment schedule rows, you’ll see validation flags tied to mismatched timelines.

• Any “last updated” or “event occurrence” fields used in your calculations
  If you edit one cell but forget dependent date logic elsewhere, the checker will usually catch date inconsistencies immediately.

How the Georgia rule is applied (general/default)

The checker applies Georgia’s general statute of limitations timing input from your jurisdiction data: 1 year under O.C.G.A. § 17-3-1.

If you’re unsure, run the checker iteratively:

• once with your original date set,
• then after you correct formatting or align plan and schedule dates,
• and once more after any final spreadsheet edits.

This “before/after” approach makes it easier to confirm the checker is catching the problems you actually fixed.

Related reading

• Browse the blog