Spreadsheet checks before running Damages Allocation in Georgia

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Before you run Damages Allocation in Georgia with DocketMath, use a spreadsheet pre-check to catch issues that commonly break allocation math or create wrong assumptions about timing.

This checker is designed around Georgia’s general/default SOL concept—specifically the general statute of limitation period of 1 year under O.C.G.A. § 17-3-1. If no claim-type-specific sub-rule is provided, treat 1 year as the baseline you’re testing against (i.e., the general rule, not a tailored exception).

Use the checklist below to identify spreadsheet conditions that typically produce invalid or unreliable allocation runs:

• Confirm you have a clear trigger date (for example, claim accrual/event date) and a calculation reference date (often filing date or another cut-off used in your model).

• Practical tip: add column headers that explicitly state what the date represents (e.g., “Accrual Date,” “Reference/Cut-off Date”).

• If dates are stored as text (e.g., "01/02/2024" in a spreadsheet that doesn’t treat it as a real date), formulas may return blanks or zeros—making downstream elapsed-time and SOL-window logic unreliable.

• What the checker should flag: “date-looking” fields that are not recognized as date types.

• Many allocation approaches weight damages by elapsed time. If elapsed time is negative, your time-weighting can produce incorrect proportions.

• What the checker should flag:

  • Negative elapsed days (date order likely reversed)
  • Zero elapsed days (may collapse the allocation into a single bucket)

• For Georgia’s general rule, the default is 1 year under O.C.G.A. § 17-3-1.

• Your spreadsheet should explicitly set the baseline rather than leaving it implicit (for example, hard-coding “365 days” in one place but “1 year” logic elsewhere can cause mismatch).

• If your sheet converts dates into “365-day years,” uses mixed month-length logic, or rounds months inconsistently, the SOL boundary can shift.

• What to aim for: consistent date arithmetic (e.g., convert to a day-difference once, then compare to a single threshold).

• Damages Allocation frequently depends on component line items.

• What the checker should verify:

  • component lines sum to their intended category total
  • category totals sum to the grand total

• This is a quick way to catch copy/paste errors, missing rows, or ranges that don’t match what the allocation logic references.

• In many spreadsheets, blanks become 0 in arithmetic without generating errors—so an allocation can appear to “work” while using incomplete inputs.

• What the checker should do: highlight critical blanks (especially dates and amount fields that drive elapsed-time or weighting).

Gentle reminder: a spreadsheet can “run” (calculate numbers) while still producing incorrect allocations if timing assumptions or date arithmetic are wrong. Pre-checking is meant to reduce those silent failures.

Georgia-specific SOL baseline your spreadsheet should reflect

Georgia’s general/default statute of limitation period is 1 year under O.C.G.A. § 17-3-1. In this workflow, the checker should treat that 1-year window as the baseline assumption for timing checks—because no claim-type-specific sub-rule has been provided for more granular exceptions.

Reference for the general rule:

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

When to run it

Run the spreadsheet checks right before you execute Damages Allocation, not after. The goal is to stop bad inputs from propagating into outputs that may look plausible.

A practical sequence:

1. After data import / manual entry

   • Run immediately after you populate the spreadsheet with dates and amounts from source documents or prior sheets.

2. After any formula changes

   • If you edit elapsed-time logic, allocation weights, or SOL-window filters, re-run checks to confirm outputs still reconcile.

3. After you set Georgia jurisdiction-specific parameters

   • Lock the baseline to Georgia’s general rule (1 year under O.C.G.A. § 17-3-1) before timing tests and allocation runs.

4. Before exporting results

   • If you export results, upload to another system, or map cells into a report, run the checker one last time to confirm ranges/cell mappings are correct.

If the checker flags an issue, correct the spreadsheet first—don’t “override” outputs after the fact. A consistent workflow helps you trust what DocketMath calculates.

Try the checker

You can run the allocation workflow starting with DocketMath here: /tools/damages-allocation.

Before you click “calculate,” mirror the pre-check logic in your spreadsheet:

• Confirm you’re using the Georgia general/default SOL baseline of 1 year under O.C.G.A. § 17-3-1 (don’t substitute other timelines unless you’ve specifically identified and applied a different rule).
• Ensure elapsed-time calculations use consistent date arithmetic (and that date cells are real dates, not text).
• Reconcile amounts so your component lines equal your totals.

A quick “pre-flight” routine:

Related reading

• Damages Allocation Guide for Alabama — Comparative Fault Rules
• Damages Allocation Guide for Alaska — Comparative Fault Rules
• Damages Allocation Guide for American Samoa — Comparative Fault Rules