Spreadsheet checks before running Damages Allocation in Louisiana
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Damages Allocation calculator.
Before running a Damages Allocation calculation in Louisiana (US-LA) with DocketMath, use a “spreadsheet checker” step to catch the most common data issues that can distort results—or trigger later workflow problems (like filing deadlines) even if the damages math seems right.
This checker is designed to flag problems in your spreadsheet before you hit the /tools/damages-allocation workflow.
Spreadsheet issues the checker can detect
- Missing required columns for allocation inputs (for example: injury/damages line items, amounts, dates used for time-based logic, or any jurisdiction parameters your sheet relies on).
- Unit and formatting mismatches
- Currency stored as text (e.g.,
"$12,500"instead of12500) - Dates stored as strings (e.g.,
"03/01/2024"typed into cells rather than real date values)
- Internal consistency errors
- Allocation components that don’t sum to totals
- Negative values where your model expects non-negative figures
- Duplicate rows that inflate totals
- Jurisdiction gating issues
- Confirming your spreadsheet is set to US-LA rules, so you don’t accidentally run with a default or wrong jurisdiction configuration.
- Time-window logic problems tied to Louisiana’s general prescriptive period
- If your spreadsheet uses dates to determine whether a claim is within the general prescriptive period, the checker verifies you’re applying the correct baseline: La. Rev. Stat. Ann. § 9:2800.9
- Based on the provided jurisdiction data, the general SOL period is 1 year, and no claim-type-specific sub-rule was found—so the checker treats § 9:2800.9 as the default period.
Note (gentle disclaimer): This is a workflow validation step, not legal advice. If your spreadsheet’s timing rules are based on assumptions that don’t match your situation, the checker can’t replace legal review.
Quick “red flag” checklist (use before you calculate)
When to run it
Run the checker at two points: once before data entry locks in, and again right before you export results for damages allocation.
Run the checker before importing a spreadsheet into the Damages Allocation workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.
Step 1: Immediately after you import or paste data
This is usually the fastest time to correct issues because you still have the raw source document(s) in view.
Focus on:
- Numeric conversions (currency → number)
- Date parsing (string → date)
- Column headers and mapping (ensuring the sheet’s structure matches what the calculator expects)
Step 2: Immediately before running Damages Allocation in DocketMath
Even small edits can introduce subtle defects—like changing a date in one place but not in the related fields that feed the time-window logic.
Common examples:
- A date cell edited during review but not mirrored in related “start date/end date” columns
- A row inserted for notes that breaks range references
Jurisdiction timing logic: how it connects to Louisiana
If your spreadsheet incorporates time-window logic, the checker should enforce the default prescription baseline for Louisiana:
- General prescriptive period: 1 year
- Statute used (default): La. Rev. Stat. Ann. § 9:2800.9
- Claim-type-specific sub-rules: none found in the provided jurisdiction data, so § 9:2800.9 is treated as the general/default period
To keep your workbook traceable, a practical habit is storing the applied citation in a “Rules” tab so reviewers can see what baseline the spreadsheet assumed.
Source reference (as provided in the brief):
https://louisianabaptists.org/resources/sexual-abuse-response-resources/sexual-abuse-definitions-and-louisiana-statutes/?utm_source=openai
Try the checker
Start with your spreadsheet and run a preflight pass before you open the allocation calculator.
Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.
Capture the source for each input so another team member can verify the same result quickly.
Recommended workflow
- Go to /tools/damages-allocation
- Run the spreadsheet-checker preflight:
- Validate data types (numbers/dates)
- Validate sums and totals
- Validate US-LA jurisdiction selection
- Validate prescription baseline usage (default 1-year period from La. Rev. Stat. Ann. § 9:2800.9)
- Run the calculator
- If outputs look off, trace back to the specific flagged group (e.g., “dates in column D are text” or “allocation components do not reconcile”)
How inputs affect outputs (practical examples)
| Input condition | Checker response | Likely effect on allocation results |
|---|---|---|
| Amounts entered as text | Flags non-numeric currency fields | Totals may become 0 or incorrect during computation |
| Dates entered as text | Flags unparsed date cells | Time-window logic may misclassify timing |
| Components don’t sum | Flags reconciliation mismatch | Allocation may be based on the wrong totals or invalid rows may be excluded |
| Wrong jurisdiction mapping | Flags US-LA inconsistency | The “prescription baseline” logic may use an incorrect assumption |
| Prescription logic applied to the wrong period | Flags rule mismatch | Outputs may reflect ineligible time windows based on the wrong SOL |
Pitfall to avoid: If you correct only one flagged cell (for example, a single date column) but leave related fields inconsistent (like the comparison column still being text), the checker may still block a clean run—or the allocation may look reasonable but fail reconciliation.
Sanity checks after you run
Even after a “clean” preflight, do quick validations:
- Do allocations align with your spreadsheet totals?
- Are any categories unexpectedly zeroed?
- Did the calculator apply the default 1-year prescriptive baseline tied to La. Rev. Stat. Ann. § 9:2800.9 (with no claim-type-specific sub-rule provided)?
If something doesn’t match expectations, re-run the checker and correct the specific flagged issue(s).
