Spreadsheet checks before running Damages Allocation in Maryland
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Before you run Damages Allocation in DocketMath for a Maryland case (US-MD), you should sanity-check your spreadsheet inputs—because allocation math can be derailed by one bad assumption, especially around timing.
This Maryland-focused checker is designed to catch spreadsheet issues that typically cause:
- Out-of-range date math (leading to incorrect damages windows)
- Wrong start/end dates being fed into allocation logic
- Inconsistent installment timelines (for example, mixing monthly and quarterly schedules)
- Accidentally blank or text-formatted dates (Excel/Sheets may interpret these differently)
- Conflicts between “case timeline” tabs and “damages” tabs (different tabs using different dates for the same concept)
Maryland timing baseline the checker uses
Note: Maryland’s general/default statute of limitations period is 3 years under Md. Code, Cts. & Jud. Proc. § 5-106. No claim-type-specific sub-rule was identified in the provided materials, so the checker treats § 5-106’s 3-year general period as the default framework.
Here are the specific spreadsheet patterns the checker catches.
Common spreadsheet problems (and what the checker flags)
| Check | What it looks for | Typical spreadsheet symptom |
|---|---|---|
| Date validity | Blank date cells, non-date text | “0 days” or calculation errors like #VALUE! |
| Timeline direction | End date earlier than start date | Negative day counts or inverted time windows |
| 3-year general SOL window | Windows extending beyond the default 3-year period | Damages appearing to cover periods outside the default limitations framework |
| Installment alignment | Partial months or mismatched frequency | Allocation sums don’t reconcile to totals; period-by-period amounts look off |
| Cross-tab consistency | Different dates used across tabs | Total allocation differs depending on which tab effectively drives the model |
| Unit/scale drift | Percent vs decimal vs whole-number rates | Damages jump by ~100× (or collapse near zero) |
If your allocation model depends on “Damages Start” and “Damages End,” this checker verifies that those anchors are internally consistent and compatible with the default Maryland 3-year framework.
Gentle disclaimer: A damages allocation spreadsheet can be numerically “clean” while still being legally mis-scoped if the underlying window ignores Md. Code, Cts. & Jud. Proc. § 5-106’s default 3-year limitations period. This checker aims to reduce that risk by forcing timeline consistency before you compute.
When to run it
Run the checker before you commit to allocation outputs, and again after every material edit to timeline inputs. A practical workflow:
Create your base timeline tab
- Define: filing date (or your model’s anchor date), damages start, damages end, and any installment schedule dates.
Run the checker immediately
- Fix date formatting, ensure end dates follow start dates, and confirm the 3-year default window behavior.
Only then run Damages Allocation in DocketMath
- Allocate using the model and methodology you intend to use—the tool can’t correct window logic you didn’t mean to input.
Re-run after edits
- If you change any of the items below, rerun the checker first.
Quick “edit triggers” checklist
If any box is checked, rerun the spreadsheet checker.
Try the checker
You can use DocketMath’s Damages Allocation tool to operationalize these checks with jurisdiction-aware rules.
Primary CTA: Run Damages Allocation
Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.
What inputs usually control the outcome (and how output changes)
In most damages allocation spreadsheets, these inputs determine the allocation window and the period-by-period amounts:
- Anchor date (often filing date or a designated event date in your model)
- Damages start date
- Damages end date
- Rate/amount schedule by period (if applicable)
- Installment frequency (monthly/quarterly/etc.)
When your computed damages window drifts beyond the 3-year default framework under Md. Code, Cts. & Jud. Proc. § 5-106, the checker will typically prompt you to review whether your damages window is broader than the general limitations period. This can change the effective inclusion window (what periods are treated as allocatable) before the allocation totals are computed.
A practical example of “what changes”
If your model currently allocates damages for:
- Damages Start: 2021-01-01
- Damages End: 2025-01-01
- Anchor Date: 2025-01-15 (example)
Because the default period is 3 years, the checker may indicate the effective allocable period should focus closer to the 3-year window relative to your anchor logic. In other words, the checker can change the effective inclusion window—not your raw rate schedule—before allocation totals are finalized.
Minimum steps to test your sheet
- Locate the cells that hold:
- anchor date
- damages start
- damages end
- Ensure all three are true date values (not text).
- Confirm damages end is after damages start.
- Run the checker via DocketMath, then compare:
- the period window it uses
- the total allocatable period
- any flagged out-of-range dates
Pitfall to watch: A spreadsheet can look correct while storing dates as text (for example,
"04/15/2023"instead of an actual date serial). That can silently break timeline logic and lead to allocations computed over the wrong days.