Spreadsheet checks before running small claims fees and limits in North Carolina

5 min read

Published April 15, 2026 • By DocketMath Team

This article is for informational purposes only and does not constitute legal advice. Laws change frequently — verify all citations with current official sources.

What the checker catches

Run this scenario in DocketMath using the Small Claims Fee Limit calculator.

Running North Carolina small-claims fee and limit calculations off a spreadsheet is where mistakes hide: a wrong cell reference, a mis-copied fee table, or a limit filter that excludes the wrong case type. DocketMath’s small-claims-fe-limit checker is designed to catch spreadsheet “sanity” issues before you rely on the output.

Here’s what the checker can flag in a typical workflow:

Fee/limit mismatch caused by numeric formatting
- Example issues: imported amounts stored as text (“$500” instead of 500), commas causing parse failures, or rounding at the wrong step.
Wrong base amount
- Example: using total damages claimed instead of the amount used for fee or jurisdiction thresholds.
Off-by-one logic in thresholds
- Example: a conditional like > 2500 when it should be >= 2500 (or vice versa), shifting outcomes at the boundary.
Stale or inconsistent columns
- Example: one tab uses updated parameters; another still points to an older fee rate.
Contradictory assumptions across the sheet
- Example: the sheet calculates fees using one method, then applies a limit using a different method or a different “amount” column.
Accidental inclusion/exclusion via filter flags
- Example: a “case type” column that’s empty for some rows—your filter silently drops them, skewing totals.

Note (gentle disclaimer): A spreadsheet can “look right” while producing legally incorrect thresholds if the sheet uses the wrong input field (for example, claimed damages vs. net amount) or applies a boundary rule inconsistently. The checker is meant to prevent this class of spreadsheet error—not to replace legal judgment.

A quick timeline reality check: the 3-year default SOL baseline

Spreadsheets often include a statute of limitations (SOL) step to determine whether a claim is timely. In North Carolina, the general/default SOL period is 3 years. Where a spreadsheet assumes a different sub-rule per claim type, the workflow can break.

Your materials may also mention the SAFE Child Act, which is part of the broader supporting-victims-and-survivors framework summarized by the NC DOJ (see: https://www.ncdoj.gov/public-protection/supporting-victims-and-survivors-of-sexual-assault/). However, for SOL handling in this checker context, the safest spreadsheet approach is:

Treat the 3-year general default SOL period as the baseline.
Avoid claim-type-specific SOL branching unless you have a confirmed, source-backed rule for that specific claim category.

This post focuses on fee/limit sanity-checking, but an SOL mismatch is a common “upstream” error because people bundle SOL, fees, and limits into one workbook.

When to run it

The best time to run DocketMath’s small-claims-fe-limit checker is before you copy results into filings or summary documents. In practice, that means at least three checkpoints:

After you import or paste amounts
- Run the checker immediately after data entry.
- This catches formatting issues (text numbers, missing decimals, commas, trailing spaces).
After you update any fee/limit parameters
- If you change a fee rate, threshold, or rule selector cell, rerun the checker right away.
Right before final exports
- If you generate PDFs, copy to another tab, or export to another system, run the checker on the final sheet version to catch broken links.

If your spreadsheet handles multiple rows (e.g., multiple plaintiffs, multiple invoices, or batch scenario planning), use the checker on:

Each boundary case row (values near the threshold), and
At least 1 “typical” middle value row (not just extremes).

Boundary-value checklist (practical)

Use values that sit just below, exactly on, and just above your spreadsheet’s threshold logic:

The goal isn’t to “guess the law”—it’s to confirm your formulas behave correctly when inputs move across boundaries.

Try the checker

Use DocketMath’s tool here: /tools/small-claims-fe-limit.

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

Recommended inputs to verify in your spreadsheet

Before running the checker, confirm these fields (rename them in your sheet as needed, but keep the meaning consistent):

Claim amount used for fee/limit logic
- Make sure you’re using the same column for both fee calculation and the limit check.
Any selector flags
- Example: “include costs,” “use claimed damages,” or “net amount.”
Rounding rules
- Confirm whether you round at each step or only at the end.
**Date fields (only if you’re filtering by SOL timing)
- Use the 3-year default SOL period as your baseline unless you have a confirmed claim-type-specific rule.

Reminder: The checker helps you sanity-check the spreadsheet logic. It doesn’t provide legal advice.

How outputs should change (so you can spot formula errors)

Once you run the checker, compare outputs as you change one input at a time:

If you increase the claim amount gradually, fee/limit outputs should move consistently (in the same direction), not bounce around.
At the threshold boundary, outputs should switch exactly once—no double counting and no gaps.
If you switch formatting (e.g., $1,500.00 vs 1500.00), the checker should interpret both consistently.
- If it doesn’t, your spreadsheet is likely storing numbers as text or using locale-specific parsing. Fix the input type first, then rerun.

A quick cross-check against the SOL baseline

If your workbook includes “timely vs. not timely” filtering:

Ensure the workbook uses the general/default 3-year SOL period as the baseline.
If you later add claim-type-specific branches, keep them separate from fee/limit math. Mixing them into the same cell logic often creates hidden dependency bugs.